I remember the first time I heard about Texture. It was introduced to me at an early stage in my career as an iOS developer, and just at the moment when I finally got my head wrapped around the idea of how to work with UIKit and its storyboards. Was I excited to try out something new? Yes. Did I think I was ready for such a challenge at the moment? I don’t think I did. But was it worth it? It most definitely was!
Now, let me introduce you to the library we chose to incorporate into our layout routine.
Each method of building your UI has its advantages and disadvantages, and this one is no exception. One thing I can tell you straight away is that if you are looking for something that will fast forward the process of creating your app’s layout, or make your project smaller, this is not a solution for you. Anyways, you might get a little bit disappointed at first, but I promise you, it pays off later.
Texture requires you to build your layout just like you are building everything else when developing a mobile app – by writing code. Yes, you read that right. So instead of dragging and dropping your components to the view, you will define them and arrange them in the class.
It is an iOS framework whose main purpose is to optimize your app by making user interfaces thread-safe. What this means is that you will be able to move all your views and view hierarchies on background threads, where you will prepare them before presenting them. This is the main reason why we love using it, as they make our apps faster, and leave the main thread available to focus on the execution of the app’s logic and data management, as well as to immediately respond to user interaction events.
However, Texture is not the only library that’s been developed to set up your layout programmatically. SnapKit is another example of such a library and the idea behind it was to simplify auto layout in iOS app development. Then why did we still chose Texture? Because, even though SnapKit is a library for itself, and it is not an integral part of Swift programing language, it still works with UIViews and uses UIKit to layout its components, thus throws off the app’s performance which is the exact thing we want to avoid.
Let’s start this comparison with the most obvious difference.
As you probably already know, storyboards let you build your layout by dragging the components onto the view itself, so the most noticeable difference between Texture and storyboards is that, when developing your app with Texture, there is no way to know how your layout will look until you run the app itself. At least at the beginning.
However, when it comes to the components that Texture works with, there are a lot of similarities with the UIKit. Let me explain why.
Texture’s basic unit is node, from which all other nodes inherit. It represents an abstract over the UIView which is an abstract over the CALayer. Therefore if you know how to work with views, then you already know how to use nodes as well. Of course, in case you want to access node’s view or layer itself, you can do so by calling node.view or node.layer, since they are underlying views, just keep in mind that you have to perform those calls on the main thread.
Here are some examples of nodes and node containers and their equivalents in UIKit.
|ASCellNode||UITableViewCell and UICollectionViewCell|
SwiftUI is an innovative way to build the UI of your app that uses a flexible box layout system and allows you to see the changes you make instantly on the preview as you type, as well as to see the change you make to preview immediately in your code. Many of its parts directly build on top of the existing UIKit components, but many other parts don’t, as they are new controls rendered by SwiftUI.
When compared to Texture and UIKit, SwiftUI seems to offer the best of both worlds, since it combines the technique of writing your layout through the code and previewing the changes you made so you can keep track of your UI elements the whole time.
Still, the main question remains: Is the advantage of the preview that SwiftUI brings to the table worth sacrificing the overall performance of the app since it also builds and runs its UI on the main thread?
Using Texture has allowed us to bring out the quality of the apps we offer, making them more responsive and faster. It has taught us how to think beyond the fact that we have to lay out a bunch of elements on the screen. Also, it made us visualize our work, and see the components before they are put onto the screen. In the end, it showed us how to become more precise and focused, especially when it comes to details we did not think mattered as much.
When it comes to user interaction, now we can make our apps run more smoothly and we have the tool to customize all sorts of things meeting our or client’s likings.
One of the main things I learned while using Texture is that patience and creativity are the keys to improving layout. In case you were asking yourself why these two of all things, it’s because Google doesn’t know everything. Sure, it will help you in 95% of the time, but those 5% will also occur. And when that moment comes, you’ll need to combine your knowledge and the creative side of your brain to come up with a unique solution for your problem. On your way to finding the solution the patience will join the game as you will need it throughout your journey.
Of course, if you prefer, you can always add a third party library and solve the problem, but trust me, it will feel much better if you come up with the solution on your own. Considering how adding another library may slow the app down, the result will be more satisfying, especially for the client.
All in all, I hope you found this post interesting and that it taught you something new. I urge you to give it a shot. Try it out and see if it fits your style of app development. Even if you don’t end up liking it, you will for sure learn something new and acquire new experience.
Care to share?