I'm not 100% sure this is all accurate but:
It seems as though share extension predicates are a lot more specific than we originally thought. For example, if Instapaper declares support for only NSExtensionActivationSupportsWebURLWithMaxCount = 1, this means that activity controllers configured with a URL but also some other item types too, e.g. a string, won't show Instapaper.
So basically if you have multiple items in your activity items array, your controller will only show extensions that support all types. I imagine this would be extremely limiting, and as such, think the best option is to:
- Only include a single provider in your items array. The provider would have a placeholder of a single type that will be provided to any activity or extension that isn't specifically accounted for
- In the provider, specifically hardcode alternative item types for activities that need an alternative to the placeholder type:
- "Copy" activity could use photo data, if present
- "Mail" activity would get a string to use as the message body
This sucks because we're limiting how useful sharing from our app is if we only export a single data type. But I'm not sure that there's a way to be any more accomodating.
This is the behaviour I'm seeing (https://devforums.apple.com/message/1012526), and it seems very counterintuitive.
The way around it is for the extension developer to be super lenient about what they can be passed, which is what I'm having to do for now. It doesn't really work when you start to think about sharing both an image and a URL though, since the apps that can handle one will probably not be equipped to handle the other.
Edit: As @donahue says, for extensions that need to operate on a URL/webpage it seems best to set NSExtensionActivationSupportsText, NSExtensionActivationSupportsWebURLWithMaxCount=1 and NSExtensionActivationSupportsWebPageWithMaxCount=1, and deal with them something like this: https://gist.github.com/blork/3908619597ab4515941d