One of a series of posts about our next app as we make it. It’ll include some details about our technology and design choices and challenges.
Bloop will not be releasable until well after iOS 13 is public. It’s a spare-time project right now and that means progress is slow. There’s often a great benefit to this however, in that you get a lot of “out-of-band” time to think about the problem you’re solving and how to do it.
As a consequence of this future release date, we can use all the iOS 13 specific APIs right now and this includes SwiftUI.
Our app is a sort of video player with on-screen controls and a bunch of UI for editing content or settings. Most of our on-screen controls are likely to use UIVisualEffectView for system blurs, vibrancy and materials. This sadly means we can’t seem to use SwiftUI for this because of issues with nesting views inside the effects views and SwiftUI not supporting materials or vibrancy yet.
However since the Xcode 11 beta which added support for SwiftUI forms, the main editing and settings UI have turned out to be a brilliant candidate for SwiftUI. Especially so because we will want to build up many different variations of some of this UI based on the user’s content. SwiftUI should make this really easy because we can conditionally include UI elements easily in code.
This approach has already allowed us to quickly prototype the UI and prove out possible navigation controller issues we were concerned about. I also learned something I never fully understood about UINavigationController — namely that no matter what nesting level a view controller is, if it pushes something new onto the navigation stack, that nested view controller’s navigation item is used for Back navigation. This is really smart and very handy — and amazingly is supported with SwiftUI code that sets navigation bar titles, even when nested inside a UIKit UINavigationController and another child UIViewController. Go SwiftUI team!
Obviously all things SwiftUI are still very rough, but we found a part of the app where SwiftUI will give us a great deal of productivity and reduce code while minimising risk. In the unlikely event it doesn’t work correctly, it has been so easy with SwiftUI that we won’t lose much if we then have to write it in UIKit.
One very painful problem with SwiftUI has been that at the time of writing, it seems impossible to run SwiftUI previews that are inside a framework of your own or in an app containing certain frameworks — the preview process crashes with what look like Thread Sanitizer related issues. We have to run previews in a separate project with no dependencies as a scratchpad.
I’ve raised Feedback of course (FB6962455 “SwiftUI preview canvas crashes when adding a framework to an app”).
