Forem: matsuji

An Anti-Pattern to get UIWindowScene

matsuji — Mon, 18 Nov 2024 13:00:50 +0000

Starting with iOS 13, UIWindowScene was introduced, and it is often required in cases such as showing a review request for the App Store.

When it comes to obtaining UIWindowScene, incorrect implementations are often shared on platforms like Stack Overflow.
In this article, I will share the incorrect implementations, their issues, and the correct one.

The Common Incorrect Pattern

This is an incorrect example that I often encounter.

let windowScene = UIApplication.shared
    .connectedScenes
    .compactMap { $0 as? UIWindowScene }
    .first

This code extracts UIScene from UIApplication, casts it to UIWindowScene, and uses the first one.

If you are not familiar with Scene, the code seems to work well, and you may adopt this pattern without understanding it well.

What is An Issue?

The most obvious issue is that the code does not account for multiple windows in iPadOS and visionOS.
The type of connectedScenes is Set<UIScene>, which contains UIWindowScene objects corresponding to each window.
It means that if a user makes multiple windows, window A and window B, connectedScenes has window A and window B.

// Image
connectedScenes = [
    (UIWindowScene of window A),
    (UIWindowScene of window B),
]

In this case, if you adopt the incorrect implementation shared above, the implementation may return UIWindowScene of window A even if you need UIWindowScene of window B.

You may need a UIWindowScene that the user is touching, but there are no APIs filling such requirements.
I sometimes found the following implementations which checks activationState, but it is also incorrect because multiple UIWindowScenes can become foregroundActive at the same time when multiple windows are foreground in iPadOS and visionOS.

let windowScene = UIApplication.shared
    .connectedScenes
    .compactMap { $0 as? UIWindowScene }
    .filter { $0.activationState == .foregroundActive } // check activationState
    .first

Is the above code fine if we give up multiple windows in iPadOS and visionOS?
The answer is NO.
Multi windows can be possible even though in iOS.
When an iPhone is connected to an external display, the UI in the external display is on another UIWindowScene which is made newly.

If your product doesn't support iPadOS, visionOS and an external display and you really need the above code, it seems fine to use it for now.
However, note the above code is one of hack ways and it can work well only on the current iOS.
The code may not work well in the future iOS and you should evaluate whether the risk can be accepted or not.

Correct Implementations

UIKit

The easiest way is to get a UIWindowScene from a UIView.

let windowScene = view.window?.windowScene

That's all!
Note that window is nil until the UIView has appeared.
On viewWillAppear, the window is nil and the value is set from viewIsAppearing.

SwiftUI

If you use SwiftUI, you can extract UIWindowScene from EnvironmentObject.

Define AppDelegate and SceneDelegate
Connect AppDelegate and your App.
Make SceneDelegate conform to ObservableObject
Capture UIWindow in SceneDelegate.
Get SceneDelegate by EnvironmentObject and get UIWindowScene from the SceneDelegate

@main
struct FlashcardsApp: App {
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

    var body: some Scene {
        ....
    }
}

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {
        let configuration = UISceneConfiguration(name: nil, sessionRole: connectingSceneSession.role)
        configuration.delegateClass = SceneDelegate.self
        return configuration
    }
}

class SceneDelegate: NSObject, UIWindowSceneDelegate, ObservableObject { // Make SceneDelegate conform ObservableObject
    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        self.window = (scene as? UIWindowScene)?.keyWindow
    }
}

struct YourView: View {
    // SceneDelegate is automatically set if it conforms to `ObservableObject`
    @EnvironmentObject var sceneDelegate: SceneDelegate
    var windowScene: UIWindowScene? {
        sceneDelegate.window?.windowScene
    }
    ...
}

Wrap Up

Please avoid incorrect implementations using connectedScenes which are shared in many places, because they are a hack.
The simplest and correct way is to get UIWindowScene from a UIView.

Tips | Effortlessly Presenting UIViewController in SwiftUI

matsuji — Sun, 10 Nov 2024 15:32:28 +0000

This article introduces tips for presenting UIViewController in SwiftUI.
While this might seem trivial, I’ll share the technique as there are no articles currently explaining it.

A Common Pattern Using UIViewController in SwiftUI

In general, UIViewControllerRepresentable is used when UIViewController is needed in SwiftUI.

struct FooView: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> FooViewController {
        FooViewController()
    }

    func updateUIViewController(_ uiViewController: FooViewController, context: Context) {
        // Update the view state
    }
}

This is a straightforward implementation, but it's a bit cumbersome to define a new subtype of UIViewControllerRepresentable for each UIViewController.
And it's also a bit cumbersome for me to name the subtype.

Use Generics

To solve the issue, define a generic type.
This is an implementation example.
The code is a bit long, but closures corresponding to each function of UIViewControllerRepresentable are just injected.

public struct UIViewControllerRepresenter<ViewController: UIViewController, Coordinator>: UIViewControllerRepresentable {
    private let makeCoordinatorHandler: @MainActor () -> Coordinator
    private let makeUIViewControllerHandler: @MainActor (Context) -> ViewController
    private let updateUIViewControllerHandler: @MainActor (ViewController, Context) -> Void
    private let sizeThatFitsHandler: @MainActor (ProposedViewSize, ViewController, Context) -> CGSize?

    public init(
        makeCoordinator: @escaping @MainActor () -> Coordinator = { () },
        makeUIViewController: @escaping @MainActor (Context) -> ViewController,
        updateUIViewController: @escaping @MainActor (ViewController, Context) -> Void = { _, _ in },
        sizeThatFits: @escaping @MainActor (ProposedViewSize, ViewController, Context) -> CGSize? = { _, _, _ in nil }
    ) {
        self.makeCoordinatorHandler = makeCoordinator
        self.makeUIViewControllerHandler = makeUIViewController
        self.updateUIViewControllerHandler = updateUIViewController
        self.sizeThatFitsHandler = sizeThatFits
    }

    public func makeCoordinator() -> Coordinator {
        makeCoordinatorHandler()
    }

    public func makeUIViewController(context: Context) -> ViewController {
        makeUIViewControllerHandler(context)
    }

    public func updateUIViewController(_ viewController: ViewController, context: Context) {
        updateUIViewControllerHandler(viewController, context)
    }

    @MainActor
    public func sizeThatFits(_ proposal: ProposedViewSize, uiViewController: ViewController, context: Context) -> CGSize? {
        sizeThatFitsHandler(proposal, uiViewController, context)
    }
}

Usage

Just use the type when you want to present UIViewController in SwiftUI.
You don't need to define new types.

struct BarView: View {
    var body: some View {
        UIViewControllerRepresenter { _ in
            FooViewController()
        }
    }
}

In a case where a coordinator is required or you need to do something on update, closures for them can be injected.

struct BarView: View {
    var body: some View {
        UIViewControllerRepresenter {
            FooCoordinator()
        } makeUIViewController: { context in
            let viewController = FooViewController()
            viewController.delegate = context.coordinator
            return viewController
        } updateUIViewController: { _, _ in
            print("updated")
        }
    }
}

class FooCoordinator: FooDelegate {
    // ...
}

Note

This way is just for omitting of type definition and it doesn't cover all use cases.
For example, since the dismantleUIViewController function in UIViewControllerRepresentable is static, this method doesn’t cover cases where that function is needed.

Wrap up

In this article, I introduced a technique for effortlessly presenting UIViewController in SwiftUI.
This approach doesn’t cover all use cases, but it’s a powerful utility.
I hope this article can help your development!