▲ 141 points
back
86 comments
Before ExtensionKit you could only make app extensions to extend the functionality of Apple provided systems. Things like authentication, file sync and badging in the Finder, Xcode text editors, or Final Cut Pro editing extensions. With ExtensionKit you can make your own extension points and let people develop extensions for your apps on all Apple platforms.
The code editor Chime just released extension support in their 2.0 release if you are on macOS 13. They have a lot of good details on how the implemented the feature on their blog. https://www.chimehq.com/blog/extensionkit-intro
Application extensions outside the Apple ecosystem have been used on Apple computers for decades. It was never limited to Apple provided systems, whatever that means.
ExtensionKit is for the new facility to extend the UI. Non-UI extensions only need ExtensionFoundation.
For example extensions on macOS, go to system preferences and search for extensions. They're listed by affording context (e.g., Finder, Photos Editing). Mine include pdf conversion, cropping photos, etc. You can create your own via Automator.
The docs imply that before Ventura (13.0), developers had to create a property list to declare NSExtension, but now you can do it in Swift. However, the TextTransformer sample has the usual melange of metadata, and there's no deployment information in the API documentation.
Ideally, a simple swift script would be sufficient :)
To offer another take at a summary:
Apple has offered App Extensions for several years, in both UI-serving and non-UI contexts. App extensions are secondary services, bundled within apps, to provide some service. These extensions are invoked in their own process space, typically in the containing application's sandbox.
Examples include:
- The contents of the action/share menu in apps, which for example lets you share photos onto social media
- Audio Units
- Photo plugins
- Password manager autofill
- Content blockers
- Custom keyboards
- Filesystem providers to have a cloud storage show up in the Files app
- Finder synchronization for cloud-synchronized services like OneDrive
- All app integrations to extend Siri
ExtensionKit (and the underlying ExtensionFoundation) lets a host application define its own extension points, which other applications can provide. I do not believe you can define n-to-m extensions with this interface however; I can create a language server for an iOS text editor and put it in an app, but I can't do that once and support _every_ text editor.
This is the functionality that enables Live Activities in iOS 16.1. For example showing the score for an ongoing sports game on the Lock Screen.
That's a different API https://developer.apple.com/documentation/activitykit
Did the headline make anyone else think we were going to see system extensions again?
Sample code (not from Apple): https://iosexample.com/apple-extensionfoundation-extensionki...
> However, Apple’s documentation lacks crucial information on how to use these new APIs (FB10140097), and there were no WWDC sessions or sample code available in the weeks following the keynote.
> Thanks to some trial and error, and some help from other developers, I was able to put together this sample code, demonstrating how one can use ExtensionFoundation/ExtensionKit to define custom extension points for their Mac apps.
Christ
Is there any context, e.g. a press release, for people unfamiliar with the apple dev environment?
This Apple ExtensionKit documentation page opens with "Extensions are executable code bundles" but doesn't provide any executable code bundles such as examples, doesn't provide any way for a developer to ask a question, and doesn't show how a developer learns to create an extension.
This misses opportunities to reach developers-- and the tech is actually really compelling. I'm experimenting with it in the BoldContacts app, which conceptually extends the Contacts app to give disabled people ways to contact their families and caregivers.
Apple's documentation group needs a new leader ASAP who can emphasize documentation usability in concert with real-world developers. Apple wants its platform to continue being successful, and this goal can be helped by a documentation team that creates examples, questions-and-answers, and tutorials.
Totally agree.
Apple’s API documentation is nearly useless because it usually doesn’t give me any info that I can’t already infer from my IDE (which of course is XCode, sigh).
I usually don’t need a list of classes and methods, I need to know how the pieces fit together to do something useful.
They say a picture is worth a thousand words. Well, an example is worth a thousand method signatures.
> doesn't provide any way for a developer to ask a question
If you ask questions on the developer.apple.com forums, Apple engineers often answer them directly. At least that has been my experience.
I think this is by design. Apple wants to weed out non-loyal developers, so only the ones who truly love the platform build software for it. Unfortunately, it drives developers to use cross platform tech instead, which apple hates
> … doesn't provide any way for a developer to ask a question, and doesn't show how a developer learns to create an extension
Is this because programming that targets poorly documented APIs is taught at select universities, and Apple wishes for these new grads to have an upper hand?
They really love the Kit suffix, eh?
Consistent naming patterns help devs navigate the hierarchy of libraries/frameworks/APIs available.
CoreFoo is going to be a low level library for dealing with Foo. FooKit is going to be a high level way to create gui apps that deal with Foo. Likely FooKit uses CoreFoo under the hood.
They inherited "AppKit" and "Foundation" from Next and they have been running with that naming convention ever since.
Why not? No different to the unix lib prefix
It's a NeXT legacy, and it's a mighty fine and nice sounding one, so why not?
I do not understand what this actually does, has anyone got a better example? :)
This allows you to expose either a view or a function in your app to be shown/executed in another app.
One example that I use often — the Photos app on Mac has a built-in editing interface, but also supports extensions that allow third-party apps (e.g. Affinity Photo and Pixelmator) to take over that whole UI and present their editing UI inside the Photos app.
One potential use of for allowing "plugins" in an app (the host app exposes the extension points for others to hook into), where other apps can integrate with that app, within that host app's own views. This is different than existing extensions, which basically only shuffle data mostly one way, and always outside of the app that it is initiated from.
This framework is cross-platform, so it would offer such a plugin architecture on both macOS and iOS.
There's no hints that Apple would offer this kind of integration within their own apps however.
I don’t know if this can be implemented but I wish it was. I have the Word app on iOS. Now, a citation manager like Zotero could allow importing references into Word through this API. You click a button in Word and that brings up a dialog for selecting references stored in Zotero app.
I wish Apple docs would include examples. I'm not an Apple developer but I've played around with SwiftUI and they have fantastic examples.
I'm with you. Is there a tangible app example?
At first glance, looks like the apple version of COM/COM+/OLE.
Is this a new form of IPC ? https://en.wikipedia.org/wiki/Inter-process_communication
If not, what IPC is this using behind the hood ?
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...
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.
You'd think with nearly a trillion in cash, they'd be able to hire some full-time technical writers.
Still lacks proper documentation (like, vital details still missing). So obviously not a serious feature yet.
This fact has been reported multiple times before[1][2][3], and it's frustrating that a company that claims having over 1000 engineers, and touts its $6B campus at every opportunity in every one of its keynotes has, evidently, not enough resources for proper documentation.
[1]https://news.ycombinator.com/item?id=33411242 [2]https://news.ycombinator.com/item?id=33410300 [3]https://news.ycombinator.com/item?id=33410329
I object to that. Some of Apple's most serious features are missing vital documentation details!
As a total noob studying Swift and SwiftUI documentation I was wondering about this. But I couldn't believe this huge company would neglect their developer community like that. But as I delved deeper I found everything is beautiful on a surface level and beyond that suddenly there are no standards.
>Still lacks proper documentation (like, vital details still missing). So obviously not a serious feature yet.
Those two things are completely orthogonal tho... an API/tool/service can even be used to build billion dollar businesses and not have proper documentation...
Maybe there is a market for complete, comprehensive documentation by a 3rd party? Something similar to "definitive" programming books of the past, but web-based / searchable and maybe importable into IDEs.
This fact has been reported multiple times before
That seems like a really good reason not to post it again as a toplevel comment.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The dream of COM is alive in Cupertino!
OpenDoc would be more relevant to Apple: https://en.wikipedia.org/wiki/OpenDoc
COM has been alive for quite some time, not only does Taligent and Copland ideas precede it (the IDL is lously based on DCE/RPC), similar ideas are used in the IOKit, DriverKit and XPC.
Not really? The example for Messages seems very specific; closer to an API for Messages.app than a generic process interop framework.
They at least decided to go with a sane language instead of C++
Also is it really COM like? it doesn't look like it
EDIT: