While iOS extensions are similarly considered components of a containing application (they are bundled together and cannot be deployed separately), their execution model is different than Android. iOS launches extension components into a separate (i.e. third) process from both the containing application and the calling application making the request (called the “host” by Apple).
Alongside an Intent’s destination definition (via an implicit action, explicit class name, etc.), the filter scope can further narrow by referencing a custom data type that is only known to a private suite of applications. Currently in iOS,
NSExtensionItemdata returned from the extension can provide unique type identifiers, but the same is not true for data passed forward to an extension; identifiers are inferred from the type of data passed in (rdar://17217209).
This is important because iOS, via the
NSExtensionActivationRulein the Info.plist, determines when and where to show a custom action extension by comparing the input items passed to the
NSPredicate. By limiting the scope of input items to standard data types, it becomes difficult to create more targeted actions that only respond to special data.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.