5 ms·

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

by hunterb123 4y ago

krackers 4y ago
How is this different from bundles/dylibs?
- hunterb123 4y ago
  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, coming from an 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 can be invoked. Also the feature is only provided if the user has that app installed. So the experience is curated.
  - asveikau 4y ago
    > 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.
  - mattiemass 4y ago
    Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.
kidustiliksew 4y ago
I hate to be that guy, but isn't this an Android feature?
- deleted 4y ago
  [deleted]
- f6v 4y ago
  As iOS user I couldn’t care less if it was.
- kennywinker 4y ago
  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 isn't even new on iOS, since its been supported since 2015 in the form of AudioUnit plugins.
  - thewebcount 4y ago
    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.
    - kennywinker 4y ago
      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
      - dwaite 4y ago
        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.
- coldtea 4y ago
  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).
jaypeg25 4y ago
so will I finally be able to open a link in one app that opens in another app and not in safari?
- kennywinker 4y ago
  You can do that since iOS 14 (sept 2021) https://support.apple.com/en-us/HT211336 https://support.apple.com/en-us/HT211336
  - chongli 4y ago
    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?
    - kennywinker 4y ago
      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.
    - dwaite 4y ago
      > 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.
slowmotiony 4y ago
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?
- busymom0 4y ago
  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.

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

krackers 4y ago

How is this different from bundles/dylibs?

hunterb123 4y ago
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, coming from an 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 can be invoked. Also the feature is only provided if the user has that app installed. So the experience is curated.
- asveikau 4y ago
  > 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.
- mattiemass 4y ago
  Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.

kidustiliksew 4y ago

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

deleted 4y ago
[deleted]
f6v 4y ago
As iOS user I couldn’t care less if it was.
kennywinker 4y ago
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 isn't even new on iOS, since its been supported since 2015 in the form of AudioUnit plugins.
- thewebcount 4y ago
  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.
  - kennywinker 4y ago
    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
    - dwaite 4y ago
      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.
coldtea 4y ago
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).

jaypeg25 4y ago

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

kennywinker 4y ago
You can do that since iOS 14 (sept 2021) https://support.apple.com/en-us/HT211336 https://support.apple.com/en-us/HT211336
- chongli 4y ago
  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?
  - kennywinker 4y ago
    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.
  - dwaite 4y ago
    > 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.

slowmotiony 4y ago

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?

busymom0 4y ago
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.