I have a code which shares a line of text and an image via UIActivityViewController. After I updated to iOS 10 it started crashing with the following log:
This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSPhotoLibraryUsageDescription key with a string value explaining to the user how the app uses this data.
I do not post the code since it seems to happen even in Apple's own example. I found a corresponding radar, but not StackOverflow topic.
Hope it will save someone's time. The fix is to add that line to your plist even though the app itself does not interact with the Photo Library. If anyone finds a better solution, it would be nice.
Please, note that it is different from a problem with UIImagePickerController - it is close to an opposite action.
Add NSPhotoLibraryUsageDescription to Info.plist :-( Don't leave it empty - it reuses Apple's default question, but it is fine only for development. Uploading such archive to App Store will trigger an error.
Related
While working on an iOS app written in Swift, I am having trouble with the Info.plist. Here is the issue:
The unique Info.plist file contained in the project has an NSBluetoothAlwaysUsageDescription key.
For reference, here is the relevant part of Info.plist:
<key>NSBluetoothPeripheralUsageDescription</key>
<string>The app uses bluetooth to transfer data to a neighbouring device.</string>
<key>NSBluetoothAlwaysUsageDescription</key>
<string>The app may frequently use bluetooth to transfer data to peers.</string>
But when I run the app on my iPhone, I see this error in the Xcode debugging console:
2021-06-06 11:20:21.235717+0900 TheApp[5010:1066154] [access] This app has crashed because
it attempted to access privacy-sensitive data without a usage description.
The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key
with a string value explaining to the user how the app uses this data.
There is already a contradiction at this point that I do not explain.
For some further investigation, I do as follows:
Product
-> Archive
-> Distribute App
-> Development: Distribute to members fo your team.
-> Export
There I change the name TheApp.ipa to TheApp.zip and uncompress it.
Then inside the Payload folder, on TheApp.app I do:
Show Package Contents
There I see an Info.plist item which I click to take a look at.
And for some unknown reason the NSBluetoothAlwaysUsageDescription key is indeed missing.
This last point may explain the error message I was getting earlier, but I still don't know why the key has disappeared.
Anyone who can shed light on this issue will be very welcome.
I finally found the solution.
While looking and trying out various things I discovered a duplicate of Info.plist.
MyApp copy-Info.plist
This ghost Info.plist contained wrong contents and looking at it, that explained all the weird observations I was making.
For some reason the building process was using the ghost file instead of using mine. And the actual Info.plist was ignored.
I am trying to use the HealthKit API in my Apple Watch app but could not get it to work. I tried copying Apple's demo program SpeedySloth found here:
https://developer.apple.com/documentation/healthkit/workouts_and_activity_rings/speedysloth_creating_a_workout
Downloading this app and running it works but if I copy each line of code line for line it doesn't work. Is there anything else that needs to be set for it to work. I know NSHealthShareUsageDescription and NSHealthUpdateUsageDescription in Info.plist need to be set which I have done but it still crashes when the view loads.
There are no errors displayed in the console.
Any ideas of anything I've missed?
I have submitted a Single View Swift iOS application to App Store Connect. The application is not Document Based.
The application uploads successfully, but I get the following warning in an email from Apple. I can still test the application through Test Flight, but I want to eliminate the warning.
"Invalid Document Configuration - Document Based Apps should support either the Document Browser (UISupportsDocumentBrowser = YES) or implement Open In Place (LSSupportsOpeningDocumentsInPlace = YES/NO)."
I just ran into the same problem; I don't know why, since I barely change anything since the previous version of my app.
Anyway, my app doesn't support the Document Browser, so the first half of the error message doesn't apply. That left me with the second half. I looked up LSSupportsOpeningDocumentsInPlace's documentation and still wasn't clear on how it works, so I decided to try both options. My app supports it's own document type, and when a user opens an appropriate file iOS shows an action sheet with the option "Copy to Leio" (my app). After setting LSSupportsOpeningDocumentsInPlace to YES, iOS wouldn't show that action sheet anymore; it would just open my app and do nothing. So I set it to NO; now the app works as it did before and I'm not getting that error message anymore. If you don't handle any document types I suppose you could set the option either way.
Edit: There's some more information about that option here.
So there you go. If your app were to edit a document, would it edit the original document, or would it make a copy and deal with that? Set the option accordingly. If you really don't do anything like that I'd guess setting the option to NO would be the safest bet, and I think that's how my app behaved when I hadn't set that option at all.
Since your app is not Document based just set UISupportsDocumentBrowser and/or LSSupportsOpeningDocumentsInPlace (reference and documentation) to NO in your plist. This should resolve the warning.
I had the same problem with the warning from App Store Connect. After changes these two keys to NO and resubmitting the warning was gone.
Typical Requirement
If your application is not document based (which would typically be the case if you get this new warning) and if furthermore you are already opening files in your documents directory, then all you need is:
LSSupportsOpeningDocumentsInPlace = YES
This answer does not apply if you are not opening documents in place (i.e. make a copy), or of course, if you so desire to support document browser, as seen in #rivera's comment.
If you are using UIDocumentInteractionController in your app, set
UISupportsDocumentBrowser = YES
in your project's info.plist; otherwise, set
UISupportsDocumentBrowser = NO
It appears that if you have CFBundleDocumentTypes in your apps Info.plist, even if the array is empty, this warning is triggered when you submit your app. If your app doesn't support any document types remove that key and you won't get the warning.
I also faced the same issue recently while uploading the app to TestFlight, The below solution worked for me,
In your app's Info.plist file, the UISupportsDocumentBrowser key is set to YES, declaring document browser support for your app.
For more info, please refer Setting Up a Document Browser App
Here are where you find the settings in Xcode 13:
I want to upload my app to iTunes connect but after uploading I always get an error message by mail from iTunes, that after their scan some description variables are missing.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSPhotoLibraryUsageDescription key with a string value explaining to the user how the app uses this data.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCameraUsageDescription key with a string value explaining to the user how the app uses this data.
I am using both features, so that's ok, BUT: i already added those variables to my localized infoPlist.strings. And these seems to work, because in the Simulator and my iPhone, both strings are displayed correctly in the system dialogs. I didn't add the strings to the plist.info file, because I specified them in the localized file, which should be ok. The plist.info and also the localized file are both packaged in the app, I already head a look using Finder.
Is there anything else I must add? Do I still need to add them to the plist.info file, although they are in the localized file?
Additional info: I am using the latest XCode 8 GM build on macOS Safari.
Are you using AdMob? If so the answer is that Google confirmed that it is an issue with the AdMob SDK. You can read about it here.
The solution is, to add the keys also to the PList.info file, not only to the localized infoPlist.strings file.
This is a bit inconsequent because within the simulator and on my phone every message is displayed correctly. But now my app was accepted.
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.