Is swiftUI suitable for production?

I faced several times to the question Can we use swiftUI to build our views?. As an iOS developer, I want to use the newest tools such as SwiftUI, Combine or even the new concurrency APIs. But when we’re working on an app that goes to hundreds, thousands or even millions of users we have to prioritize the clients instead of our desires.

That’s why always the answer to this question is: yes, we can introduce it, but why do you consider we have to adopt it? In this article I’ll try to explain the benefits of working with swiftUI to build a basic flow and explain its advantages and disadvantages.

Our requirements

Before starting we have to be realistic, we want to deploy our app to iOS 13+ using only swiftUI, we can’t use any other UI framework such as UIKit or AppKit. As one of the main advantages of swiftUI is its cross-platform support, we want to deploy our app on macOS (without using catalyst)

Once we have defined our requirements, let’s inspect the flow we want to build:

As you can see the first screen is going to push the login form and the login is going to present a screen modally.

Advantages

SwiftUI is so powerful one of the best features it has to improve the productivity is the preview which allows you to create your interfaces very fast. It increases the benefits of using a design pattern like atomic design in your interfaces.

You’ll be able to forget the broken constraints error as you’re going to spend your time working with paddings etcetera which are safer to use while coding.

The learning curve is hard as it swiftUI relies on concepts like generics, asociatedTypes and this is especially difficult for newbies, but the possibility of visualizing your changes in real time allows you to test and understand what you’re doing in real time (You can achieve the same with UIKit if you need it).

It’s completely reactive. If you use swiftUI along with Combine (which I personally recommend) you’re going to see a complete compatibility between both frameworks allowing you to use all the benefits from both.

The memory management is quite easy as your views are going to be modeled with structs instead of classes reducing the possibilities of getting retain cycles. This is so important when you deal with junior developers on your team.

But the main one is the cross-platform support. You now don’t need to code your interfaces twice (if you want to fully reuse your interfaces) as you can now code it once and share the code to macOS and iOS.

Disadvantages

If you really want to use swiftUI there are several disadvantages you’re going to see.

Under construction

We all know how old UIKit or AppKit are and how new is swiftUI. In my opinion, we can’t discard swiftUI yet because we have to assume that we can’t have all the possibilities UIKit give us with a framework which is 2–3 years old. Every iteration is going to add more and more possibilities. But, our clients can’t provide a worse experience because of forcing us to work with swiftUI and I’m going to show you some examples.

The first issue you’re going to face is the lack of APIs. Yes, if you’re supporting the latest iOS this is probably not going to be an issue in your code, but as we said we have to support 3 different iOS versions.

Very basic interactions such as responder management are not straightforward in swiftUI and in the case of iOS 13 or 14 are nearly impossible to achieve without relying on older frameworks. Starting with iOS 15, the focus API opens us a bunch of possibilities of managing the responder but if you just simply want to work with the responder on iOS 13 you’ll have to rely on UIViewRepresentable to achieve this behaviour

struct LegacyTextField: UIViewRepresentable {
    @Binding public var isFirstResponder: Bool
    @Binding public var text: String

    public var configuration = { (view: UITextField) in }

    public init(text: Binding<String>, isFirstResponder: Binding<Bool>, configuration: @escaping (UITextField) -> () = { _ in }) {
        self.configuration = configuration
        self._text = text
        self._isFirstResponder = isFirstResponder
    }

    public func makeUIView(context: Context) -> UITextField {
        let view = UITextField()
        view.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)
        view.addTarget(context.coordinator, action: #selector(Coordinator.textViewDidChange), for: .editingChanged)
        view.delegate = context.coordinator
        return view
    }

    public func updateUIView(_ uiView: UITextField, context: Context) {
        uiView.text = text
        configuration(uiView)
        switch isFirstResponder {
        case true: uiView.becomeFirstResponder()
        case false: uiView.resignFirstResponder()
        }
    }

    public func makeCoordinator() -> Coordinator {
        Coordinator($text, isFirstResponder: $isFirstResponder)
    }

    public class Coordinator: NSObject, UITextFieldDelegate {
        var text: Binding<String>
        var isFirstResponder: Binding<Bool>

        init(_ text: Binding<String>, isFirstResponder: Binding<Bool>) {
            self.text = text
            self.isFirstResponder = isFirstResponder
        }

        @objc public func textViewDidChange(_ textField: UITextField) {
            self.text.wrappedValue = textField.text ?? ""
        }

        public func textFieldDidBeginEditing(_ textField: UITextField) {
            self.isFirstResponder.wrappedValue = true
        }

        public func textFieldDidEndEditing(_ textField: UITextField) {
            self.isFirstResponder.wrappedValue = false
        }
    }
} 

But as we requested the support of macOS with the same source code, we’ll have to start using compilation flags to support both platforms and all the advantage is gone.

And this is pretty much the same with navigations. Pretty basic navigations such as modal might get difficult because the lack of APIs in iOS 13. Forcing you to use custom viewModifiers to achieve the same user experience.

Views are a function of state

SwiftUI proposes a new paradigm for interfaces. The views are meant as a function of state, an algorithm of converting state data to a rendered picture. And this explains why extracting routing off the SwiftUI view is quite a challenge: routing is an integral part of this drawing algorithm.

This is where, in my opinion, swiftUI can’t compete with frameworks such as UIKit or AppKit. Building dynamic navigation trees are quite difficult and you’re going to have at least at one point declared your navigation hierarchy, forcing you to a specific navigation tree.

Conclusion

It’s all in your requirements, if you have to deal with your app which is used by millions of users, I’ll probably say no, in the same way you said no to adopting swift as your language code instead of objective-c during the first versions of swift. But, things might change in the future, swiftUI is a framework that we all have to start working with and learning how to deal with as it is the future of the development.

I’m currently rebuilding my app Nalu from scratch using swiftUI. So I’ll keep this post updated with the new issues or advantages I’ll find.

If you want to know the advantages of distributing compiled code instead of source code, check out my post:

Reduce build times on your iOS app

If you like these posts please don’t forget to give me a clap and if you want me to write about another topic, don’t forget to add it to the comments.