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?

  • I want the experience.

Add a Comment

Replies

when will they fix this issue on iOS13? "Uninstalling all but one of the apps that can import GPX" works, but it is not elegant....

iPhone Beta13.2 - nope.

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.

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. 🙂

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.

Same, need this to work again as it did previous. Apple regration testing and backward compatibility lacking?

iOS13.2 and xcode 11.2 still not working

All of my export files are .plist. I changed the "Types" to public.plist and "Conforms To" property to public.text but this still doesn't work for me.


I had also upgraded to 13.2 but then had to downgrade to 13.1.2 as Xcode would no longer load files onto my device giving me the message that I needed to upgrade to the latest version of Xcode.

This is how I got it to work for me. For the file type I just made an abitrary extension to the file I was saving as an email attachment: filename.anyuniqueextension


Under Document Types I left the default value of "Damian-s.${PRODUCT_NAME:rfc1034identifier}"


Then under "UTTypeTagSpecification" change Item 0 to "anyuniqueextension"


Make sure in your app that you read and write the file extension with "anyuniqueextension"


All of my file types are .plist.

Did you add these or where they already there? I only have Document Types, I don't see UITypeTage Specification anywhere. Can you provide more detail

I replaced the types that were there.


It would be easiest to show an image but since images aren't allowed here, this is the text from the .plist file in the app:


The UITypeTage is in the UTExportedTypeDeclarations.


The extension to the email data file is "visionPF". This is added to the file name in the app when creating the email attachment.



<key>CFBundleDocumentTypes</key>

<array>

<dict>

<key>CFBundleTypeIconFiles</key>

<array>

<string> blah blah blah path to icon image </string>

<string>VisionEmailIcon.png</string>

</array>

<key>CFBundleTypeName</key>

<string>VisionFliteSettings File</string>

<key>CFBundleTypeRole</key>

<string>Editor</string>

<key>LSHandlerRank</key>

<string>Owner</string>

<key>LSItemContentTypes</key>

<array>

<string>Damian-s.${PRODUCT_NAME:rfc1034identifier}</string>

</array>

</dict>

</array>

<key>UTExportedTypeDeclarations</key>

<array>

<dict>

<key>UTTypeConformsTo</key>

<array>

<string>public.data</string>

</array>

<key>UTTypeDescription</key>

<string>VisionFliteSettings File</string>

<key>UTTypeIconFiles</key>

<array>

<string>VisionEmailIcon.png</string>

</array>

<key>UTTypeIdentifier</key>

<string>Damian-s.${PRODUCT_NAME:rfc1034identifier}</string>

<key>UTTypeTagSpecification</key>

<dict>

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

<array>

<string>visionPF</string>

</array>

</dict>

</dict>

</array>

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 :-)):

mdls -name kMDItemContentType -name kMDItemContentTypeTree -name kMDItemKind FILE


For GPX files the UTI is "com.apple.dt.document.gpx". Corresponing record in Info.plist should look like this:


    <dict>
        <key>CFBundleTypeIconFiles</key>
        <array/>
        <key>CFBundleTypeName</key>
        <string>GPX record</string>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
        <key>LSHandlerRank</key>
        <string>Owner</string>
        <key>LSItemContentTypes</key>
        <array>
            <string>com.apple.dt.document.gpx</string>
        </array>
    </dict>

Works perfect. Thanks for that elegant solution.


UTI for a .plist file:

com.apple.property-list