Modernization of iOS app for business

At WWDC 2019 Apple introduced a brand new way of building UI for iOS apps - SwiftUI. Now in 2023 - SwiftUI is the perfect native way for building Swift apps User Interface and Apple strongly suggests to modernize iOS applications using this approach.?

The main issue with SwiftUI is that it’s completely different from UIKit in regards to structure, architecture and paradigm. Many developers across the world are suggesting rewriting the apps from scratch using SwiftUI due to the complete difference of approaches. But that kind of refactoring is time and resource consuming and can take years of development if the app codebase is big. So how businesses can avoid huge one time investment in the modernization of their legacy apps? Is the difference between SwiftUI and UIKit that significant so development needs to start from scratch?

The answer to those questions was provided by Apple itself and called UIHostingController. This class was designed along with SwiftUI release to hold Swift codebase within the UIKit structure and represent the SwiftUI views as a part of legacy project. Basically UIHostingController was created to maintain Swift codebase within an even older iOS programming language (Objective C) codebase. But since SwiftUI is built in a declarative way using Swift itself, products can use that for step-by-step refactoring of legacy app. That’s how it can solve high scale project modernization without needing to rewrite the app completely.

Lets imagine the app built on UIKit by using Storyboards, XIB or even code based UI. In UIKit everything was built using MVC architecture, so for a general iOS application the structure will be following

If developer is working on a particular screen with its structure, along with bug fixes of new features those are involving this screen they can refactor and reimplement the UI for that module using SwiftUI and then replace the general UIViewController to almost completely the same structured UIHostingController and add a brand new SwiftUI view to rootView of such controller. Yes, it is that easy. As a result the app will have the same structure of the application, but instead of representing the screen's UI using UIKit, it will be represented by a newly created and implemented SwiftUI view.

Allocating more time and resources to a particular screen, when implementing a new feature or fixing bugs, developers can rewrite the screen’s User Interfaces one-by-one into SwiftUI and then connect those using UIHostingController. So at the end when most or all UI modules will be rewritten, structure will be as following.

Then developers may drop the UIHostingControllers and make a SwiftUI native connectivity for screens and modules. It’ll take time and resources to make that happen, but it’ll be significantly less than reimplementing the app from scratch.

Done! Now the iOS application product is transferred from UIKit to SwiftUI. So it is that simple. Using UIHostingController will definitely save resources and investments for modernizing iOS apps and on the other hand will apply up to date technologies into the product.

The main issue here will be that the product will still use MVC architecture which is okay for SwiftUI, but not the best and optimized solution. This will be a big procedure to move to different architecture and it depends on a particular product’s codebase. But since the project will have “ready for use” SwiftUI structure, it’ll be an easier and less time consuming process to move forward.

If you want to know more about the architecture and how to transfer your current codebase to different and more suitable architecture for your needs - feel free to reach me out ?https://www.seniordev.com/contact-us