Re: App unable to import files in iOS13

My app has the ability to import GPX route files. However I am getting reports from users of iOS13 that the app is no longer appearing in the list of available apps when they try to export a GPX file.

Has anyone else seen or heard of this, and does anyone know how I might get around it? As far as I know it is only the Imported UTIs that affect this - is iOS 13 more fussy about how they are specified?

Did you get to the bottom of this? I also have an app that exports UTIs, but on iOS 13 when opening an appropriate url Safari uselessly offers to download the file rather than offering the usual "Open with" dialog.

Same issue here. From all the documentation, I believe my exported types are correct. Opening a supported file from the 'Files' app launches my app, but my app doesn't appear in activity controllers, nor can I open files 'shared' through messeges, etc.

I haven't worked out a way around it yet but when I uploaded my last beta I did get a warning about LSHandlerRank needing to be set on my document types. I had it set for the GPX document type but not for a couple of other types, so maybe you cannot import any types if some of them do not have this key set?

It was only a warning and I haven't been able to test this theory because I didn't want to immediately release another beta with a new build number, so I won't be able to test the theory until my next beta. I will probably also set CFBundleTypeRole as well because that seems to be associated with LSHandlerRank.

Apologies if this is a red herring but I thought I would mention it in case it helps anyone else.

In my case, it's not a problem of being buried. My application can share things just fine. It can even be opened by those shared things... unless they are in iMessage. I'm comfortable with it being a bug, given that code level support couldn't find anything amiss with my code. I appreciate the offer of the assist though.

I have added a workaround to my app in the form of an Import button that displays an instance of UIDocumentPickerViewController. It isn't as good as being able to share a document to the app, but it does allow users a way to import documents that works on iOS 13.

You know what? UIDocumentPickerViewController exhibits the very same behavior. All .ovpn files are disabled as long as OpenVPN Connect is installed together with my own app, which handles the same file extension. ****.

