Creating UI with like SwiftUI’s syntax by the power of Texture framework in UIKit based app development
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:
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.
Above code makes UI component such as following
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.
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.
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.
