I've seen a lot of posts lately regarding the should-we/shouldn't-we in transitioning to SwiftUI and thought I'd chime in with my recent experience.

Some background: I'm a lifelong coder who hated Obj-C and started writing Swift on Day 1 after ordering my MacBook Pro on Day 0. I've done the corporate gig, but currently work for myself. I started a popular light show app around 8 years ago, which is almost entirely written in Swift/UIKit with Storyboards. Previously I've reused these components when writing new apps.

For my new app, I planned to write the new core user interface entirely in SwiftUI and reuse the view controllers and storyboards I had already created for additional features such as user settings, light pairing, Firebase authentication, and purchasing. The pitch from Apple is that SwiftUI and UIKit are interoperable, so I thought I would give it a try.

The reality is that once I began writing in SwiftUI, the code was so fast and easy to update that it made more sense to write new SwiftUI for most of these components rather than adapt the old, clunky UIKit code. Most SwiftUI views were completed in a day, and since I had done a reasonable job of keeping the control code separate from the user interface, I was able to drop 99% of the UIKit code and only keep one view controller that was essentially a drop-in.

All in all, this was about five months of solo, full-time development. From scratch, this app would have taken much longer to complete, but I was able to adapt many solutions I had already created for previous apps, including Firebase cloud support and subscriptions with promotional offers, as well as my extensive light control library. The next steps are to begin some marketing and advertising efforts, but those won't start until after the new year.

If you'd like to check out the app it's available now on the App Store: https://apps.apple.com/us/app/dramatic-light-presentations/id1637747559 I also have a web site that describes the features in detail: https://www.dramaticlights.com

Q&A: "Do I still need to learn UIKit?" - You will encounter UIKit code in your travels and have to be able to work with it, but you should probably be writing SwiftUI with all new projects now. If you're a corporate coder or have a large code base YMMV but the sooner you transition the happier your life will be. Similarly, when Swift was originally released people said that you'd still need to know Obj-C, which was true but also overstated.

"Is SwiftUI 'ready' for primetime?" - Yes, I'd say the version as of iOS 15 is market and developer-ready. iOS 16 has some nice improvements but you'll be targeting a lot fewer devices (only 15% of market). By choosing a SwiftUI iOS 15 over a UIKit app with a lower target version you'll be sacrificing 5-15% of the market, but since the vast majority of users are on those latest 2 OS versions I think it's an acceptable loss since the other users will probably upgrade at some point and the up-to-date users are more likely to buy apps anyways.

"Who shouldn't be writing SwiftUI?" - If you have a boss or client who is going to demand that the user interface look and act a certain (uncommon) way, SwiftUI might be a hassle. SwiftUI has a way of organizing layouts that's fantastic if you're a developer trying to quickly write and release apps, but many things can be customized to high standards, although perhaps not always in the way you would like. I wanted an all-native solution, but still used a few different third-party controls in cases where the native implementation was missing or lacking (e.g. SwiftUIPager to function as UIPageViewController). If you have a reasonable and flexible boss or client who prefers to save money on development costs over nitpicking UI details, then you should use SwiftUI.

"Where was your biggest time savings?" - Designing with live preview was fun and easy (until it wasn't). Prototyping a large, complex user interface in code is usually difficult because it can require a lot of re-coding after you test it out on a real device. This was much easier with the way SwiftUI is designed because refactoring large UI components isn't as much of an effort; often, just moving a struct from one place to another. Data bindings make it easy to save and manage data, streamlining the process. Where this process fails is when you have a large app with long compile times. Some changes in SwiftUI code can take effect in the Previewer without compiling, but as soon as you touch code or delete a value, it will cause a recompile, which for me takes about 30-60 seconds. That's too long for practical live preview, so at that point, I might as well just preview on-device. For creating new, complex views mid-project, I have a sandbox project where I design, so I can have "Hello World"-level compile times.