Someone on another thread (https://forums.developer.apple.com/thread/122170) has spotted that the existence of other apps that have registered an interest in the same type could be the cause. I uninstalled several such apps and suddenly my app appeared on the share list. I then reinstalled the apps and it is still on the share list.

It seems inconsistent, but maybe knowing this may help us to work out what is going wrong.

Subscribing the thread for facing the same annoying issue. In the meantime I'll have to resort to the UIDocumentPickerViewController trick too (@cfc good call on this). More development time wasted to have a degraded app functionality.. and I foresee user complaints. Gosh, I'd better say nothing.

BTW I also filed a report a few days ago, but the bug has really been around since June. I had hoped that they could realize by themselves due to how blatant it is.

I submitted my bug report using Feedback Assistant, although I haven't been able to login to it for several days. It always seems to be down at the moment. I wonder if that is why the iOS 13 beta is so bug-ridden: because the tool for reporting bugs is rarely working.

It is strange that such an obvious bug that was reported back in June hasn't been fixed in September, but maybe it isn't so obvious to Apple engineers. It seems to depend on what other apps are installed and they may do their testing on "clean" devices without other apps.

I also dropped any Imported/Exported UTIs (unused in this scenario). Interestingly, I'm unable to open .ovpn files (which are plain text) with public.text or public.plain-text.

Granted, it's bruteforce-like, but it's the only way I had my app appear consistently. The obvious downside is that the app is virtually able to open all files, but compared to a crippling bug it feels like minor cosmetics. Import would eventually fail so I don't really care much.

I just got an email from Apple saying that the issue is fixed in iOS13.1 beta 2, which is great but it sounds like it will be an issue for users using iOS 13. It will be interesting to see how soon after the iPhones are available that 13.1 will be available. Hopefully very soon if not immediately!

"As a result of your feedback, there are software changes in build 17A5831c that have resolved this issue. Has this issue been fixed for you?"

We solved it by re-adding all the file definitions in our App-Info.plist file by using Apples documentation and the Xcode Project Editor (In Xcode click on the project item at the top of the file tree. Then click on the tab "Info".) We used for that an iPhone SE with the newest iOS 13 beta and Xcode 11 GM (11A420a).

Thanks for posting this. Adding "UTTypeConformsTo" is what I needed for my app to show up in sharing action sheets in iOS 13.

When Safari downloads one of my custom files in iOS 13, it no longer prompts if I want to open that file in my app like it used to. I hope that ability comes back since I'm not sure users will know to look at the downloaded file and then do a share action.

Yes the Safari link is broken. My app really relies on that to download propriatery plugins from a webpage. They just went ahead and broken the whole functioanlity. What a shame. Some of the brightest minds around wasting their time on Apple's GUI churn, insted of creating something of value.

My bug report for the issue says less than 10 people have reported it, so I am wondering if Apple do not actually realise how big the problem is because their systems are not correctly detecting that multiple reports are for the same bug. I guess it can be described in many ways.

Unfortunately iOS 13 is so buggy (the worst I can remember in over 10 years of iOS development) that bugs with so few reports are probably well down Apple's list of priorities.

I seem to have finally got it to work with iOS 13.1.1 by setting LSSupportsOpeningDocumentsInPlace to false - there's other apps installed on my device that can handle the same file but my app pops up in the share sheet and can open the file.

The problem with knowing if any specific change fixes the problem is that just the act of installing can solve the problem. The order of installation/uninstallation seems to be a factor. I have had several users re-install other apps that register an interest in GPX files and suddenly my app appears on the share list, despite them having made no changes to it at all.

I have also had users for whom it was working with iOS 13.1 but then it broke when they installed iOS 13.1.1. It seems almost random but is triggered or fixed by the installation of a new iOS, or the install or uninstall of other apps that register interest in the same file type.

I am also now having problems with my workaround of showing a UIDocumentPickerViewController to allow files to be specifically imported. It seemed to work with iOS 13.0 (or at least no-one complained) but sometimes does not work since iOS 13.1 was released. Strangely it still does work for some users for whom the sharing mechanism is not working. So it helps some users but not others.

I had set the document type for this import controller to be kUTTypeXML but for some people this will not allow any files to be selected for the affected users. I will try making it kUTTypeData in the next version to see if that helps, although I would prefer not to make every data file selectable.

We are waiting on a response on this issue as we too import gpx and MBTile. Hopefully this gets resolved soon. From what we see it is totally random in that we can delete and reinstall the app and get different results. Sometimes we will show up as an import option, sometimes we won’t but if imported into Files first then sometimes we will show up in there and sometimes not. Only work around we found is to compress (.zip) the file then we show up and it can be imported. From the looks of it a fair number of gps apps are having this issue as I have them loaded and they no longer show up as an option. We’re not alone Apple. Kill this bug! Damian LEADNAV GPS

Hi Damian, Stan here, Speedometer 55 developer, you can try with my most recent pro version and if import works for you (sqlitedb, mbtiles, gpx) when Leadnav fails, I'll share my solution with you. Would hate to see this Apple's total failure as a competitive factor for some apps. Per response from Apple that I got for my bug report on this with providing a link to this thread, I'd say we might not be sure we will have it fixed soon. We need to fix it ourselves.

But even if we fix it ourselves, still the problem is that you can't export from your app to the affected apps while users are of course seeing this problem as your app's problem. But that's another side of this problem.

Apples response We understand that you are having issues with your type definition for .gpx files. At this time, there is no commonly-accepted Uniform Type Identifier for .gpx files and different developers have defined their .gpx declaration differently. This means that if two apps are installed on the same device that claim to open these files with different definitions, they won't interact correctly: from the user's point of view, only one of those apps, chosen seemingly at random, will be able to open these files. Our understanding is that this format was designed by Topografix, so our current recommendation is that you redeclare support for .gpx files in your app by adding a type declaration for com.topografix.gpx that conforms to public.data and has the filename extension tag gpx. An example declaration is shown here: UTImportedTypeDeclarationsUTTypeIdentifiercom.topografix.gpxUTTypeReferenceURLhttps://www.topografix.com/gpx.aspUTTypeConformsTopublic.dataUTTypeTagSpecificationpublic.filename-extensiongpx Apple does not generally declare Uniform Type Identifiers for file types the operating system does not natively support, so this is a change that you will need to make. If you and other developers standardize on this Uniform Type Identifier, users on iOS 13 should see these apps appear in UIActivityViewController and other relevant UI locations. Such a change will also benefit users still running iOS 12 and earlier if they have multiple apps installed that can handle this file format. For more information about declaring Uniform Type Identifiers, see our documentation here: https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_declare/understand_utis_declare.html While making this change in your app will not immediately fix the problem, it is a step in the right direction as other developers adopt this UTI.

I filed FB long time ago and didn't get as thourough response as LeadNav, just "Fix it yourself" resolution. But are you still having a problem? I have not had a single customer complaint since I've merged a range of suggestions in this thread together for my apps. Given response that LeadNav has got, it all makes some weird sense. I use "All files":

<dict>

<key>CFBundleTypeName</key>

<string>All files</string>

<key>CFBundleTypeRole</key>

<string>Viewer</string>

<key>LSHandlerRank</key>

<string>Alternate</string>

<key>LSItemContentTypes</key>

<array>

<string>public.content</string>

<string>public.data</string>

</array>

</dict>

As the last entry in document types. Above this I have the following for kmz:

<dict>

<key>CFBundleTypeIconFiles</key>

<array/>

<key>CFBundleTypeName</key>

<string>KMZ Google Earth</string>

<key>LSHandlerRank</key>

<string>Alternate</string>

<key>LSItemContentTypes</key>

<array>

<string>$(PRODUCT_BUNDLE_IDENTIFIER).kmz</string>

<string>public.archive</string>

<string>public.data</string>

</array>

</dict>

Then I have the following for the kmz in the Exported UTIs:

<dict>

<key>UTTypeConformsTo</key>

<array>

<string>public.data</string>

<string>public.archive</string>

</array>

<key>UTTypeDescription</key>

<string>KMZ Google Earth</string>

<key>UTTypeIdentifier</key>

<string>$(PRODUCT_BUNDLE_IDENTIFIER).kmz</string>

<key>UTTypeTagSpecification</key>

<dict>

<key>public.filename-extension</key>

<array>

<string>kmz</string>

<string>KMZ</string>

</array>

</dict>

</dict>

I have no intent to be adding anything for GPX right now, but I think I could do it in the same way as it is done for kmz. The only benefit that I'd see from adding GPX would be gpx file icons being my app icon sometimes?

I tested this with my own apps (compass 55, speedometer 55, planimeter 55) and they were never competing on any types (I do declare explicitely .sqlitedb, .mbtiles, .kmz and my own .trk) and I think they are not breaking other apps as well.

This led me to having no imported types. Will I need to agree with 1 million devs to have working imported types again? Per Apple's response to LeadNav, yes?

My understanding of this is that for the imported types, instead of merging info from different devs on it, Apple simply overrwites it in iOS 13? Imported types are not owned by the app. Next app comes and becomes the "master" over this imported UTI. If both matched perfectly on UTI there would no conflict?

Exported types are owned by the app. Looks to me that Apple still continues to merge information from the Exported UTIs in iOS 13.

I might be very wrong with my understanding, I hope not, but let me share it here in hope that someone wiser may comment. The solution seems to work, and while not being perfect, I can't suggest my customers to delete other apps (and which ones)? I believe this solution breaks nothing in fellow dev apps and makes my apps immune. I don't think that Apple is right with their new approach to the imported UTIs in iOS 13.

The problem is still present for me on iOS 13.1.2. My app has support for 5 different file types. Some work fine, others don't show up in the menu, even though all are specified in similar ways in the info.plist. For GPX files, if you open the file from Mail, then the app does not show up in the menu, but numerous other apps do. But if you transfer the file through AirDrop, then I don't get a menu at all. Instead, a popup comes up saying that "This file type needs an app from the App Store".

I have logged a bug report as well. I strongly suggest everybody to do so, to put pressure on Apple to fix this. This is a major, major bug which disables important functionality in apps.

I had the same issue with my app, not released yet. My mistake was that I registered the gpx type as my own. For the Types property, I had "com.myappname.gpx". Same for Identifier. This told IOS that I have invented the gpx format and it should be registered as my app's. That was completely wrong.

In fact, the gpx is an xml format. So, for me, the solution was to set the "Types" property to public.xml and the "Conforms To" property to public.text. Now my app appears in the Share menu, as Copy to AppName, and the gpx file opens properly. My app is kind of hidden under the More button, but it's there. After setting it as favorite, it's on the first page, but that's the user preference.

In my rookie mind, that would explain why everything depends on the order of installation of the apps. If all the apps register themselves as the creator of the format, the app that was installed last will work, while the others will not. If we all register our apps as opening public formats, the isuue would disappear. In theory. Not tested enough.

None of the file formats that my app supports are registered as my own, and never have been. I still have problems with opening 3 out of the 5 file types. So, no, that is not the underlying cause of the problem.

I've solved this in may app by replacing custom UTIs with system defined ones. I used them in Info.plist in the "Document types" section and removed all exported UTIs. Now my app is back in the list of available apps.

You can get UTI for a file by using this command in Terminal (God bless Wikipedia :-)):

