iOS 9

[irace]

⚠️ Preliminary thoughts! Please take this with a grain of salt as I haven’t thought about it for long enough to feel like I have my head fully wrapped around it. ⚠️

To try and determine what modifications we may want/need to make to XExtensionItem in the short term, I think it’s worthwhile to consider how we’d want the library to function if we only needed to support iOS 9.

XExtensionItem for iOS 8 has two goals:

• Support multiple attachments (obviated by iOS 9)
• Support metadata parameters (still useful on iOS 9)

Therefore, XExtensionItem usage on iOS 9 only could look something like the following:

// Application

// `XExtensionItem` no longer wraps your attachments, instead it’s just an additional metadata object
[[UIActivityViewController alloc] initWithActivityItems:
 @[@"Apple homepage", [NSURL URLWithString:@"http://apple.com"], xExtensionItemSource] 
                                  applicationActivities:nil]

// Extension

// Rather than treat *every* item as something that can be wrapped by an `XExtensionItem`, just specifically look to see if one was passed in
for (NSExtensionItem *item in self.extensionContext.inputItems) {
    if ([XExtensionItem isXExtensionItem:item]) {
        XExtensionItem *xExtensionItem = [[XExtensionItem alloc] initWithExtensionItem:item];
        // Access tags, app attribution, custom application parameters, etc.
    }
    else {
        // Process regular, non-XExtensionItem item
    }
}

Ideally, we’d release what we currently have (let’s call it 1.0) and add a section to the README documenting how we envision the library changing in order to eventually better support iOS 9 exclusively. Then at some point we cut a new release for developers who only support 9 (let’s call this 2.0), and those who continue to support 8 can just use the older version.

But the problem here is interoperability. An application that uses XExtensionItem 1.0 (e.g. provides a single XExtensionItem instance as their lone activity item) wouldn’t be compatible with an extension that uses 2.0 (I need to think about it a little more but I think an app that uses 2.0 will still work just fine with an extension that uses 1.0).

How can we resolve this? It seems as though modifying the extension-facing API to support both types of input is the most future-proof course of action. Otherwise, we’d have to either:

• Go iOS 9 only and not be useful to anyone who needs to support iOS 8 for a while still (bad option, almost no one will use this)
• Forget about changing the library in the future to better mesh with how activity items work in a post-iOS 9 world (makes this library very useful in the short term but more annoying to use than it needs to be post-iOS 9)

@mattbischoff @prendio2 @AriX

[mbbischoff]

How can we resolve this? It seems as though modifying the extension-facing API to support both types of input is the most future-proof course of action

I haven’t watched the session yet, but I did read your notes on it. This seems like an appropriate, if slightly inelegant way to go. I like a lot better than either of these...

• Go iOS 9 only and not be useful to anyone who needs to support iOS 8 for a while still (bad option, almost no one will use this)
• Forget about changing the library in the future to better mesh with how activity items work in a post-iOS 9 world (makes this library very useful in the short term but more annoying to use than it needs to be post-iOS 9)

[irace]

I actually dreamt about this last night. How sad is that?

I think on the extension side, we’d want our custom class to wrap the extension context rather than an individual item. We would no longer be providing a cleaner API on top of NSExtensionItem on the extension side, but we’d be able to provide a uniform API – an array of NSExtensionItem instances and some metadata – regardless of if the input was structured the old way (one XExtensionItemSource) or the new way (a bunch of raw input items plus one XExtensionItemSource.

The new class would look something like this:

@interface XExtensionItemContext : NSObject

/**
 @see `NSExtensionContext`
 */
@property (nonatomic, readonly) NSArray/*<NSExtensionItem>*/ *inputItems;

/**
 @see `XExtensionItemSource`
 */
@property (nonatomic, readonly) NSArray/*<NSString>*/ *tags;

/**
 @see `XExtensionItemSource`
 */
@property (nonatomic, readonly) XExtensionItemReferrer *referrer;

/**
 @see `XExtensionItemSource`
 */
@property (nonatomic, readonly) NSDictionary *userInfo;

/**
 Inialize a new instance with an incoming `NSExtensionContext`.

 @param extensionItemContext Extension context.

 @return New instance populated with the extension context.
 */
- (instancetype)initWithExtensionContext:(NSExtensionContext *)extensionContext NS_DESIGNATED_INITIALIZER;

@end

Title and attributed content text would no longer be something that XExtensionItem concerns itself with, since it would now be augmenting one or more NSExtensionItem instances, rather than expecting to be used in place of them. In short, I think this makes the API slightly less nice in the short term but much more future-proof.

I have an in-progress branch that makes these changes that I’ll happily link to from this issue once I’ve got it a little further along. In the meantime, feedback welcome!