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:
Related
I have some questions regarding the information I should include in my project's Info.plist file before submitting the app:
A) About CFBundleIcons: I see this key when I open the file in Xcode as source code and the xml format is displayed but, when I open it as property list, I only see an Icon files (iOS 5) entry, is that correct? On the other hand, I've changed the app icons I firstly had in the General tab of the target settings, and the Info.plist file keeps listing the old app icons as well, and the new icons I added do not have the .png extension in their name... should I handle this information manually, or did I something wrong when I changed the icons in the target's settings? Should the names include the png extension? Should I list all versions of an icon (standard and #2x), or just the name for the standard is enough?
B) Regarding UIRequiresPersistentWifi key, Apple's docs say that
Include this key if your app requires a Wi-Fi connection
I'm not sure if I have to include this key: my app performs network operations but they could be done via WWAN, not only via Wi-Fi. And not all my app's features need network connection to be performed.
C) About UIRequiredDeviceCapabilities key. I have in turn some questions here: Apple says that
The value of the UIRequiredDeviceCapabilitieskey is either an array or a dictionary that contains additional keys identifying features your app requires (or specifically prohibits).
What do they mean when they say "features your app requires": those features which the app won't work at all without them, or all those features that your app can use? For example: my app includes an option for listening the device's location. It is an optional functionality, users can enable and disable it. I check [CLLocationManager locationServicesEnabled] when the user enables the option. I've no set the location-services value in the plist file and the app has been tested and the feature works, and the compiler has never complained. Should I include the value if I want to submit the app?
Something similar happens with another capabilities, for example microphone and still-camera. I use UIImagePickerController at some point of the app, as well as the microphone for speech recognition, but that are also optional functions of the app that the user has to select, they don't affect its overall operation. And I neither have included such values in the plist yet and they are working...
Thanks in advance
A: If you want to publish iPhone app only you need provide the 2 icon's(#1x, #2x),Now I think #1x is not for necessary, if you want to publish Both iPad & iPhone, you may need to provide 4 icon. But if you dont care about the quality 1 icon is OK.
B:This line UIRequiresPersistentWifi is not necessary.
C:Same as B) This line UIRequiresPersistentWifi is not necessary. if you have more require from iOS system.
I intend on releasing an app in the Apple store that contains an apostrophe in the title. I notice that XCode already has issues in building the code when the 'Target' name contains an apostrophe. I've managed to get around this problem (for now), by using the following character:
’
as opposed to:
'
This seems to build okay, but I'm a little concerned about what may happen later down the line, such as when I submit the final build to the store etc.
Does anyone happen to know if this little workaround is suitable, or am I just setting myself up for a world of problems?
For example, is using an abstract character like this going to mean no one can search for my app in the store?
The display name of the app as it will appear on the iOS spring board is set in the app's infoPlist and has nothing to do with build settings. The Xcode project, target and all other files can be named whatever you like.
You need to set the CFBundleDisplayName in your app's Info.plist. By default this is set to ${PRODUCT_NAME} which is the Xcode configuration variable of the target's name, but it can be what you like.
Going one step further you should use the InfoPlist.strings file to overload this value for different localisations. Setting the value in this file will make the other value in the Info.plist obsolete. These days Xcode comes with a blank one in new projects but it's easily added if it's not there.
The InfoPlist.strings file would look like this:
"CFBundleDisplayName" = "App's Name";
Note: If you've set up the app's name as above and the spring board isn't displaying the Apostrophe then it's probably taking it out deliberately.
It appears you're talking about the title of your application in The App Store, which is entered in iTunes Connect and has absolutely nothing to do with any code you write.
If you place an apostrophe in your app's name in iTunes connect it may have an effect on the users searching for your app as you suspect.but often apps have extended names that offer more context to the app's name and you should also use the keywords to your advantage.
You should check out the iTunes Connect Developer Guide
Edit your CFBundleDisplayName in info.plist to
<string>App's Name</string>
Works perfectly. I've used above in production app, with no issues.
This question could also be a general "How to change info.plist contents at compile-time" but I know it's a complex issue that is handled differently on iOS and MacOSX. The thing is that specifically when working with the Facebook SDK, it feels kind of wrong supplying my FB app-id twice - once in the "URL types" dictionary under "URL schemes" in the app's info.plist and once in my code. I want to be able to change the app-id dynamically from within my code without touching the info.plist file. I looked into Apple's launch services and found a potentially helpful "LSSetDefaultHandlerForURLScheme" method, only to find out that I was looking at the MAC developer library. I saw some other SO questions about this issue but the general opinion seems to be that this is not doable. Any ideas that don't involve pulling information out of the plist at compile time? (I want to be able to support several app-ids that are defined in a specific header file in my code).
Thanks!
I’ve got several iOS apps and I need them to be aware of each other. More precisely, I need to know whether there’s already one of my apps installed.
I thought about registering a custom URL scheme (something like my-app-present://), so that I could check whether the custom scheme is supported and if yes, I would know there’s already one of my apps on the device. But that doesn’t work, because the schemes are registered through Info.plist and the app registers the scheme before it has a chance to check for its existence. In other words, the check always succeeds.
Then I thought about creating a file in the temporary directory, but NSTemporaryDirectory() returns a folder inside the application sandbox, so that wouldn’t work either. I also thought about keychain, but again it looks like each application has strictly separate keychain on iOS.
I don’t want to go through the list of running apps and I don’t want to use networking. Do you know some other tricks?
The custom URL scheme method sounds fine, as long as you have a different scheme for every app, for example my-app-1:// and my-app-2://. Then (I assume this is what you already knew) you can use canOpenURL: to check if the URL can be handled (i.e., your app is installed).
If by "talk to each other" you meant you just want to detect whether other app has been installed or not then iHasApp is an open source iOS framework could come in handy. I haven't used it yet. but from the description it appears to be a good choice.
http://www.ihasapp.com/documentation/Classes/iHasApp.html
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.