Thanks for that. I can't tell if it works for me yet because I wasn't having the problem - many of the users of my app were seeing it, but not me. I will use that UTI in my next beta and see what the beta testers say.

I finally solved this problem for custom UTIs. First a little background. Our apps have two or three custom file types. They have been in the apps for at least five years and have always worked fine. After upgrading to iOS 13, users could no longer import their files from any source.

After trying many suggestions in this thread, I finally decided to delete the entire "Exported Type UTIs" and "Imported Type UTIs" keys from the info.plist for each app. Note that I used the property list view for all changes, not the source view. Next, I went to the target info tab and created new Exported UTIs and Imported UTIs. The identifier for each UTI was the same as before, which was the reverse company domain and the custom file extention (com.company.ext). The "conforms to" field was set to "public.data" for all. In the "additional properties" area, I added the UTTypeTagSpecification key as a dictionary and added the "public.filename-extension" key as an array. In the array I added one item which was the file extention.

UTTypeTagSpecification Dictionary

public.filename-extension Array

Item 0 String ext

Prior to these changes, I was working with the plist source to try to solve this problem. But apparently using the property gui editor changed the plist source in a way that resolved the problem. I only did a quick compare of the old file and the new and didn't see anything obvious.

1) Clear the Conforms To field, then the app will not show up in the list.

