I'm with you. Is there a tangible app example?

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.

This allows you to expose either a view or a function in your app to be shown/executed in another app.

so will I finally be able to open a link in one app that opens in another app and not in safari?

You can do that since iOS 14 (sept 2021) https://support.apple.com/en-us/HT211336

What I want (as a user, not a developer) is to be able to force an app to open links in Safari, not the app's built-in webview, and to force links to certain URLs to open in the app of my choosing, not Safari (in that case).

This is really, really basic stuff. Why don't we have this capability?

Ahh.. I see. Yeah, that's structurally unlikely to happen any time soon on iOS. "open a link" is not a shared idea across apps. In one app that'll be a webview, where the OS could get involved. In another app it'll just be a button - the OS doesn't know if that button is perceived by the user as a "link" or not.

So I think it'd have to be an app-review policy, and I suspect they'd have a LOT of pushback if they tried to enforce something like that.

They could have structured the OS so that each transition to a new view was a request to the operating system to open a URL, and the OS handled the routing to the browser, this app, a different app - but without that kind of a structure I don't think this very doable.

> What I want (as a user, not a developer) is to be able to force an app to open links in Safari, not the app's built-in webview

In some cases apps use the browser to render the app's UX, via hooks added to the browser to invoke native code (e.g. to expose native platform functionality that is not web accessible). This web content may only exist within the app sandbox's filesystem, or may be externally hosted.

But from a systems API standpoint, this is no different from Facebook opening links in their own internal browser so they can glean metrics on what links you are following.

So what you are talking about is actually a store policy (e.g. apps without the browser entitlement must open third-party web content via this other mechanism).

> and to force links to certain URLs to open in the app of my choosing, not Safari (in that case).

For HTTPS in general, IIRC the user can select from a list of apps with the browser entitlement.

Apps can already opt into their own HTTPS URL support for several years via Universal Links - but they have to get the domain owner to allow it to prevent abuse. They've been able to take over URI schemes outside of a reserved list since the App Store launched.

The android equivalent system (App Links IIRC) allows non-affiliated apps to take over certain HTTPS URL function, but the user has to enable it in settings - and will get a chooser if multiple applications can support the interface.

Not really. You can do that for web, or email, or maps, but for the most part - and especially with third party apps for things like Reddit, or Twitter - you're forced into opening links in Safari. You MAY be given the option to open the link in an app once opening in Safari but in my experience it doesn't always work.

It's fundamentally a worse experience than it is on Android, in every way.

How is this different from bundles/dylibs?

What are you asking specifically?

If you want a feature comparison, list what you know about bundles/dylibs to start...

From what I know, dylibs is for including 3rd party code at build time, maybe a client to consume an API.

ExtensionKit allows you to expose realtime UI or information, going through the installed app instead of a 3rd party service.

That way you don't have to expose your API or build an SDK. You just have functions in your app that expose it. Also that information is only provided if the user has that app installed. So the experience is curated.

> Dylibs is for including 3rd party code at build time

Nope. You can decide how and where to load and call entirely at runtime. Check out manpages for dlopen, dlsym.

I don't know anything about this new feature of Apple's, but knowing the way they've been going for the last decade and change I would guess the unique thing is around sandboxing, out of process calls, etc.

Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.

I hate to be that guy, but isn't this an Android feature?

As iOS user I couldn’t care less if it was.

Extension points have existed for much longer than Android has. The Mac has had them since at least system 6 (1988). Photoshop has had them since version 2.0 (1991)

This is not correct. That's not an Extension Point. That's a plugin interface. Extension Points are a type of plug-in, but have the specific feature of not running in the host application's address space meaning that many types of bugs and security attacks are not possible. For example, if an Extension Point dereferences NULL, it will crash, but the host app can restart it and reconnect without losing any data. If a Photoshop plug-in dereferences NULL, Photoshop crashes.

Ah, yeah, that's an interesting distinction I hadn't thought of. Any idea what the first example of that type of extension was? My gut says that'd still been done long before android

IPC has been a systems feature for a while, but discovery is a higher level thing needed for this sort of plugin interface. COM and CORBA are ancestors I know about.

not any more than a filesystem is an "Android feature" because Android also has a filesystem API.

Such APIs have been around since the 90s, if not earlier. MS OLE, OpenDoc, Classic Mac's "Publish and Subscribe" API, I'm pretty sure OpenStep had something similar (which would be Apple's IP today, and predates Android by half a millenium).

I still don't get it. Can anyone provide an example how this could work in practice? Is there something like this in Android already?

It’s already used in many apps. For example, in the imessage app, you can tap the apps icon to show a drawer of all the extensions which are available. For example you have an extension of photos app available which lets you send photos in iMessage.

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.

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.

At first glance, looks like the apple version of COM/COM+/OLE.