openURL a local file or force UIDocumentInteractionController to use a specific app

Question

I wish to open a file (stored locally in my app) with another app.

Currently, I am using openURL (there is a dedicated url scheme), and it works fine if I use a file hosted on the internet, but I would like to use a local file so: a) it works offline b) a lot of the time my users are either out of cell zone coverage, or roaming internationally

What I have tried so far: I have not had any luck telling openURL to use a local file, I have tried a few approaches but they are all something like this

      NSString *filePath = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"ext"];
      NSURL *fileURL = [NSURL fileURLWithPath:filePath];
      [[UIApplication sharedApplication] openURL:fileURL];

also

      NSURL *fileURL = [[NSBundle mainBundle] URLForResource: @"test" withExtension:@"ext"];
      [[UIApplication sharedApplication] openURL:fileURL];

also manually using strings with different variations of localhost/ and file:// and var/mobile etc paths

nothing works (for me anyway)

So, I looked around SO and came across UIDocumentInteractionController

I am able to use UIDocumentInteractionController to let the user open my local file with the other app - however it always present multiple options of other apps to use and for example, one of the other apps can be 'Dropbox'.

I do not want to let the user download (or upload technically) a copy of my file for their use in other ways. It contains data that I would prefer not to make so readily available.

When the file is opened by my intended app (not made by me btw) it does not allow any kind of saving or access to raw data.

I realize that by including the file in my app anyone who is serious about obtaining it will be able to, I just don't want to flash a big menu saying 'Here it is if you want your own copy to make derivative work from'

Ideally, I could use openURL but I think it is because of the 'sandbox' that the other app doesn't respond - in Android I use mode_world_readable to declare the file as readable by other apps (therefore placing it outside the sandbox, and it doesn't allow other apps to write to it, just read) - is there anyway of doing the same with iOS?

Otherwise, if I could force UIDocumentInteractionController to use a specific app and not present the menu - that would be fine too.

Similar question asked a while ago

Sorry about the long read, any help is appreciated.

Edit: I just received an answer from Apple Tech support and they told me that this is currently impossible (just after iOS 6 released)

Answer 1

Yes, you're limited because of the strict sandboxing on iOS. Here are some thoughts.

You can override the functionality of the UIDocumentInteractionController by instead subclassing QLPreviewController. You can then replace the standard bar button item that displays the "Open in" menu. Take a look at this post for one solution for subclassing QLPreviewController: QLPreviewController remove or add UIBarButtonItems

Of course, I believe the way inter-app sharing works is largely out of your hands. If an app has registered to be able to handle a certain type of file, it is going to display as one of the choices in the "open in" list whether you want it to or not. I don't believe you can filter which apps display in that list.

Here are two experimental ideas I've thought about but have never tried:

• You could base64 encode the data from the file you're trying to pass along--which just converts binary to text--and hand that off as part of the custom URL you use to launch the other app. Then the other app can base64 decode that same data back into binary. The down side there is that there is a limit to the length of the URL which means the "file" you're sending would have to be pretty small.

• Next, and I don't even know if this is possible, but I wonder if you could use some steganograhpy algorithm to embed the document data inside an image and then hand that off to the camera roll. Then, the other app could open the camera roll and decode the image back into the data again. ... Yeah. I know... obscure, but it might be fun to try to implement. ;-)

Not sure if any of that helps, but you did say "any help is appreciated". ;-)

Best regards.