They have a ton of different products and APIs and they just don't document them all. Even worse, much of the documentation they do have is hidden inside hard-to-search WWDC session videos or, ugh, Slack conversations with Apple engineers.

External developers have complained for years. [1]

[1]: https://www.caseyliss.com/2020/11/10/on-apples-pisspoor-docu...

At this point I'm starting to believe that Apple begrudgingly accepts that people outside that UFO that landed in Cupertino should be granted the privilege to develop applications for their hardware.

You'd think with nearly a trillion in cash, they'd be able to hire some full-time technical writers.

The only reason I was able to figure out how to use ExtensionKit at all was because of a chance encounter with an Apple engineer during WWDC that provided some needed information.

I'm sorry to disappoint, but ExtensionKit/Foundation do not make use of any Swift features in the way you describe. It's all just IPC (via XPC), so much of it is useable from ObjC, or even C!

Also, this does not provide a direct app-to-app communication channel. The extensions themselves must be separate executables and run within their own sandbox. I think the extension could communication with its containing app, but the system is not set up to do that. All your scheduling questions are really around how XPC works. The view itself is basically an image within your hosting app, so communication is entirely async to the other process.

> I think the extension could communication with its containing app, but the system is not set up to do that.

and on iOS, the containing app is likely not running (in a GUI context).

Typically, the extension is its own small program bundled within the app. The app can be run by an end user, while the extension can only be invoked via the extension mechanism.

Same thing on macOS. The containing app does not need to be running for the extensions to be active. You are right that the extension bundle can only be used by this mechanism, but interestingly the containing app can use its own extensions (though this may not make sense in many cases).

That's sad that it has a serialization layer. It makes sense, but it's not ideal or more performant than existing techniques.

I'm more interested in the extension handling after that IPC layer, it's usually non trivial to integrate the call into an existing app's threading model.