Introduction
As developers we are always excited when a new technology comes out, and we ask ourselves how it will change our lives. Is this new technology the future? How will this change the way I work? Is it going to be revolutionary? Will it help me develop faster or improve the quality of my work?
Some of these questions will be answered eventually, but how can we know how much time we should wait to start using a new technology? In this articule we'll discuss making the switch from UIKit to SwiftUI when developing native iOS applications, and how that might be beneficial for new projects.
Before SwiftUI
SwiftUI was announced at WWDC 2019 as a new paradigm, using declarative programming instead of imperative programming. Before using SwiftUI, iOS developers used storyboards, NIBs or XIBs to build the UI, and swift classes to control the events, handle the logic, search data, etc. Building the UI with UIKit is something we are used to, but sometimes brings a lot of cons, like being difficult to read for a human as it is auto generated code, and is even worse when you have a merge conflict, to the point where sometimes you get forced to revert the changes instead of resolving them.
Another disadvantage we see is the need to choose beforehand between working on a visual editor, or to create the UI programmatically. In the case, if developers were to change their mind in the future this could cause some rework.
Xcode was released many years ago and it still has some known bugs while using UIKit, where the solution is closing and opening the editor. For instance, some of the issues you may find while working with Xcode oftentimes appear after creating a new file, when Xcode doesn’t recognize it was added to the project. On the other hand, you have to specify which is the controller on the XIB files, and sometimes on runtime you can get an error saying that the view controller was not specified, getting as a result an app crash for a missing checkbox (embedded to project), a missing outlet, or not adding the class name to an identifier variable. Even if this issue is easy to fix, it definitely takes time.
What’s new?
SwiftUI has greatly reduced the time spent on development. The initial setup is very similar to what we used to have, but when it comes to the UI, everything is faster. The view can be handled both from the code and from the visual editor, and when you change something in one, it is reflected on the other. This is helpful because the code is always updated with the latest UI changes in real time using the previews. Another advantage is that it has a short learning curve, and once you get past the threshold, it becomes simple, straightforward, and organized.
With small classes, from 50 to 200 lines of code, you can have an entire view including the UI, the logic, the events and the navigation. Using reusable components helps with this. It reduces the amount of lines you need to write, making the code more readable and easy to understand. Since everything is handled by code, it becomes much easier to share the components between projects. On big, large, and complex projects, this begins to become more difficult to use and maintain. SwiftUI new Interface Guidelines tend to show few information on cells and collections, and show all the information on a detailed view. But when the view starts to add a lot of actions to perform, SwiftUI may not be the perfect tool to handle all this. Luckily, if the developer has handled everything encapsulating the views and the logic to have smaller components, this could be manageable.
If needed, there is the possibility to add UIKit components to the SwiftUI views. These wrappers should be used when a particular component only is available for UIKit (and does not exist for SwiftUI, example: UIPickerView). However, it’s always better to handle everything on only one technology and avoid custom fixes that can break another functionality. The implementation of some of the new gadgets that Apple has lately started to work on, just like Widgets and App Clips, has to be done in SwiftUI. The benefit of this is that SwiftUI is meant to work to follow the standard of the Interface Guidelines used to develop these artifacts.
SwiftUI has brought us a lot of benefits, but not everything has been perfectly implemented. The navigation between screens is something that was not correctly designed, and for applications that already exist it's going to be a problem in the future. The NavigatorView is used for iOS 14 and 15, but is deprecated for iOS 16, and of course, it affects all the screens that navigate to another one, breaking the navigation in all the application.
What are others doing?
The iOS community knows that SwiftUI is the future, and as developers we need to make the change to this new technology not only because of its longterm potential, but also because it will save a lot of time & effort to our teams and clients. However, let's not forget that the majority of the apps on the market nowadays are built using UIKit. Developing an app from scratch is expensive, especially if we cannot assure that we can have every working functionality with the new technology.
For small applications, we can start using SwiftUI, but usually with the goal of learning how to use this technology in the process. We also need to keep in mind the limitations, such as the limited support, the community is not mature enough to get all the solutions we need, or the limitation of not having all the same components and libraries that were developed for UIKit.
Conclusion
SwiftUI is a great tool with a lot of potential. It saves a lot of time of development, and is much easier to visualize, learn and understand. It’s the future of iOS native development. However, it it still not mature enough and this process will naturally take some time. It should, nonetheless, be ready in the near future which is why it's beneficial to start becoming acquainted with it in. We're confident it will continue to gain popularity, which is why we're actively using it for internal projects and recommend you do the same.