2) Create another app GPXApp2 with the same Imported UTI and Document Type, except changing the Identifier and Types to a different value, say com.topografix.gpx2. Then at least one of the apps will not show up in the list.

I found that one solution is to add public.xml to the LSItemContentTypes array. Then both apps can show up in the list. The side effect is that they will also show up in the list for XML files. Probably, it is safer to add public.data instead, but I found that the only case for public.xml to fail is when both apps set the Conforms To field to public.data.

Hi, I have had this problem exporting GPX files from Gaia to Outdooractive up to 13.2. OA would not show up in the list of suggested apps. So I deleted a lot of apps that had shown up instead: Threema, Telegram, LinkedIn, DropBox, Google Drive, Komoot, Motion Control X GPS, ... Now I have only three GPS apps (which create GPX filed and can import them). Gaia, Outdooractive, Alpenvereinaktiv. Cheers

There is no config that is guaranteed to work. One of the other users reported the following feedback from Apple on the issue:

"We understand that you are having issues with your type definition for .gpx files. At this time, there is no commonly-accepted Uniform Type Identifier for .gpx files and different developers have defined their .gpx declaration differently. This means that if two apps are installed on the same device that claim to open these files with different definitions, they won't interact correctly: from the user's point of view, only one of those apps, chosen seemingly at random, will be able to open these files."

That is, if there are two or more apps that have given different Uniform Type Identifiers for the same file extension, then only some of them will appear, choosen at random.

I have my own custom UTI for my own files which I serve from a web page.

in iOS 12, Safari puts up "Open in.." when tapping it. Choosing Open in copies the file into my apps Documents dir in a special Inbox subdriectory, where I can read it via the URL. If I use the UIDocumentPickerViewController way , it says "Copy to [my app]", which again puts it in the Inbox.

in iOS 13, it demands to be downloaded instead. Trying to read the downloaded file results in it not being owned by my app and illegible. In fact, I can't figure out what anyone can do with the download's file:// URL that is given to the app in that situation. If I go to the Download part of Files and move (copy really) it into my app's Document dir, it's found.

I've tried a great number of the techniques mentioned, but the truth is: works in iOS 12 perfectly, decides it wants to use the new file system in iOS 13, but still doesn't give access.

I gave up trying all the suggested fixes because in the end it was impossible to tell if they worked because the issue is random. So I very reluctantly made my app accept all file types. Even if Apple were to fix the problem tomorrow it would still be too late. Most people are using iOS13 now and a significantly large amount will still be using it in a year or two, so I can't see myself ever changing the app back to only accepting some file types.

It is very annoying because we told Apple about the issue months before iOS 13 was released but they did nothing and now the file type system is broken for the foreseeable future.

2019-12-27 09:34:05.150198+0800 Happy3D[357:24297] invalid mode 'kCFRunLoopCommonModes' provided to CFRunLoopRunSpecific - break on _CFRunLoopError_RunCalledWithInvalidMode to debug. This message will only appear once per execution.

We had today a similar case that it was not working anymore on iOS 13.4. The gpx file was flagged with the icon of our app, but the "copy into app" menu entry was missing. A restart of the smartphone did solve it.

More Like This

Incoming Links

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Developer Forums Participation Agreement.