SwiftUI — Learnings and Challenges

Photo by Road Trip with Raj on Unsplash

With Great Power comes Great Responsibility, with a New Framework comes New Challenges.

In 2019, Apple launched SwiftUI framework for iOS development with the potential for being the best option for defining iOS and macOS user interface layouts.

During the revamp of Naukri Recruiter iOS app, we thought of trying our hands on this new framework for Authentication modules where we implemented login, OTP, forget password & other related flows.

When we started learning & using SwiftUI for our project we faced many limitations & had to use workarounds for most of the challenges.

In this blog, we will share our experiences, learnings & challenges we faced which will help you to understand whether SwiftUI would be useful for your next project.

Positives of using SwiftUI💡

Less Code / Faster Development

SwiftUI is declarative and makes a reactive-programming paradigm natural. The amount of code you need to write for a particular UI has been significantly reduced with respect to the UIKit framework. No storyboard or xib is involved.

Previews / Hot Reloading

You do not need to compile your project every time you make any UI changes. With SwiftUI previews or hot reloading concepts the changes reflect automatically as soon as you update the UI.

Cross-platform development

One of the most exciting things with SwiftUI is to write once and use it across iPhone, iPad, WatchOS, and macOS. So, you do not need to maintain a separate codebase.

Animations

Creating beautiful animations in SwiftUI is super easy since the attributes are very much similar to CSS styling.

Challenges 🛑

Minimum iOS Support

SwiftUI was launched only for iOS 13 and above versions, so you have to drop your OS 12 users. But this does not end here, there exist scenarios where some modifiers & functions are available only for iOS 15 or 14, since it is still in the evolving phase.

This makes a developer’s life difficult to add checks for availability & also compromise some features for a particular OS.

Missing Components

Some components in SwiftUI are still missing and in such cases you have to rely on the UIKit.

SwiftUI aims to solve this problem by providing UIViewRepresentable, UIViewControllerRepresentable and UIHostingController.

You can embed your UIKit views and controllers into a SwiftUI view hierarchy using UIViewRepresentable & UIViewControllerRepresentable.

If you want to use SwiftUI views in your UIKit you can use UIHostingController.

let controller = UIHostingController(rootView: SwiftUIView())

Let us discuss two such examples in detail.

a. Text Input in SwiftUI has limited features and it does not give the flexibility that UIKit has.

TextField in SwiftUI will give you a complete new string instead of “should replace characters in range” like UIKit does.

SwiftUI gives us a specific property wrapper for tracking which view currently receives user input, called @FocusState. This can be bound to a Boolean to control a single field, or to an enum to control movement between several.

BUT this works only with iOS15, which is not a correct solution. So we had to use UITextField in UIViewRepresentable instead.

b. Another example is using web views in your project. In SwiftUI there is no support for WKWebView, so if you want to implement some web views, you’ll have to use UIViewRepresentable.

struct SwiftWebView: UIViewRepresentable {
var url: URL
func makeUIView(context: Context) -> WKWebView {
return WKWebView()
}
func updateUIView(_ webView: WKWebView, context: Context) {
let request = URLRequest(url: url)
webView.load(request)
}
}
struct CustomWebView: View {
var body: some View {
SwiftWebView(url: "https://www.apple.com")
}
}

Navigation

Handling navigation in SwiftUI is one of the most challenging tasks.

Things get complex when you have to manage navigation between multiple screens depending on some state & views using deep linking.

You can checkout this interesting use case for handling complex navigation stacks in SwiftUI

Implementing complex navigation stack in SwiftUI and The Composable Architecture

Performance

We observed some rendering issues & performance lags in SwiftUI screens on some devices. The user interaction and animation experience were not smooth.

SwiftUI Laggy on a Real Device

SwiftUI Performance Issues, UI Lagging in iOS 14.2

Conclusion 👀

Based on the above experience we decided to use UIKit for the rest of our modules that involve complex navigations & logic handling. We are using SwiftUI for login flows & keep improving as it is still a younger framework.

It might take 2–3 years until it reaches the same reliability and robustness as UIKit. If we need fine-grain control and limitless possibilities, sticking to UIKit looks like a wise decision. However, that doesn’t mean you shouldn’t learn or use SwiftUI. We can still take the benefit of SwiftUI for static pages by using UIHostingController to include SwiftUI views.

The goal here was to share our learnings & experience to help you analyse the tradeoffs and drawbacks to make a more informed decision about whether SwiftUI is right for your next project.

Thank you so much for reading, would love to know your thoughts on SwiftUI!