Comment by duped | Hacker News Reader

Comment by duped | Hacker News Reader

I'd like to take this moment to call out how atrocious Apple developer documentation is. This is honestly embarrassing. I would reject contributions at my company that shipped APIs/headers with this caliber of documentation. People who do it regularly get bad performance reviews.

I don't know if it's because they actually hate developers, or they're just bad developers themselves.

---

More on topic, this is an interesting approach to a tricky problem that exploits one of Swift's strengths (a stable ABI) and Apple's tight integration across the system (standardized app installation/structure/store/etc). You expose some functions as an extension/plugin API and other apps can just call them. Neat! IPC kind of sucks!

What could use some more discussion is how if you have two apps running and calling eachother (or being called from eachother), how does that affect the threading model? Are calls scheduled to happen later on the main UI thread, or are they actually coming from a separate process and you need to worry about synchronization if that call affects any kind of state?

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.

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.

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

Reply on news.ycombinator.com