Image for post
Image for post
Creating UI Component using Texture + TextureSwiftSupport

Creating UI with like SwiftUI’s syntax by the power of Texture framework in UIKit based app development

Muukii (Hiroshi Kimura)
May 3 · 4 min read

In this article, I’m going to talk about “Creating UI with code and how we could write like SwiftUI’s syntax with Texture

As a premise, the targets people in this article:

  • Trying to create UI without Interface Builder. (It means writing the code to set the layout constraints up.)
  • And feels tired with so many constraints and hard to recognize a layout from the source-code.

About creating UI with the code.

What can we get from creating UI without Interface-Builder?
That means writing setting AutoLayout up or managing the frame of view or layer manually.

In a massive project, it would have so many screens and dependencies on each other to get screen transitioning.
And we’ll see so many patterns of layout and UI components on a screen.

The visual editor, such as Interface Builder, it helps us creating UI faster.
However, they don’t have an excellent way to manage it while improving the application (UI would change frequently depending on their business).

Therefore, one of the popular ways to do that, we drop to use Interface-Builder. The big players are doing that.

However, writing the code of AutoLayout gets it complicated, and it takes a longer time.

What about SwiftUI?

Firstly, SwiftUI’s paradigm differs from UIKit. But SwiftUI’s layout syntax seems it based on CSS Flexbox and expanded.

Therefore, the syntax would be like this:

Image for post
Image for post
From Apple’s SwiftUI Tutorial

You should take care of this syntax that includes style and setting data up as well as layout when comparing AutoLayout.

This syntax is nicely clear to read and recognize the layout.
VStack and HStack mean the direction of Vertical and Horizontal.
They indicate it distributes sub-components their direction.

What if we get SwiftUI similar syntax, at least for creating the layout in UIKit based application development?
In AutoLayout, it’s not easy to get. Therefore I’ve tried this on Texture framework.

What we could get with Texture.

First of all, Let me show you an example of the code and layout figure.

Image for post
Image for post
Creating UI Component using Texture + TextureSwiftSupport

Above code makes UI component such as following

Image for post
Image for post
Layout figure

Texture supports flexbox based layout engine.

Texture (Formerly AsyncDisplayKit) is a library to get more power into the application.

Mainly they attract with the point of getting excellent performance (Faster FPS)
This feature is fantastic, but now we focus on their layout-system and component management in this article.

Texture wraps UIKit to get better performance and performs some operations asynchronously.
Therefore they use ASDisplayNode to manage UIView or CALayer.
No needs to worry about using Texture. They support interop with UIKit.

Texture’s layout runs on its layout engine that utterly different from AutoLayout.
Then Texture manages its children that should be added automatically.
(Please don’t forget to turn automaticallyManagesSubnodes true.)

This function means we can describe the layout with the condition that the component will be hidden. It removes from superview.
It lays out again when called setNeedsLayout.

Image for post
Image for post
It’s like SwiftUI. It lays out the components conditionally.

TextureSwiftSupport gives Texture more power.

This syntax is powered by TextureSwiftSupport framework. We can’t do this only Texture.

TextureSwiftSupport project started from to get DSL like syntax for ASLayoutSpec. I am the main contributor.
If we don’t use it, layout syntax would be following.

Image for post
Image for post
Writing LayoutSpec without TextureSwiftSupport

It’s already simple, but it looks a little bit confusing. However, the engineers who know CSS Flexbox well can read easily.

Creating UI fast and clarity in UIKit based application

Experience in writing the code of AutoLayout (programmatically) can be improved with any other AutoLayout libraries. However, I don’t think it will be shorter than the time for writing SwiftUI’s layout.

Although SwiftUI is not ready for production that pretty complicated and large, we can get some great ideas such as this topic.

While waiting for SwiftUI, let’s improve the time for development with any ideas.

Eureka Engineering

Learn about Eureka’s engineering efforts, product…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store