Related
I'm developing an iCloud-enabled app where users will be able to import and export files via iCloud Drive. When browsing iCloud Drive, either using the UIDocumentPickerViewController (iOS 8) or the Finder (OS X Yosemite), I can see directories created/owned by other iCloud-Drive-enabled apps, such as, Automator, Keynote, or TextEdit.
I want our app to expose its ubiquitous documents directory in iCloud Drive, too, but haven't been able to figure it out yet. Within some of the aforementioned apps' Info.plist files, I've discovered this key:
<key>NSUbiquitousContainers</key>
<dict>
<key>com.apple.TextEdit</key>
<dict>
<key>NSUbiquitousContainerIsDocumentScopePublic</key>
<true/>
<key>NSUbiquitousContainerSupportedFolderLevels</key>
<string>Any</string>
</dict>
</dict>
These keys are also documented here, but I haven't found any other documentation on the broader subject. Edit/Note: Although it does not contain the answer to my questions, the Document Picker Programming Guide is a helpful resource.
I've tried adding the above-mentioned keys/values to our app but didn't see any effect. Things I've noticed/tried:
For 3rd party apps, iCloud containers are constructed this way: iCloud.$(CFBundleIdentifier). I'm not sure why TextEdit only uses the pure bundle identifier, but for our identifier, I've tried both approaches, i.e., with and without the iCloud. prefix. I've also recognised that you need to hard-code the bundle identifier (i.e., don't use iCloud.$(CFBundleIdentifier)) as only the PLIST's values seem to be resolved at build time, but not the keys.
I've added a sub-directory programmatically (to <containerPath>/Documents) so the container is not empty. However, this shouldn't matter as all the other apps' directories were initially empty, too.
Some Apple apps that appear in iCloud Drive do not have these entries in their Info.plist, e.g., Numbers and Pages.
iCloud is set up correctly and I can programmatically look into the ubiquity container using the URL returned by [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];.
I am logged into an iCloud account where iCloud Drive is enabled. I can see my iCloud Drive content in the UIDocumentPickerViewController.
I use the iOS 8 beta 5 simulator (and Yosemite beta 5 to view the iCloud Drive directory on the Mac) (Edit/Note: This equally applies to beta 6)
This is how my Entitlements file looks like (relevant parts only)
<key>com.apple.developer.icloud-container-identifiers</key>
<array>
<string>iCloud.$(CFBundleIdentifier)</string>
</array>
<key>com.apple.developer.icloud-services</key>
<array>
<string>CloudDocuments</string>
</array>
<key>com.apple.developer.ubiquity-container-identifiers</key>
<array/>
I've set this up using Xcode's UI in the Capabilities section. I don't get why the last key doesn't have an entry, but adding <string>iCloud.$(CFBundleIdentifier)</string> doesn't help. Instead, it makes Xcode complain in the Capabilities UI, so I've removed it. Edit/Note: In Xcode beta 6, this has been fixed, i.e., the ubiquity container identifier needs to be set and Xcode can fix that for you.
Original Questions: So... is it a bug? Does it not work yet? Am I doing it wrong? I couldn't find a known issue in the release notes.
Edit:
Two more things that I've tried:
Adding the (optional) NSUbiquitousContainerName key (+ value) to the container-specific dictionary, as suggested by Erikmitk.
Adding only the NSUbiquitousContainerIsDocumentScopePublic key/value to the PLIST root dictionary rather than the container-specific dictionary, as it's done in one of the WWDC sample apps (look for NewBox).
I was experiencing a similar problem with my application. I was able to make this work by doing the following:
Add the NSUbiquitousContainers setting to my Info.plist file according to documentation here https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/FileProvider.html. Here is the relevant code:
<dict>
<!-- ... other top-level Info.plist settings ... -->
<key>NSUbiquitousContainers</key>
<dict>
<key>iCloud.com.example.MyApp</key>
<dict>
<key>NSUbiquitousContainerIsDocumentScopePublic</key>
<true/>
<key>NSUbiquitousContainerSupportedFolderLevels</key>
<string>Any</string>
<key>NSUbiquitousContainerName</key>
<string>MyApp</string>
</dict>
</dict>
</dict>
Important! I then changed the above NSUbiquitousContainerSupportedFolderLevels string value from Any to One
<key>NSUbiquitousContainerSupportedFolderLevels</key>
<string>One</string>
Next, and last, I had to change CFBundleVersion to a higher version. I also bumped the CFBundleShortVersionString to a new version as well.
Built and ran and after that, the folder with my applications icon appeared properly in iCloud Drive! Hope this helps!
When you edited the Info.plist, maybe you forgot to bump up the bundle version number? This is a requirement as per WWDC session #234.
The catch is to call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil]; (or with another container identifier if it's not the default one) at least once (not per launch, but presumably per version, or when changing one of the respective PLIST entries) in order to initialize the directory. I reckon this step needs to be combined with an increase of the bundle version number, as suggested in roop's answer.
I notice my question may have been confusing in that respect, as I mentioned being able to look into the documents directory* programmatically using the API in question. However, I removed that code from the app later, maybe before getting the rest of the setup right. I'm not going to write into the documents directory directly, only through the Document Picker. Therefore, there hasn't been any need to get the URL.
If you just need a Document Picker to read/store files from/in iCloud Drive or other apps' document directories, there's no need to call URLForUbiquityContainerIdentifier:. Only if you want your app to have its own ubiquity container (and potentially expose it in iCloud Drive and the Document Picker), the steps mentioned in the original post and the call to URLForUbiquityContainerIdentifier: are necessary.
*When mentioning the documents directory, I'm always referring to the one in the ubiquity container, not the local one.
It seems, changing the CFBundleVersion will let it work.
I think you can try it. I got this from Apple Developer Forums.
Hope this work for you.
After dorking around with this all morning, reading all the posts, making all the changes, the key thing that finally worked for me was, as Yet Another Code Maker stated, changing the bundle ID. I think once it has created a container for a bundle, you can't go back and change the visibility of it to have it appear in Finder. I had tried all the different info.plist values but nothing worked until I changed to a new bundle name and forced the system to create a new one. By the way, I didn't see this noted anywhere but the bundle name, the NSUbiquitousContainer name and the NSUbiquitousContainerName can all be different - which is what I did in my case. After spending so much time on this, I figured I would go ahead and put a simple sample app on GitHub in case anyone is still having problems debugging their iCloud folder appearing in Finder - you can find it here. All the required steps are outlined in the README.
In my case (Xcode 7 and iOS 9), the only thing which made it works, after multiple tries, was just use a new bundle identifier (you don't have to change the cloud container identifier, just be sure to select the container you want to use in the Apple Developer Member Centre and to specify in Xcode a custom container instead of the default).
In fact, that means the first time you run your application, the NSUbiquitousContainers section of the info.plist has to be set up. If you set it afterwards as a second step, it won't work...
Well, it's not documented anywhere but try to add Documents folder in the container and store your files there.
Found this hint in replies in this Apple Developer Forum thread.
The .plist entry on this documentation page has an additional entry:
<key>NSUbiquitousContainerName</key>
<string>MyApp</string>
Maybe the missing name is prohibiting it from showing up.
Couldn't find any documentation, but trial and error, I found that:
[[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:#"com.apple.CloudDocs"];
Gives you the base URL for the drive as seen in the picker. Using this base URL I was able to save files in my app and see it on the iCloud drive within Yosemite.
Edit 14.8.14
I tried your plist settings:
<key>NSUbiquitousContainers</key>
<dict>
<key>iCloud.net.redacted.docTest</key>
<dict>
<key>NSUbiquitousContainerIsDocumentScopePublic</key>
<true/>
<key>NSUbiquitousContainerSupportedFolderLevels</key>
<string>Any</string>
</dict>
</dict>
In my little throwaway test app "docTest" it does indeed expose the empty Documents directory in Yosemite and in the document picker.
Screenshot http://spring-appstudio.com/picker-view.png
Just wanted to emphasize one of the OP's discoveries that fixed it for me:
I've also recognised that you need to hard-code the bundle identifier (i.e., don't use iCloud.$(CFBundleIdentifier)) as only the PLIST's values seem to be resolved at build time, but not the keys.
You need to hard code the bundle id. Also update the version.
(I didn't notice this in the question until I went through all the answers).
Same problem occurred to my OSX app.
It is seemed that NSUbiquitousContainers setting works only in the creation time of the iCloud containers. So I tried with new Apple ID(for preparing clean iCloud environment), it becomes to work.
I know this is an old thread but just in case someone runs into the same issue: Only way for me to get my Container folder to be visible in iCloud Drive (after trying all the above suggestions) was to have my app create a temporary file in the Documents folder. As soon as I did that the Container Folder (and the file I created) showed up on my Mac. If this is really the case that I have to create a file to make this folder visible then this would be a bit annoying because my app is a read only app (only reads files added by the user to the Container Folder). The Container Folder needs to be visible as soon as the app is launched for the first time. I guess I will have to detect the first launch.
Xcode 5 helped in creating plist descriptor for enterprise ipa.
Xcode 6 (6A313) creates ipa only.
Is this a bug or intentional change? If so - what would be the reason for taking a step back?
If I did not have previously generated plist using Xcode 5, I would need to crete it manually myself.
Do you know of any automatic tool which would help in the process?
I'm having the same problem. Needed to put a build out last night. I ended up just reusing an old plist and updating it. Here's a template:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>[INSERT URL HERE]</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>[INSERT BUNDLE ID HERE]</string>
<key>bundle-version</key>
<string>[INSERT VERSION HERE]</string>
<key>kind</key>
<string>software</string>
<key>title</key>
<string>[INSERT APP TITLE HERE]</string>
</dict>
</dict>
</array>
</dict>
</plist>
Couldn't find other solution than reusing an old .plist-file --- worked perfectly.
I fixed this issue in following manner(As #pir800 mentioned)-
1) Take plist file of an old project and rename it name should be same as ipa file.
2) Changed values of following keys in plist file - a) url. b) bundle-identifier. c) title.
And then put ipa and plist on server. Remaining things are same like Xcode5.
But it is very bad, apple should inform to developer and mention such type changes in document.
I do not my way is correct or wrong but my Enterprise In-house Distribution build properly downloaded and working. ....:)
I replied same on apple developer also. You can check this thread https://devforums.apple.com/message/1076995#1076995 also
If any one find better solution then please reply.
Thank you...
To extend the accepted answer, you need to be a team member of the 299$ enterprise account. Go to Project Navigator (ProjectName) -> Targets -> General tab and select the account that is assoicated with 299$ enterprise developer account. If you cannot find the account you are looking for, go to XCode -> Preferences -> accounts and check if you are the admin / agent / team member of the said account and then proceed to make the ipa and plist file.
I'm not sure about enterprise deployment, but in XCode 7.0, you can create a manifest.plist while exporting an archive for Ad Hoc deployment...
Select Product > Archive
When the build finishes, select the archive you wish to export and choose "Export..."
Choose "Save for Ad Hoc Deployment"
Select your dev team
Choose the desired option for "Device Support"
On the "Summary" page, check the box beside "Include manifest for over-the-air installation." This will add a manifest.plist to the folder where the .ipa file was saved. - Click "Next"
Insert the correct paths to the .ipa, display image, and full size image and click "Export"
Hope this helps.
I'm experiencing exactly the same thing, having to re-use a plist file generated from Xcode5. Just one other thing to add: The validate button, that we're presented with after archiving, does not validate my App correctly. It gets past "Preparing Archive" but then throws up an error, "No matching provisioning profiles found for Applications/plumbsApp.app" - None of the valid provisioning profiles allowed the specified entitlements: application identifier, beta-reports-active, keychain-access-groups.
Now, dismissing this and continuing with the "Export", creates my .ipa file and my users are able to install correctly, with the correct url, of course. So, not totally sure why this is happening. I had the beta release of Xcode running but used the final release of Xcode6. Perhaps the beta, comment, in red-herring. Has anyone else experienced this, where the validation of the archive fails in this way but the App installs ok?
I am submitting my app to the app store which uses location services (GPS dot) and MKPinAnnotations and doesn't use anything else for a map, and it looks from what I have researched that the Routing Coverage File is used for overlays?
I dont think I need a Routing Coverage File, but when I go to publish, xcode errors out saying it is missing in the Itunes Connect.
The category for the app is Utilities. It was also navigation but I unticked this hoping it would solve the issue and it didn't.
How can I get around this?
I had the exact same issue earlier today when trying to publish an application that uses the MapKit but does not offer routing capabilities. I resolved it by deselecting all supported routing modes under '{Target} --> Capabilities --> Maps'. If you are just looking at the Info.plist file then you can remove the the MKDirectionsApplicationSupportedModes key and the CFBundleTypeName key that equals MKDirectionsRequest.
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<!--Remove both of these key/value pairs -->
<key>CFBundleTypeName</key>
<string>MKDirectionsRequest</string>
<key>LSItemContentTypes</key>
<array>
<string>com.apple.maps.directionsrequest</string>
</array>
</dict>
</array>
and
<key>MKDirectionsApplicationSupportedModes</key>
<array>
<string>MKDirectionsModeBike</string>
<string>MKDirectionsModeBus</string>
<string>MKDirectionsModeCar</string>
<string>MKDirectionsModeFerry</string>
<string>MKDirectionsModeOther</string>
<string>MKDirectionsModePedestrian</string>
<string>MKDirectionsModePlane</string>
<string>MKDirectionsModeStreetCar</string>
<string>MKDirectionsModeSubway</string>
<string>MKDirectionsModeTaxi</string>
<string>MKDirectionsModeTrain</string>
</array>
turn off map capability solved my problem,
xcode - next to general tap, you should see capability tab,
scroll down to maps section, turn it off,
general tab, change you build and version different from last time,
re-upload to app store.
This time it would not ask for routing profile coverage file,
Done.
This took me a long time to figure out, but the problem was with my scheme. It was the routing app coverage file location. I just change it to "None". Go to your scheme -> Edit Scheme -> Run -> Options -> Routing App Coverage File, change it to None.
see here
In my Info.plist file I have this:
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeName</key>
<string>CSV Data</string>
<key>LSHandlerRank</key>
<string>Alternate</string>
<key>LSItemContentTypes</key>
<array>
<string>public.comma-separated-values-text</string>
</array>
</dict>
</array>
Which mostly works.
The screw case happened when somebody took an Excel spreadsheet on Windows, saved it as CSV, and emailed it to their iPad, for import into my app.
The mail client gave the attachment a MIME type of application/vnd.ms-excel, which could be considered incorrect. I would expect that MIME type to be used for files actually in Excel format, not for just any file that was exported from Excel.
In the iOS mail app, I long-press on the attachment to open the file in some other app. Here is where things to wrong.
My app gets included in the list of available apps. I'm not sure whether to call this correct or incorrect. The file is CSV and has a .csv suffix, so I'm happy my app was invited to the party. But...
If I then click on our app to open that file, it "doesn't work", meaning that the OpenURL method in my AppDelegate never gets called.
In this case, two wrongs do make a right. If I lie and add com.microsoft.excel.xls to LSItemContentTypes, then it "works", meaning that (1) my app still gets listed in the Open In dialog, and (2) iOS actually gives me the file, and (3) because the file isn't really in Excel format but CSV, my app deals with it just fine.
But now the app is claiming to support actual Excel files, which it does not do.
This seems like a bug in iOS. Either don't list me in the dialog or actually give me the file.
Or am I doing something wrong?
I ran into a similar problem using passkit and found no solution to accept malformed MIME types. I suggest that you add a converter from Excel to CSV and accept Excel files! (:
Here's another post to help you with that:
Read data from Excel file in Objective-C (iPhone)
I created an iOS app and want to distribute it Over-The-Air. I followed this guide:
http://help.apple.com/iosdeployment-apps/mac/1.1/?lang=en-us#app43ad77ea
The App is signed with the enterprise certificate and contains the distribution provisioning profile.
When I try to download the App onto the ipad (using the technique described in this guide), a square icon with my download icon appears on the screen with the name "Waiting...", then a second later the name changes to my actual application name and then again a second later i receive the error message:
Unable to Download Application
"Your Application" could not be downloaded at this time.
in the guide, there are three troubleshooting tips:
if wireless app distribution fails with an “unable to download”
message, check the following:
Make sure the app is signed correctly. Test it by installing it on a
device using iPhone Configuration Utility or Apple Configurator, and
see if any errors occur.
Make sure the link to the manifest file is correct and the manifest
file is accessible to web users.
Make sure the URL to the .ipa file (in the manifest file) is correct
and the .ipa file is accessible to web users.
I checked all three things and they are fine.
What else could cause my download problems?
As alexey mentioned, too many reasons can cause that message. Apple use it as a "catch all errors".
You can diagnose it through the Console. Connect the device to your desktop and access it either from XCode's Organizer (mac only) or iPhone Configuration Utility (mac and windows). But...
It just ain't that simple! :-(
Console may be far from enough. Sometimes there is no relevant message there.
Then, the last resort is following a checklist. Doing all over from zero again. There are many out there... But following there's my generic and non-detailed checklist for Over The Air distribution, at the moment.
Have a Distribution build - This is the most complicated part, done always on the web, and Apple changes the steps all the time. In general, you need a certificate, an identifier and the provisioning profile. Listing devices is almost always required. My current choice is "Distribution -> In House".
P.S.: If you do want to list the devices, make sure the UDIDs are correct. Many issues reported here.
Set the profile under Project -> Build Settings - Since XCode 5, things changed. Instead of code signing with an identity you can clear all that up and set it under *Code Signing -> *Provisioning Profile. The Identity should automatically change to "Automatic". There's also no more need to manually download files from step 1 and install them. XCode manages that now.
Archive - In Xcode 5, there's no need any more to "Build for Archive". Just archive it. It should show up next on Organizer, and it will take some time if it's a big project. Many errors can come up on this step, but they're almost always related to code compilation and not to OTA.
Deploy - Now in Organizer -> Archives, select the proper archive (should be already selected as the most recent one) click on "Distribute", then Save for Enterprise or Ad Hoc Deployment. May be big wait now. When saving the file, there is an option to "Save for Enterprise Distribution". That is a completely misleading name. What it really does is create the plist file. If you have one already, it's fine. You can even manually edit it, which is generally better. The plist be needed for step (5). Here's a good one:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>http://example.com/app.ipa</string>
</dict>
<dict>
<key>kind</key>
<string>full-size-image</string>
<key>needs-shine</key>
<false/>
<key>url</key>
<string>http://example.com/FullSizeImage.png</string>
</dict>
<dict>
<key>kind</key>
<string>display-image</string>
<key>needs-shine</key>
<false/>
<key>url</key>
<string>http://example.com/Icon.png</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>com.example.app</string>
<key>kind</key>
<string>software</string>
<key>subtitle</key>
<string>for iOS</string>
<key>title</key>
<string>My App</string>
</dict>
</dict>
</array>
</dict>
</plist>
Distribute - Skip this step if you want to install it using XCode or iPhone Configuration Utility. You're done. This is putting on the file on a web site. "Simply" add a HTML page with a href link such as this:
itms-services://?action=download-manifest&url=http://example.com/app.plist
Unfortunately dealing with web servers is never simple. So also check the server mime-type! I've made a couple PHP files to deal with them, if your server supports php. Just keep your files as they are (the plist, html and ipa) and link to app.plist.php instead:
app.plist.php
$file = fopen("app.plist", "r");
while(!feof($file)){
$line = fgets($file);
print str_replace(".ipa", ".ipa.php", $line);
}
fclose($file);
?>
app.ipa.php
<?php
header('Content-type: application/octet-stream');
$file = fopen("app.ipa", "r");
while(!feof($file)){
$line = fgets($file);
print $line;
}
fclose($file);
?>
Verify - Ensure that all files listed in the assets array are available to download. If any of these files return 404 or such (including the icons) the entire install will fail. You must either (A) make those files available or (B) delete those missing entries from the plist. The icon entries are not required for the download to work.
Here is an example plist with no icons:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>http://example.com/app.ipa</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>com.example.app</string>
<key>kind</key>
<string>software</string>
<key>subtitle</key>
<string>for iOS</string>
<key>title</key>
<string>My App</string>
</dict>
</dict>
</array>
</dict>
</plist>
The file examples are a very important part of the checklist. They have to be 100% correct.
Double check the plist and html files!
P.S.: I'm writing this answer because, in my case, it was a "simple" matter of wrong link on the .plist file. And, as such, it's hard as hell to diagnose. Well, only doing this checklist could I find the error! It was pointing to "another-app.ipa" rather than "app.ipa"!
There are a plenty of reasons to cause this message.
The best way to diagnose it is to connect a device to Mac and look Console for the device in Organizer.
In my case, for example, it was:
verify_bundle_metadata: This app was not build to support this device family
Answering my own question:
The problem was that one of the thumbnails did not have the correct path set in the manifest.plist - so not only the ipa needs the correct path, but also the temporary download icons, otherwise the installation will fail with the mentioned error message.
Another Issue that it could be is that both the .plist AND the .ipa need to be hosted with HTTPS and not just regular HTTP. The software package string should look like below:
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>https://example.com/app.ipa</string>
Stupid little oversight but it was tripping me up for awhile.
We did experience the very same error message when trying to install an iOS 5+ app to an iOS4.3.5 phone.
Did you also check deployment/build targets and target architecture to match the device(s) showing that issue?
Make sure the casing is matching in all the files. They tend to be case insensitive.
In my case the issue was on my device an older version of same app was installed with same bundle identifier (downloaded from applstore) so now when I was trying to download its new version via enterprise distribution it was doing nothing, no error at all. Delete existing version from the device solved my issue.
I found in console.
installcoordinationd(MobileInstallation)[99] :
****bundleID****:5:11:1:1:Updating PlaceholderMetadata for
****bundleID**** with failure 1 _LSInstallType 1, underlyingError
(Error Domain=MIInstallerErrorDomain Code=13 "Failed to verify code
signature of
/private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.IoCSM9/extracted/Payload/App.app
: 0xe8008016 (The executable was signed with invalid entitlements.)"
UserInfo={LibMISErrorNumber=-402620394,
LegacyErrorString=ApplicationVerificationFailed, SourceFileLine=147,
FunctionName=+[MICodeSigningVerifier
_validateSignatureAndCopyInfoForURL:withOptions:error:], NSLocalizedDescription=Failed to verify code signature of
/private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.IoCSM9/extracted/Payload/App.app
: 0xe8008016 (The executable was signed with invalid entitlements.)}),
source 17>
Here we should look at:
Failed to verify code signature of App.app
The executable was signed with invalid entitlements.
In my case it was because i downloaded enterprise build from amazon. But the provisioning profile, which it was builded with, was expired (figured out in developer console).
Another one with the other purpose:
"This app could not be installed at this time."
UserInfo={NSLocalizedDescription=This app could not be installed at
this time., NSUnderlyingError=0x100cbd3c0 {Error
Domain=MIInstallerErrorDomain Code=64 "Upgrade's
application-identifier entitlement string (BBBUUUU.com.bundle.www)
does not match installed application's application-identifier string
(CCCEEEE.com.bundle.www); rejecting upgrade."
UserInfo={LegacyErrorString=MismatchedApplicationIdentifierEntitlement,
FunctionName=-[MIInstallableBundle
_validateApplicationIdentifierForNewBundleSigningInfo:error:], SourceFileLine=878, NSLocalizedDescription=Upgrade's
application-identifier entitlement string (BBBUUUU.com.bundle.www)
does not match installed application's application-identifier string
(CCCEEEE.com.bundle.www); rejected
Here i just removed the previous version of the app. The error was, because i changed the team for the bundle ID and it was installed the app with previous bundle ID.
Open console with:
Xcode > Window > Devices
Select the device
Expand a console with with a box with an arrow inside of it in the bottom left corner.
Try checking bundle identifier in your XCode and .plist file
In my case I did following to get rid off "cannot connect to dl.dropboxusercontent" message after providing ipa shared link.
1. Removed md5 section from plist
2. Uploaded 512*512 and 57*57 images to drop box, and provided shared link in fill_size_image and display_image in plist.
The first thing to check here is that the device you are installing on has the correct OS for the app your are installing. For instance, if the app is built for iOS 11, and your device has iOS 10 on it, then the app will install but you will see this error "Unable to Download Application".
In my case, there was a problem with incorrect file permissions of the FTP folder and the files inside (manifest, ipa, images). Check that they have 775 (rwx) and that Owner/Group is your owner.
The error in the device console was like "Cannot connect to iTunes Store" or "Failed artwork for bundleID" or "Failed to load placeholder artwork for bundleID". But it's just about the files.