iOS OTA Distribution "unable to download" immediately upon clicking the link - ios

I have an iPad app that we are distributing over the air for QA and Beta testers; we have both a debug and and a release config that we are building. Our build process puts together the website and the PLIST manifest file that that iOS needs to install the app. The release build downloads correctly, but the debug build does not. The only difference between the two manifest files is the application that it's pointing to. I've checked server permissions, signing issues (the same app that won't install OTA can be pushed via iTunes) all to no avail.
Most of the other articles out here deal with the file nearly installing and then choking (that's typically the wrong provisioning file).
Thanks for any help you can provide.

I've gotten this error before when the device has a version of iOS below the supported version of the application.

Check the url on plist file. Make sure it has correct path with http://

It turns out the problem was two-fold. One of the iPads had too old of iOS, and the other was there was a hidden character in the URL

It's also possible that the bundle ID is incorrect. We have multiple bundle IDs so we used to get them mixed up. In addition the icon URL is incorrect. Had that problem too

Related

Xcode: Could not locate installed application. Install claimed to have succeeded, but application could not be found on device

I manually deleted my app from the iPhone and now I get this error message when trying to run it again from Xcode.
I cleaned the build folder, restarted the device, Xcode and the Mac, nothing helps.
I also tried everything that's mentioned here: Install claimed to have succeeded, but application could not be found on device
How do I force a re-installation?
As always, when the question is posted on SO, one finds a solution ;)
I edited the Scheme, setting the build configuration from debug to release and that installed the app again. Changed it back to debug and now it's running again as expected.
I ran into the same issue while testing a app on iOS 13 via XCode 11.0. Building via the legacy system solved it (File > Workspace Settings... > Build System > Legacy Build System).
Hope it helps
I had a similar issue after one of Carthage/XCode updates. It means iOS was not able to install app on the phone. XCode apparently is not able to provide this information directly. The first thing to do is open your phone console - go to Window/Devices and Simulators then select your device and click Open Console. In the console you can search for your app name what should provide you more detailed fail info. In my case it was sth like this:
Applications did fail to install: (
"<LSApplicationProxy: 0x118913b60> com.mydomain.myapp (null) <com.mydomain.myapp <INVALID >:0>"
) (appInfos: (null))
There was another console log few rows before flagging the problem:
0x16f4df000 -[MIExecutableBundle codeSigningInfoByValidatingResources:performingOnlineAuthorization:ignoringCachedSigningInfo:checkingTrustCacheIfApplicable:error:]: 789: Code signing identifier (org.alamofire.Alamofire.iphonesimulator) does not match bundle identifier (org.alamofire.Alamofire.iphoneos) for /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.E83T1l/extracted/myapp.app/Frameworks/Alamofire.framework
There was an issue with one of the frameworks Alamofire I'm using in the project. I changed bundle identifier of the project and build framework again what solved the problem.
Hope it helps!
In my case, the problem was an embedded framework that was not being signed. In the General tab of the project settings, setting the embed setting to 'Embed & Sign' did the trick.
In my case it was a problem with new Development certificate. It's created automatically after Xcode updated to 11 and may not be included in current provisioning profile.
I was facing similar issue in Xcode 11.1. I have fix this issue. Not sure about this solution that it will to work for all or not.
My device iOS version was older then the iOS Xcode target build version.
Steps:
I have put Xcode target Device to iPhone device OS version.
Delete derived data
Start xcode and open project
Clean the project and gererate build and install in device
Note: Please check your developer account, certificate validation and already registered device warning.
Hope this solution will help some peoples. Happy coding.
After trying everything here, for me the solution was to change my distribution profile to use the new Apple distribution certificate that covers all apple platforms. This should be compliant with xcode 11 (if you're not experiencing one of the other million problems since the "upgrade").
The cert change is mentioned here:
https://developer.apple.com/documentation/xcode_release_notes/xcode_11_release_notes
Cert creation instructions here:
https://help.apple.com/developer-account/#/devbfa00fef7
Once done, make sure the correct profile is selected in Signing & Capabilities, and 'Apple Distribution' is selected under Build Setting -> Signing for the appropriate build configurations
A solution that solved this issue for me was to check the signing team for my tests target. Selecting the same development team then meant that my app was able to be built and run on device.
Build system: New Build System
Xcode: Version 11.1
Uninstall all the other apps that are under the same "Organization" or "Bundle Identifier" with your current app and try again.
It works for me. Hope it does for you too.
On your iPhone go to Settings/General/Profiles & Devices/Apple Development: "YOUR APPLE ID" and delete all apps from there. It fixed the problem for me.
It happened to me when trying to launch a watchOS app on a real device.
The only solution that worked was:
Delete iOS app from device
Delete watchOS app from device
Close and reopen Xcode
Clean build folder
I did a Product -> Clean then Build, and it was able to run.
Go to settings on your phone and wipe out all certificates and apps and then install your app again. That helped me
Problem occured on XCode 11
TL;DR:
Try changing Embed option in General=>Section Frameworks, Libraries.. to Do Not Embed (although it sounds strange)
In my General=>Section Frameworks, Libraries.. list are Security.framework and the CocoaPods Pods_projectname.framework amongst others. Default setting of these two was Do Not Embed. Sounded strange to me, so I changed it without need alternating to Embed & Sign or Embed Without Signing. With both options the error occured!
On your iPhone go to Settings/General/Profiles & Devices/Apple Deelopment: "YOUR APPLE ID" and delete all apps from there. It fixed the problem for me.
This was the solution that worked for me.
Please double check the bundle ID of the installed application to see if it is re-applied, this will also cause this problem .I uninstall the app and solve the problem.
In my case i have PROD certificate and trying to install the app in the device, later i changed to development certificate it got installed.
As Marcin's answer suggested, I visited the phone console and in my case, it is this error message:
-[MIFreeProfileValidatedAppTracker _onQueue_addReferenceForApplicationIdentifier:bundle:error:]: 182: This device has reached the maximum number of installed apps using a free developer profile: {(
So if you are signing your app with a Personal Team certificate, make sure that you don't have more than 3 apps.
Read more here: Why can I not install more than three apps?
As for me,
I added a custom key-value to Info.plist of main watchOS application file. That was wrong.
After removing it, all works correctly.
It seems this is not allowed but where is no other information about it.
If you have other under-development apps installed, try uninstalling those you are not using, and run Xcode to install your app again. It works for me.

Ios share extension does not work when installed by testflight but works installed by xcode

Installed with testflight the application does appear in the list of target applications to share an image with. When I select my application icon in the list I do get a normal Post dialog. After pressing "Post" in the dialog the application does open but nothing else happens.
When the same version of application is installed with xcode the shared file is delivered and the application displays the shared image.
I am not even sure how to debug such an issue as the application installed by testflight does not appear in the list of installed applications in xcode Devices window. Nothing that I can find in device logs either.
Please suggest any approach to troubleshooting the issue.
Update: I found a way to get much more detailed logs from device than the one provided by xcode's "Devices" window: deviceconsole utility. This gives at least some information to approach troubleshooting.
Update 1: It turns out that the application installed through ad hoc ipa file exported from the same archive that was submitted to testflight shows the same problem. This allows much quicker testing turn around.
This answer indicates that the problem can be caused by "Deployment Target" of extension set above the ios version of test device. I did try different combination of this setting in the application and extension, nothing helped thus far.
Update 2: I created code-level support request with apple for this issue and provided full source of the application to them. After few months of apathetic communications they concluded that the problem is due to a bug and suggested to create report Apple Bug Reporter. I did that and after another few months of more apathetic communications the issue was promptly closed on the basis that the application does not crash. Frustrating, but I still need to resolve the problem, now looks like without help from vendor.
If the deployment target is higher than the version number of the actual phone, your code cannot run. So the only choice is reducing the deployment target of the extension to be the same as the app.
I’d check if you have somehow set different deployment targets for debug and release.

iTunes Connect Errors occurred in the app thinning process, and your app couldn’t be thinned?

I Uploaded the build via Xcode Yesterday it worked fine but while uploading today the build is uploading perfectly but after 10 minutes i got a email form apple stating that.
While processing your iOS app, ---------------Build(1.0.22), errors
occurred in the app thinning process, and your app couldn’t be
thinned. If your app contains bitcode, bitcode processing may have
failed. Because of these errors, this build of your app will not be
able to be submitted for review or placed on the App Store. For
information that may help resolve this issue, see Tech Note 2432.
I only changed the one line of code and changed the Build Number. And, I uploaded 4 build got the same Error.
I met with this issue today, I used google-api-objectivec-client-for-rest (as framework).
I tried all the solutions above, but failed.
Now I fixed it by copying all the source of google-api-objectivec-client-for-rest to my own project. Hope it helpful to you.
MY SOLUTION THAT DID NOT WORKED BUT MAYBE CAN GIVE U A WAY OUT
In My own case, i developed my IOS APP with PhoneGap
After so much research, was told to disable bitcode from my ItuneConenct App Account https://developer.apple.com/library/mac/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ChangingAppStatus.html
And was introduced to a new phonegap plugin to disable bitcode in my IOS APP https://www.npmjs.com/package/cordova-plugin-cs-disable-bitcode
which i added to my Phonegap app config.xml file
Yet after rebuilding my phonegap IOS app and uploading to ItunesConenct using Application Builder (Got a successful message from the upload). Few mins' after the upload, I got same message from Apple with the same error.
This can give you a hint
Finally got it to work. In our case, the error was in one of the embedded frameworks. Generating a Production Ad-hoc build and then trying to export it generated an error message that pointed us to an error in a setting within one of the framework files. The framework has been there for a while and we never had any issues with it until this release.
I had the same problem and I found the solution. In my app, I had the Google Plus framework: GoogleOpenSource.framework. This framework was the problem. I searched about the latest update in Google Plus: https://developers.google.com/+/mobile/ios/upgrading-sdk.
The latest version was 1.7.1. This version has the same problem. In my app, I removed the login with Google Plus (deprecated https://gyazo.com/685a58f98ee0b0fca16a6bd83636aad8) and I added Google: https://developers.google.com/identity/sign-in/ios/sdk/
This works for me.
A greeting.
Hey guyz My App has been approved by Apple Store.
The trick i used was this
Deleted the plugin folder on my App root directory before building
Because most plugins were not compatible with Apple has to use just few of them on my manifest file
<plugin name="org.apache.cordova.inappbrowser" />
<plugin name="org.apache.cordova.network-information" />
<plugin name="org.apache.cordova.splashscreen" />
<plugin name="cordova-plugin-whitelist" />
i was surprised when Apple sent me a message that my App has been Approved just now.
I Home this trick work for someone
If you are having this problem recently, i.e. since September 2016, it may be due to having a 'special character' in the title of your app.
I had several targets for the same code, some of which would process OK and some of which would fail. The ones that were failing all had Apple symbols in the title, for example one app was called '🇨🇲 Flags'.
Credit to Krati Rastogi: https://forums.adobe.com/thread/2205923
I had this happen a couple days ago and the temporary solution for me was to not include bitcode for iOS content, which is an uploading option (see image). Apple suggests to do an ad hoc export with an ad hoc provisioning profile to receive the errors and logs of the failure, but I'm unable to reproduce the error(s) and the ad hoc export is successful each time. Will update this post when I find out how to re-enable bitcode, but for now this seems like a good temporary fix. -Update: there was an error in the name of one of my project folders, mixup with symbolic folder name, when I corrected the name to match what was actually in the folder structure I was able to upload properly-
I've experienced the same symptoms and have found a solution.
The root cause of the issue is invalid/incorrect keys in a given bundle's embedded Info.plist.
This is typically the .bundle contained within a third party library e.g. GoogleMaps SDK.
The steps for remediation are:
For each .bundle containing only resources:
Remove the key/value CFBundleExecutable
Change the value for key
CFBundleSupportedPlatforms to iPhoneOS (Item 0, first element in the array. The previous value was iPhoneSimulator in my case)
The technical reason is that CFBundleExecutable should not be present in a bundle's plist if there is no executable. The value for CFBundleSupportedPlatforms is self explanatory, it should be iPhoneOS.
Tech Note 2432 mentions the above two keys but does not elaborate how to resolve the issue.
I hope this solution works for you.
As another user above stated... Remove the Plug In Directory and it solves the problem!
I just uploaded a fully functional version of my App with all of my Plug Ins. When I use build.phonegap.com to compile my IPA file, I have no Plugin folder in the ZIP file. The plugins are correctly referenced in my config.xml file.
It works!
I have no clue why this was ever an issue, but that is the ticket to move forward!
Finally, I made this work!!!
Just like #applejack42 said, you must remove CFBundleExecutable key of all 3rd party library info.plist file.
In my case, I just remove this key from JSONModel info.plist, and submit.
Success!
I really hope it works for you, because that issue make me crazy.
update xcode to 8.0 which published at 0914 from apple store , rebuild project and submit to iturns , the issue was not found , instead any detail info for anouther issue which use ios 10 sdk required . i have submited success, and waiting for approval .
Ive attempted various build and submitted to Itunes with Xcode 8 and 7, with no success.
Deleting my plugins folder was not the solution, neither was greping through all my .plist's to find the CFBundleExecutable. At this moment its just waiting on further discovery from the community and or returning to our 3rd party resources and asking them to update their libs which may not be as easy as apple is suggesting us to do.
To identify the affected libraries I built to an iPhone with Bitcode enabled and in my case their are three libs that need updating. This may not be the best solution but if you need an explanation for your superiors this may save you some time in identifying what needs updating.
I will update my thread as I continue along this road.
Apple recommends to test by archiving the app first and then exporting the app for ad hoc distribution. If there are errors, you can then see this in the logs, you can access them from the export dialog.
My favorite solution, if there is no error during export:
update cocoapods
run pod install
clean the project and resubmit
It just worked for me, no clue why, but it might be worth a try instead of wasting hours on finding a solution for a non existant problem ;)
For me the Issue was that one of my frameworks wasn't embedded and signed . hope that might help someone
I have met with this situation with Xamarin IOS Project in Visual Studio
I have solved in
Clean All
Rebuild All
then archive your project

IOS MDM Server IOS App OTA Deployment

We've built an MDM server using a mac mini.
We have 2 applications to push out to a number of users. One app will push and download on the remote devices with out a problem. The other displays an error "The app could not be installed at this time"
This second application is an older application.. however we are building it for 6.0. In the console we see this.
ipad SpringBoard[65] <Warning>: could not save thumbnail for downloading icon: image=(null) path='/var/mobile/Library/SpringBoard/DownloadingIconImageCache/
This app can be built an installed when a device is connected to the build computer. We have all of the signing the same as the first application. We can also archive the app without any errors. What would cause this app to not install, or what should we start with?
Several notes/ideas:
a) Take a look at this (they mention the same problem)
Trouble installing AD-HOC distribution through safari
iOs application crash on install
Ad-hoc distribution fail
http://community.phonegap.com/nitobi/topics/not_installing_my_application_in_ipod
b) Can you please post your manifest (if you are installing inhouse apps)?
Please double check that that if you pointing to icons in this manifest, the links are correct.
Ok this took days to figure this out... In my situation at some point another icon was added into the build settings. We did change the name of the bundle so I'm assuming that xcode automatically populates the icon information?
In the info tab check to make sure you only have one property for 'icon files' (to be clear you should have the ability to open the drop down menu and expose sub menus... What I had was 2 'icon file' sections.) After I deleted the second set of icon files it pushed fine.
Hope that helps others figure out a very frustrating situation

Xcode 4.3: Codesign operation failed (Check that the identity you selected is valid)

After installing Xcode 4.3 I can't validate and distribute application using Organizer.
While building, signing and validating in Xcode is OK, the validation in Organizer fails with the message in the title of this question.
First, Xcode 4.3 can download provisioning profiles automatically (there's an option in Organizer), but it downloads only development profiles and ignores distribution profiles as if there are none. OK, I downloaded and installed it manually and it appears in Organizer. Then I set proper Code Signing Identity both for project and for target and use Distribution profile that matches Distribution certificate in my keychain. Then I do Archive (build-sign-verify) and no errors, in the log I see green checkmarks for CodeSign and for Verify steps. Looks good and the archive appears in Organizer.
And that's where all goes wrong, I just select Validate, choose the new version I just prepared in iTunes Connect, choose correct code signing identity, same as was used for Archiving (actually, there are no other choices in my case), it asks for iTunes login/password as usual, and then says
Codesign operation failed
Check that the identity you selected is valid
Ahhh!!! Why!? It had no problems while archiving it, then same code signing doesn't work when trying to submit to AppStore. Well, not even submit, but validate before actually sending it. So this issue is local to my machine. The very same signing and validation that is successful during build, fails in Organizer...
I tried everything, re-installed Xcode, removed/revoked and re-issued all certificates, removed duplicated private and public keys from keychain, put all certificates in one "login" keychain, issued new profiles, installed Application Loader 2.5.1, and so on... still no luck.
Could it be that I have some left-over from previous Xcode installs? Or that I have to update some tools to make Organizer work properly?
Meanwhile, if anyone knows another way to upload binary to AppStore, please share. I couldn't figure out how to do that using Application Loader, when it asks me to choose a bundle to upload, all I have is xcode archive created by Xcode in Archive step. How do I get my hands on iap or whatever file the Application Loader wants from me?
I've discovered that Xcode 4.3.1 has a serious issue validating apps with resources within a directory tree within an application bundle.
Apps can pass validation within the Xcode "Build for Archive" process - it only fails when the validation is run via Organizer.
After spending hours trying to trace down the usual code signing entitlement issues, I eventually noticed the following line in the system console when the export fails:
3/10/12 2:32:48.450 PM [0x0-0x261261].com.apple.dt.Xcode: /Users/chris/Library/Developer/Xcode/Archives/2012-03-10/Coverage 3-10-12 2.32 PM.xcarchive/Products/Applications/Coverage.app/Tiles/T-Mobile-roam/4: Is a directory
I spent a day trying to isolate this bug, and I've finally nailed it.
The code signer in XCode 4.3.1 when validating for the App Store or saving for AdHoc distribution chokes whenever there is a subdirectory in your bundle that has the same name as its parent directory.
For example:
test/test/file.x -- FAIL
test/test2/file.x -- WORKS
This seems to be new in Xcode 4.3.1, and hopefully will be fixed soon.
Notes: This thread seems related: https://devforums.apple.com/message/630800
I was the original poster on the Apple Dev Forums...
https://devforums.apple.com/message/621193
I've also attempted to bring this to the attention of the AddThis developers:
https://www.addthis.com/forum/viewtopic.php?f=19&t=38292
As mentioned in the other posts, the only way I've found to prevent the code signing failure is to remove the ATResources.bundle file from the project.
Of course, this bundle contains many of the necessary images for AddThis, among other things, but the error no longer occurs.
I'm hoping this helps someone else discover the correct way to solve this issue.
The problem is AddThis or explicitly the ATResources.bundle in the AddThis folder.
So you have two options:
The first one is using an older version of Xcode to Archive.
The second one is relocate all the images inside the
ATResources.bundle into a folder, and copy the content of the
Localizable.strings into your own Localizable.strings
Then open the FBDialog.m file and search for "close.png", remove that
line of code and replace it with:
UIImage* closeImage = [UIImage imageNamed:#"close.png"];
Now you're ready to Archive.
Finally consider to file a bug report in https://bugreport.apple.com/
In my case, it was a damaged custom framework.
I have so many subdirectories on my bundle that have the same name as their parents, so I was not able to validate and submit. The only solution I found is to download xcode 4.2.1 from Apple developer center and install it side by side with xcode 4.3.2. Then I used it to validate and submit.
I'm developing on Sencha 2. The key here is to launch the System Console from Apps/Utilities and look at the error log when distributing. That's the easiest way to see the offending directory. In Sencha2 its in the /sdk/src/device/device. Good stuff: Still happening in xcode 4.3.2
Just confirming that the problem was indeed nested folders with the same name in my app.
In my particular case this was the issue:
problem: images/packs/1/1/img.png
solution: images/packs/pack_1/1/img.png
Smooth sailing after that. This happened in Xcode 4.3.3
found the solution, it really works for me. hope this will help you guys.
if the issue is because of Addthis, try following
noted that the inside ATResources.bundle you have a folder named ATResources.
ATResources contains exactly the copy items (ADDTHIS.db,en.lproj,images) which is present in ATResources.bundle. so we can simply delete the ATResources folder from ATResources.bundle.
for deleting,, select the files from ATResources.bundle and right click , show in finder -> and remove ATResources folder.
the major issue is because subdirectory in your bundle that has the same name as its parent directory.
:)
I had same problem in my project (in xcode 4.3.2) and as per all answers I checked for any .png file starting with ._* and also checked folder and its subfolder are different name.
Also checked code signing identity as per requirement, but did not succeed to solve this problem.
After whole days effort finally I got reason for "Packaging operation failed" error in my project.
In my case, I have classed About_us.h and About_us.m and by mistake I import header file like #import "About Us.h" (white space in middle). So when I loaded app on Device it will successfully loaded but when I try to create ipa using archive its give me error and return me Estimated App Store Size just 143 kb.
Finally while I change header like #import "About_Us.h" and try to make ipa I got real size in proper MB.
Hope this will help someone.
I experienced this issue on Xcode 5.0.2 (5A3005) with 2 completely separate folders that happened to be named the same thing.
Most other cases in this thread focus on the parent/sibling relationship, but I think it's any two folders with the same name will cause this failure.
I had same problem as you do, and radven response inspired me:
did you see that ATResources directory contains nothing more than just copy of its parent?
ADDTHIS.db
en.lproj/*
images/*
ATResources/ADDTHIS.db
ATResources/en.lproj/*
ATResources/images/*
As a quick-and-dirty fix I removed the redundant subdirectory. Application builds and seems to work fine, and Xcode is able to sign.
Let me know if I missed any consequence of this fix?
Gee, I spent like an hour on this problem.
I just removed AddThis from my project. Do it and it would work.
restarting xcode made the buttons work for me. they were greyed out before, in case anyone here is having the same problem
Techi50 alluded to this but to be clear - under Xcode 4.3.5 there is a serious bug where code signing will fail if you have subdirectories with the same name as the parent directory. In the Sencha Touch 2 SDK tree, for example, there is
/sdk/src/device/device
argh... hours of trying to code sign with no luck... rename to:
/sdk/src/device/device_epic_fail
(since I don't need those libraries anyway)
and I can code sign.
And one big bug hunt is over. Apple... fix please...
Updating the AddThis SDK from 0.1.7 to 0.1.9 fixed this problem for me (using XCode 4.3.1).
I've determined another cause of this error, which occurred for me in Xcode 4.6.2 (4H1003). I had a subproject building an executable. This executable is a helper tool which is copied into my app's bundle when it builds.
The app has a min deployment target of OS X 10.7 and builds for 64-bit Intel as a result.
The helper tool, however, was set to a deployment target of 10.6, and was building for 32-bit/64-bit Intel.
Changing the helper tool to also build for 10.7 and 64-bit Intel only fixed the error. I can reliably recreate the error by changing the helper tool back to 32-bit/64-bit Intel; this is not a 'erm, zap your PRAM' fix.
As #radven and #tomek-cejner mentioned sometimes some extra directories could cause problems. Maybe if named improperly? for me the offenders were different.
Gruntfile.js, karma-e2e.conf.js, karma.conf.js, and the entire node_modules directory.
see: How to build IPA for distribution with TestFlight with XCode 5?

Resources