Using main.swift entry point for iOS, iPadOS and tvOS platforms

The context is partially expressed in an earlier post.
In summary: There is an iOS App target that contains minimal code, only to load a Framework explicitly at runtime using dlopen and dlsym, instead of the usual load-time imports in Apple platforms.

For iOS app (C++ (primary) and Swift), the entry point is a UIApplicationDelegate conformer class - AppDelegate, marked with @main. But the problem is, the AppDelegate class cannot remain in the App target, which has barely any logic. The App target is a thin loader. The AppDelegate contains some methods such as application(_:didRegisterForRemoteNotificationsWithDeviceToken:) that needs some logical processing, which is not present in the App target. Instead of using dlsym (to hand over to the Framework) for every AppDelegate event that doesn't have a broadcast notification, the thought was to move the AppDelegate class into the Framework, and the entry point in App target is now main.swift. This keeps the Framework clean and minimal with the following steps:

  1. Interop to C++
  2. Explicitly loading the MachO binary inside the Framework using dlopen
  3. Loading the symbol using dlsym
  4. Invoking the Framework entry point

Then, the Framework entry point in C++ creates the UIApplication class and the UIApplicationDelegate using UIApplicationMain(_:_:_:_:) method, which doesn't return as it transfers control to the UIApplicationDelegate. This is against the recommended @main entry point, but based on research, @main seems like syntactic sugar to avoid writing boilerplate code. But in my case, which needs to avoid instantiating the UIApplicationDelegate in the App target, using main.swift, even for an iOS app, is the best fit. I understand that main thread has to be returned back to the OS asap for processing user events etc., and the intent is to not execute the entire startup logic of the app in main thread.

Wanted to confirm if this approach of using main.swift entry point is valid for iOS, iPadOS and tvOS apps too and in which case, these flows can converge to macOS, which is already using main.swift approach.

Answered by DTS Engineer in 895218022

It’s fine for iOS apps to use a main.swift that calls UIApplicationMain(…). Likewise for its ‘child’ platforms, include iPadOS [1] and tvOS.

Having said that, this isn’t something I recommend. As I explained in your other thread, your overall approach contains significant drawbacks today, and it wouldn’t surprise me if that situation got worse in the future [2]. You are ‘fighting the framework’ [3] here, and that’s not a good idea in general.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Which isn’t really a platform, in that it uses the same SDK as iOS.

[2] For example, it’d be interesting to see if this approach benefits from the significant app launch improvements we’ve made in iOS 27 (currently in beta).

[3] Well, and the tooling.

It’s fine for iOS apps to use a main.swift that calls UIApplicationMain(…). Likewise for its ‘child’ platforms, include iPadOS [1] and tvOS.

Having said that, this isn’t something I recommend. As I explained in your other thread, your overall approach contains significant drawbacks today, and it wouldn’t surprise me if that situation got worse in the future [2]. You are ‘fighting the framework’ [3] here, and that’s not a good idea in general.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Which isn’t really a platform, in that it uses the same SDK as iOS.

[2] For example, it’d be interesting to see if this approach benefits from the significant app launch improvements we’ve made in iOS 27 (currently in beta).

[3] Well, and the tooling.

Using main.swift entry point for iOS, iPadOS and tvOS platforms
 
 
Q