We started our previous project without much experience with SwiftUI, we mainly knew about React and React Native. Because of battery life, constant connectivity and heavy camera use requirements, we had to go with Apple’s native solutions. With this in mind, we decided to rank the things we love and hate about Swift/SwiftUI, the most based on how strongly we feel about them.

Love & Hate

9. Love: SwiftUI integration with UIKit

SwiftUI could be integrated with UIKit if needed. We used this to start new features on top of a five year legacy application. In addition, this integration capability let us use some pod libraries that were made in UIKit. However, we recommend trying to avoid this as much as possible since this approach requires a new logic layer and inflates the code base.

8. Hate: There is no natural way to create a design system

If you are reusing a default value for padding, text size, etc, there's no real straightforward way to create a design system for that. We’ve looked at the following options:

• Using modifiers, but these need to be added on every single component.

• Creating extensions of the classes, but it’s a bit overkill and artificial to only add a few tiny cosmetic changes.

• Adding style constants in a centralized place and directly applying them where needed.

   

   

7. Love: Extensions

Almost every code that lives in production has some class that’s been inflated beyond reasonable proportions. Especially when you’re working under tight deadlines like it was in our case. Swift's answer to this are extensions: chop your class into smaller parts based on whatever criteria you pick. In our case we’ve cut up a 1000+ line viewModel into bite-sized chunks of 200 lines based on responsibility.

6. Love & Hate: The simplicity

Apple made SwiftUI really straightforward and easy to use. It is pretty fast to learn if you know some React. However, whenever you want to do something complex, you will start running into the boundaries of what’s possible with SwiftUI.

5. Hate: Preview in a legacy project

The preview feature won't work on a project that has UIKit implemented. This is because it will need to build the whole project to create the preview, and even then it will sometimes give you errors related to pods. So if you are building SwiftUI over a UIKit project, you should not use the Preview View as it will only make your development slower.

4. Love: Preview 

If you are working with SwiftUI, you could have a preview of what you are doing that reacts to changes in the code. This is a quick way to see your code changes on the go without having to start up a whole emulator. Similar to hot reloading in React.

3. Hate: Lack of test support

Even the most pragmatic programmer on our team, with more dirty tricks up his sleeve than there are duplicate questions on stackoverflow, was running out of ideas for testing certain functionality. Mocking parts of the code was often virtually impossible, even when using protocols. Unlike with javascript, where you can mock just about anything, with Swift you have to really code with testability in mind.

2. Love: Guard and if let Statements

Guard can be used to return from a method early if a variable does not meet a criteria. This way you can prevent unwanted behaviors and crashes. On the other hand, if let can be used to execute a block of code if a variable is not nil. These two control flow statements help you with avoiding the need to handle errors.

1. Hate: Features unavailable for “lower” iOS versions

We were very surprised that a simple feature like setting the focus on a Textfield via code was not supported in SwiftUI out-of-the-box (Basic support starts from iOS15 and up). The most bugs that we needed to solve revolved around using multiple modals in iOS14 for things such as alerts.

Conclusion

After this project, we aren’t in love with Swift and SwiftUI, but we won’t hesitate to work with this techstack when it seems suited to do so. When we look at SwiftUI in specific, we think it still lacks a tiny bit of maturity. This is being slowly and steadily addressed with each version.