SwiftUI in Production

I have been reading a lot of discussions and articles about SwiftUI.

Is it ready? Does it still have issues? Can you use it for production? Let me tell you a story about how we used SwiftUI in production back in 2019!

One sunny day in November 2019 I was assigned to lead a new interesting iOS project for a big customer. In the initial plannings I suggested to the Project Manager to create the App using the new, cutting-edge UI Framework from Apple called SwiftUI. It had been introduced just five months earlier and had only been released for six weeks. I wrote a list with pros and cons which looked like this:

Pros:

• Faster implementation of UI Code
• Less code to write, less code to debug and less code to maintain
• Having access to the latest Apple UI features
• Apple always supports their products and will fix any initial bugs.

Cons:

• SwiftUI will have bugs despite the support
• Initial learning curve

I presented it to the Project Manager and actually expected an negative anwer. But I was happily surprised that he immediately answered that we should use the latest Frameworks and with those, SwiftUI!

Starting the Project

The first screens were developed remarkable fast. However, when the features became more complex, problems emerged.

Missing Features

Slowly the first issues appeared. Design requested that we add multiple swipe actions to a UITableView.

After some search, we found out, that this functionality was not supported! Only swipe to delete was supported. It was also not possible to change the background colours or the text!

What to do now? We decided to implement this functionality on our own. After three days we had it working. Threedays for something you can do with UIKit in 5 Minutes! Apple should have known better.

Next feature, Pull to Refresh.

Same story here, there was no easy way to implement it. We needed to come up with something from scratch again. In UIKit this feature comes right out of the box. So, our disappointment in SwiftUI grew!

Bugs, bugs, bugs

And there were a lot of them! Especially when it came to navigation and lists -nothing made sense. It was very hard and tricky to even get simple spacings right.

In iOS 13.0 to 13.4 the issues were endless and we needed to create workarounds to solve a lot of issues. With 13.5 things became better but the first really usable iOS version was the 14.0.

One problem we had in SwiftUI was about changing the state. Storing the @State for a View is done in its ViewModel, but we had a lot of issues when the View was recreated and the @State would also be recreated. Apple themselve recognised this issue and introduced the @StateObject in iOS14 update, which solved such problems.

It was a great relief when the project management team decided to set the minimum iOS Version to 14.0. It took us multiple days just to remove all workarounds and hacks we had written just to hide SwiftUI bugs.

Design to the rescue

I need to thank our designers, because, each time we had an issue implementing something which was not supported in SwiftUI, like swipe actions I mentioned above, they came up with another design which was easy to implement. It’s a good thing that we at UXMA germany keep our design in-house and we collaborate closely. If design would have been done by an external agency such design-change decisions would probably have taken days.

Learning curve

The learning curve is steep. If you write UIKit code for years, your mind, at least mine, tends try to solve problems by subclassing, extensions and changing properties. This was the biggest challenge, not just use SwiftUI, but write UI code like SwiftUI indents to. After a while problems were solved different. The new tools were composition and generics. Everything became faster and better, new developers were able get into the code much faster than in any UIKit project I worked so far.

Code quantity and quality

All my initial expectations were surpassed. SwiftUI code has just a fraction of the size when compared to UIKit. Our view code became much more compact, easy to read and cleaner.

A small comparison of the code needed to write a simple TableView. Both classes do exactly the same! The difference is huge!

Performance wise, I don’t know how Apple did it. SwiftUI is fast. We did not need to cache views or consider if they are recreated multiple times. On devices the app is blazing fast!

Conclusion

At the end, we released our app successfully and we have much better and cleaner code then we would ever have had using UIKit.

Also, we were writing UI features or changing existing UI Components much faster then we would ever could have done with UIKit.

After writing SwiftUI for over a year, coding in UIKit feels more and more pointless. Why should you write hundreds of lines of code in UIKit if you can do it in only ten lines with SwiftUI! If I needed to choose again, then I would choose SwiftUI every time. I made this choice with iOS13 and now with iOS15 it should not even be a question.

If you have a great team which is fast, flexible and understanding then adopting cutting-edge, not too stable, technologies is not only do-able but actually a great experience.

Thanks to my Team @ UXMA germany!

As always,

Happy coding.