It will happen once in a while, when using an iPhone or iPad, a person may get an email with an attachment to be opened, but can’t because there is no app on the device to open it. Or similarly, surfing the web using the Safari mobile browser, and suddenly there is a file to be accessed/downloaded but it isn’t supported in Safari on iOS.
And for app creators/developers, we solve this issue by allowing our apps to open those types of files, to make up for the lack of Apple having an app that does so.
There is much info around the internet about this, but mostly the info is about supporting custom file types (for random example: .my3dimage) it all comes up short for supporting public file types. I mean, types of files that are out there in the world, but the iPhone doesn’t have an app that supports them. A really obvious case is PDF files. They used to be not supported, but now they can be viewed in Mail or Safari. One popular type that is not supported in mail or is the zip file type.
An app developer simply adds the CFBundleDocumentTypes key to the app’s Info.plist file, and fills it in with info, and then builds the app to handle the file when another app tries and fails to open a file.
CFBundleDocumentTypes is an Array of Dictionary objects. Each dictionary has a set of keys (and values) and following is a list of recommended keys from Registering the File Types Your App Supports in Document Interaction Programming Topics in the iOS developer library:
CFBundleTypeName specifies the name of the document type. (ie. Zip archive)
CFBundleTypeIconFiles is an array of filenames for the image resources to use as the document’s icon. (could be a picture of a folder with a zipper, like Windows Explorer uses, or anything else)
LSItemContentTypes contains an array of strings with the UTI types that represent the supported file types in this group. (an array of the UTI types.. this is the confusing part for quickly supporting public types that I deal with in a moment).
LSHandlerRank describes whether this application owns the document type or is merely able to open it. (This is another interesting part that I talk about)
More can be added (and SHOULD be added), and they’re found in Table 2 Keys for type-definition dictionaries, of the CFBundleDocumentTypes section, in the Core Foundation Keys page of iOS Information Property Key Reference. But BEWARE! Several of these keys are not for iOS, but Mac OSX, and some are deprecated, while still remaining in the list.
There is more information on the meaning of each specific value that can be assigned to each key. Check out below Table 2, in CFBundleDocumentTypes section, for Document Roles and Document Icons.
After Document Roles and Document Icons sub-sections, is a relatively section of some importance, Recommended Keys. I say “some” importance because it’s a very important section naturally, but contains out-of-date recommendations. This list contains 1 valid key for iOS and 3 that are Mac OSX only, plus those 3 are deprecated:
LSItemContentTypes
CFBundleTypeExtensions (not in iOS)
CFBundleTypeMIMETypes (not in iOS)
CFBundleTypeOSTypes (not in iOS)
The following are strongly recommended, but optional:
CFBundleTypeIconFile
CFBundleTypeName
CFBundleTypeRole
These 7 recommended keys, partly overlap with the 4 I listed above from the Registering the File Types Your App Supports section. The overlapping items are:
LSItemContentTypes
CFBundleTypeName
It can be confusing then, which to use… I think this is just a case of some instructions not being updated with the latest best-practices. So try support as many non-deprecated keys as possible!
Now for a list of the strings that can go into the all-important LSItemContentTypes section:
System-declared Uniform Type Identifiers (UTIs)
The table on this page lists a whole bunch of system and public file types that aren’t necessarily supported in the iPhone or iPad. Zip is in the list, and happens to have the com.pkware.zip-archive valiue.
I won’t discuss the icon, but please see Document Icons within Custom Icon and Image Creation Guidelines for info about them.
Info about the Role is in iOS library.
There is a possible issue with the Rank, if two apps declare themselves as the Owner of a type, then one of them is given precidence for the button that appears on the right-side in Mobile Safari, as seen in this picture:
I don’t know much about dealing with this yet, but it should not be a huge problem because a user can click on the “Open In..” button and see other apps that open it, like in the following picture:
Hope that helps someone.
