It has been almost a year since SwiftUI was introduced at WWDC. We’ve tried SwiftUI for a few months now, and even built a premium fitness app just with SwiftUI. Unfortunately, after this adventure, we’ve decided, as a team, to not pursue SwiftUI apps any further. The framework is simply not ready for complex apps, and, to be honest, this should be embarrassing for Apple, given how low the quality bar was for this launch.
After drawing lots of attention, SwiftUI has gradually immersed itself into the world of iOS developers. Currently, there is a lot of discussion about whether it is stable enough to start new iOS projects, especially medium to large apps. In this article, we are describing our experience with SwiftUI, covering all the drawbacks that led to our decision of delaying its adoption.
SwiftUI Drawbacks
Anything newly launched is going to have bugs. Not just SwiftUI, but everything. And we need to be patient, and give it time to improve and grow into a powerful UI framework. Therefore, the choice of the UI framework for an important iOS project needs to be carefully considered.
There were a lot of pain-points we had to go through while implementing our fitness app in SwiftUI. These pain points vary from expected to ridiculous. We’re going to share our experience through some of the issues we have encountered to help you make a choice.
- The declarative concept is still quite new
- The most important factor: the concept. iOS developers are still familiar with the UIKit framework, so this new concept makes us very confused when approaching this new method. Not to mention, many people are still not familiar with the concept of reactive programming. With such an unstable platform, it is clear that using SwiftUI is difficult, let alone applying it to a medium-size project or more.
- The learning curve is really steep. That wouldn’t be a problem in itself, but the main pain point is that there’s no clear guidelines when it comes to layout and how views are positioned. React Native has flex, UIKit has frames or Auto Layout, but what about SwiftUI? Apple didn’t tell us.
- The lack of documentation and community
- Even on the official Apple pages, the documentation is mostly very simple and generic. Of course, there are components we won’t need too much information about, but besides those, there are concepts that we really need more details than just basic definitions (e.g GeometryReader).
- In general, the current community is still quite new, and not many people are really experienced. Most are still in the process of learning and experiencing.
- This is somehow expected for a new framework, but unfortunately, the basic foundation (layout concepts, axis, etc.) is simply non-existent. You simply need to try out a infinite number of solutions, hoping something will work.
- An incomplete collection of components
- Except for primitive components like labels, buttons, images, etc, we have to rebuild almost all our familiar components like CollectionView, MapView, or Camera Picker. Whether using pure SwiftUI or building representatives through UIKit wrapping, you have to handle them yourself.
- This creates a completely messy codebase, where everything is pretty much bridged to UIKit. What’s the point Apple? What’s the point?
- Impossible migration from UIKit
- All the existing apps are pretty much stuck with UIKit. There’s no easy way to migrate to SwiftUI. Not only you have to rewrite your full UI, you also need to rethink it entirely, with a different layout paradigm.
- Migrating from Objective-C to Swift seems like a trivial task now compared to migrating UIKit code to SwiftUI.
- No backwards compatibility
- Although Apple has reported that more than 80% of the market today is running the operating system from iOS 13 onwards, and in the future this number will approach 100%, there are still currently 20% of people on lower OS versions, who will not get your SwiftUI app.
- This is not such a big drawback, since backwards compatibility would have been almost impossible to achieve, and this will get fix naturally as the time goes by.
- Difficulty to visualize how the UI is built
- According to Apple, to understand the layout nature in SwiftUI, we have 3 steps. In short, it will look like this: the parent view will suggest the size and position for the child view, the child view will decide based on the parent view or based on the size of the parent, then the parent view will redraw the entire view based on the Information from child view. Easy right? No, life isn’t all that rosy.
- The more views you have and the more nested they get within each other, the more you lose control over them. It’s hard to analyze what is wrong and how you can properly lay out stuff, when there are dozens of views, stacks and modifiers inside.
- To this day, there’s still no clear definitions/explanations of the SwiftUI’s layout paradigm. Is it flex? Is it auto layout? Nope. We simply don’t know. All we know is that SwiftUI is declarative (as opposed to UIKit which is imperative), but that only tells us that “it’s closer to React Native than to UIKit”.
- Encouraging bad design patterns
- Designing code with SwiftUI is actually not as straightforward. Adapting the classic patterns of MVP, MVC, or MVVM it’s actually really hard. SwiftUI blurs the lines between controllers, UI or view models.
- Up to now, not many developers have actually built a reasonable pattern with this data-driven framework. Sometimes, you need to add a bunch of State, Binding, ObservedObject, etc entities just for controlling bits of UI. This gets messy pretty quickly, the moment you step away from a simple image and text cell.
- A TON of major bugs
- Navigation and screen transitions are a mess. The moment you add a second screen to your app, you’ll understand.
- View life cycling has major issues (e.g. onAppear doesn’t get called when going back one screen)
- Responsiveness is a shit show. And we’re not even talking iPads here.
SwiftUI – Next Steps
SwiftUI is buggy, immature and undocumented. But it also looks like Apple’s future focus. If you are starting a new app today, you’re pretty much betting that Apple will improve SwiftUI’s features as soon as you’ll need them.
Again, as we said, it’s about tradeoffs rather than right and wrong. And of course, if you are willing to accept the current shortcomings, and work around to find temporary fixes, then just do it. The advantages of SwiftUI are obvious, the performance is better, the UI code is cleaner (allegedly), “seems” easier to understand.
And certainly, in the future, SwiftUI will increasingly improve and replace the main role of UIKit – just like Swift did with Objective-C. But it’s a bet. We simply don’t know when that future is going to happen.
Our decision for now is to not use SwiftUI at all in our products. Our apps are simply too complex, and SwiftUI doesn’t support the most important features. We predict that in about 2 years from now, SwiftUI will be production ready. Unless Apple gives up on it. We’ll watch its evolution closely, but we are staying away from it for now.
As for you, if your app is super simple, a side project or a school homework, go with SwiftUI. If you are planning to build a multi-million dollar app within the next few years, just do UIKit. You’ll save a lot of development trouble, and UIKit literally support anything you want to do in UI, as opposed to SwiftUI, which will already frustrate you starting with the second screen.
We have a team that approached SwiftUI very early. Therefore, if you have any questions or concerns about this framework, do not hesitate to send us questions via email or other contact channels. We will help you answer those questions. Thanks for reading and let us know your thoughts. Don’t forget to share this with your community.
