I have been using AirDrop for ages now to allow a document to be passed from/to iPhone users from within my App. The App generates a straightforward CSV file which is then AirDropped (or could be emailed too) to another machine, where my App can open it and import it (the UTI is registered for the csv file type). This has been working fine for a long time, but I now see that devices running iOS13 no longer list my App as being able to import the file. If I run the same code on iOS12.4 (or earlier) it works fine, but on iOS13.1 my App is no longer registered to receive the data. The device can AirDrop to another device perfectly, and provided the destination is not iOS13 the import works fine. Whenever the destination is iOS13 my App simply is not listed as being available to receive. I can't see what might have changed.
The info settings (that work perfectly up until iOS13) are:
I cannot see anything in the iOS release notes that would suggest this has changed at all. Can anybody help with this?
Since you and your app didn't invent the CSV file type, you should use a standard UTI for CSV and not invent your own.
This means you should use the Imported UTIs section to declare the CSV UTI. The Export UTIs section should only be used by new UTIs that are unique to your app.
Here is my Imported UTI for CSV:
Here is my Document Type for CSV:
I have no trouble sending CSV files to my app under iOS 13 with these in place.
Also keep in mind that under iOS 13, you may need to tap on the "More" icon at the end of the list in the share sheet to see your app (and possibly others) as a choice.
Related
As per the documentation, both UIDocumentPickerViewController and UIDocumentBrowserViewController can be used for importing documents outside an apps sandbox.
For selecting & importing a document from local document providers/cloud locations, which one for the above is best suited.Can i still use UIDocumentPickerViewController in iOS 11 ?
As per the following documentation Apple documentation for document picker , Before your app can use the document picker, you must turn on the iCloud Documents capabilities in Xcode and an iCloud container should be mapped to the appId.Is this mandatory if i'm only doing import operation ? I have tried using UIDocumentPickerViewController and it seems to be returning selected file path correctly even without the above mentioned entitlements.
You do not need the entitlement if you do not need your own iCloud container. If you just want to import files, you can use UIDocumentPickerViewController without adding an entitlement.
Yes, UIDocumentPickerViewController works on iOS 11.
The UIDocumentBrowserViewController has to be the rootview of your app, therefore from my experience you can't use within an existing APP and be part of a NavigationControl (you will not be able to get the back buttons properly). In these cases we need to use the UIDocumentPickerViewController. Hope this helps.
For debugging purposes I want to accept a JSON file from the Mac via drag & drop in the iPad simulator.
I implemented UIDropInteractionDelegate and can successfully accept drops from the iPad Files app. But ideally I'd like to accept drops directly from the Mac.
Right now, when dragging a JSON file into the Simulator, the Files app is opened and handles the drop.
I doubt it's possible but if someone has any idea (even private API, since it's for debugging only), please let me know.
You can accept dropped files in the iOS Simulator by configuring your app to open documents of type you want to import. You can do this via CFBundleDocumentTypes in your Info.plist, or by using the Info tab in your target's build settings. The UTI for JSON files should be public.json.
When you've configured your app to handle JSON files, simply implement application:openURL:options: in your app delegate to actually handle the drop.
My app works fine with iCloud, at least in terms of the metadataQuery locating documents in my app's container. I can open and save those documents and see them in iCloud Drive both in iOS 10.x and 11 (through the Files app).
But, when viewing them in iCloud Drive, tapping them does not launch my app, but rather displays a view that identifies the document (accurately) as a MyApp document. If I tap a Pages document, though, Pages is launched and the document opened.
What am I missing? Have I not set a preference properly?
Further, in iOS 11, if I Share->Add People, my document sends properly to the other iOS 11 device and the message that's sent uses my icon and identifies it as a MyApp document. But tapping that sharing message (in Messages) asks to open the document in Files rather than in MyApp, and does not place the file in the MyApp container, but one level higher where metadataQuery doesn't find it. The same sequence with a Pages document opens Pages and puts the doc into the Pages container. Again, Files is accurately showing my document's icon and identifying it as a MyApp document, but seemingly not connecting that to my app.
Does the explanation make sense? Any idea what I've not done right or am not understanding? Thanks for any insights!
Found the secret. The plist needs a property that allows it to receive a request to open the document. That property is LSSupportsOpeningDocumentsInPlace and it's a Boolean that defaults to NO but should be set to YES for the appropriate AppDelegate functions to be called. When I added that (I found it in the sample app ShapeEdit), tapping my app's doc in iCloud Drive launched the app and called the function with my code to open the doc.
I would like to create a NSPersistentDocument in Mac OS X and read this document as a UIManagedDocument on iOS 7.
Is this possible?
Are both file formats compatible?
Thank you!
Interesting question - I can confirm that the basic core data files are compatible. I have a Mac app and an iOS app using the same file that gets synced using iCloud. The app is a document based app and currently I have been storing the actual database file in iCloud so the whole file gets sync'ed by iCloud.
This works fine but obviously if a user opens the file on two devices and is not careful about saving and closing there is a possibility their changes may be overridden.
Apple has approved the Mac app which uses standard NSPersistentDocument to create and save files. Unfortunately they have rejected the iOS apps with some obscure reference to not conforming to their data storage guidelines, saying that documents must be stored in /Documents directory if they need to be backed up to iCloud. Well if the user has selected iCloud then I store the files in the iCloud location provided by the API calls.
Anyway I am still waiting to hear back from them about what is specifically wrong with this approach since it seems to be the same one used by Pages and other document based apps.
If I try using UIManagedDocument then iOS creates a folder structure and stores the database inside this folder structure. The Mac app File->Open dialog then shows this folder structure as well as a file that essentially looks like a the normal sqlite file. But then perhaps OS X 10.8.4 does not implement the latest iCloud/Core Data stuff - who knows...
EDIT
Here is a link to code examples and videos showing OSX and iOS app integration using Core Data and iCloud. http://ossh.com.au/design-and-technology/software-development/uimanageddocument-icloud-integration/
I agree this is definitely possible. I'm using NSPersistent document on OS X 10.8/10.9/10.10 with a binary core data format (no wrappers - plain files). On iOS i'm using UIDocument. Core data works fine in both environments.
Apple says NSPersistentDocument does not support iCloud. It is more correct to say it isn't fully supported. Most of the NSDocument support (which includes iCloud Document Library access from 10.8) will work. Handling of conflicted files on open works.
You can't enable auto save (which is listed as a requirement for iCloud Documents in the iCloud Design Guide). Autosave works asynchronously and is definitely not supported by NSPersistentDocument.
So if you handle file saving, and conflicts, it is possible to use NSPersistent document. There are some quirks: so, for example, if an iCloud change arrives on OS X for a document that is open, the normal NSDocument response would be to automatically reopen the document. This doesn't happen - and there is no warning the file has changed until you are about to save the file. But at least there is a warning. On iOS it is easier to detect changes as they happen by using UIDocumentStateChangedNotification.
I have recently bought a perfect file manager app for my iPad. Everything in this app is great, besides that it cannot handle some specific file types.
So for example if I try to download the file in mobile safari and try to save it into the file manager (for further upload to dropbox, email and so on), I cannot do this because the app is not listed in the "open In" list.
The question is, how to associate this app with this specific file types? I've searched google and found out that app's file association information is stored in Info.plist file in the CFBundleDocumentTypes section.
So I just modified Info.plist but id didn't help. I also found the cracked version of this app and placed info.plist into the IPA file, reinstalled the app on the iPad and it also didn't help.
Any suggestions how to solve the problem?
You cannot just add the file types. The app also has to be coded to accept the request to open the file.
Try contacting the developer and ask for them to add this feature.
The problem is probably not the APP but a limitation on IOS: it is a random selection and only shows 10. I don't know if it randomly selects based on the ones you use most or what. You cannot change this other than to delete apps you don't use as often. But having said this, the app must also support the extension of the document you are trying to send: not just as a document it stores, but as a document it accepts as a transfer from another app. You can try to convert it first into a PDF and then open, if that's possible. Hope this helps.