We normally have 'Payload' folder as root once we unarchive IPA files. However, suddenly Xcode has started creating IPAs with 'Applications' folder as root. Hence MDM is failing to locate files.
Has anyone has faced a similar issue? We are running Xcode version 6.1.
Make sure the key "LSRequiresIPhoneOS" in the info.plist has the value "YES", and make sure the key has the correct case, i.e., IPhone versus Iphone. Earlier versions of Xcode were not as picky about that.
I assume your Deployment Target is 8.0
Validate your Settings from the Editor Menu
Double check info.plist for the following entries.
CFBundleInfoDictionaryVersion | String | 6.0
LSRequiresIPhoneOS | Boolean | YES
Without it, the archive export will build an iOS IPA file with the OSX Applications folder.
I followed the steps in this post and other posts (adding CFBundleInfoDictionaryVersion and LSRequiresIPhoneOS to .plist file) but nothing worked. Here is what happened on my end:
I renamed my project and for some reason, the rename seem to "unlink" my .plist file from my project. I had to go to the project - Info tab and edit the list of parameters there. Add
CFBundleInfoDictionaryVersion | String | 6.0
LSRequiresIPhoneOS | Boolean | YES
Under
Custom iOS Target Properties
I have created .xarchive file using xcode 6.1 and then created .ipa file as per my answer here How to convert .xcarchive to .ipa for client to submit app to app store using Application Loader.
Now i have unarchieved my ipa file and it is having same folder structure as normal one, i.e. folder named "Payload" is available(no any Applications file). Also MDM is also working fine with that. Please check the way you have used, or else try this way.
Here's what I did - instead of "zipping up" the project file, go into XCode (I'n on version 7.x), and go to PROJECT >> ARCHIVE - and archive that sucker.
It auto archives as an IPA in the proper structure.
The way I did it before was by ZIPPING it up from the FINDER app, and then changing the extension to IPA -- DONT DO THAT.
Once it's archived (from within XCode), it shows up under ORGANIZER, so go there to submit it to apple as a new build.
This was my fix after half of night of trying to submit with Application Loader and it worked fine - had a dozen other issues prior to this but each issue was knocked off the list one by one, so maybe it wouldn't have submitted had I not fixed those, but the above process submitted the first time I tried it - and that was after using Application Loader probably 15 times with no dice.
I just Clean (Command + Shift + K) the project and the error has not appeared
Related
I have made an unsigned .IPA app using xcode 6 and swift language.
I have compressed the .app file and change its extention to .ipa.
When I want to install this .ipa file on my jailbreaked iPhone, this error is appeard:
"the app 'youtapp.ipa' could not be added to your iTunes library because it is not a valid app".
Would you please let me know what the problem is.
In my case I was using the "Save for Ad Hoc Deployment" option from Organizer to create an ipa file. It appears however that this is broken in XCode 6. Your answer from Jan 1 got me thinking so I did a little digging.
I renamed the exported ipa file to .zip and opened her up. XCode is now putting the .app file inside a folder named "Applications". So I went ahead and renamed this folder to "Payload", zipped it back up, and renamed the zip back to .ipa. Sure enough when I dragged this new ipa file to iTunes it works fine and can be installed on my phone.
Seems to me a bug in XCode, I think I should report it to Apple.
I had this exact same problem using Xcode 6.3 when building my iOS app. It seems that the packager does not complain when the following setting is enabled even though the target is an iOS device:
Application requires iPhone environment:NO
You need to set the this to YES and it will name the folder correctly to Payload.
I had a similar issue while trying to create an .ipa for adHoc distribution for one of the Old project (built a year ago by ex-developer). After a lot of research in google and following this link - here. By replacing the .plist file with the existing working projects (obviously - the relevant icons/bundle display name/identifier) and renaming with the current .plist name. It worked for me.
I literally spent about 3-4 hours to fix this issue. Hope it helps some one.
environment was native - iOS app.
My problem was that I forgot to put the .app file in the Payload folder. After putting the .app file in to the Payload Folder, I zip the folder and change its extension to .ipa.
It works correctly.
I've got an app that I created that I'm trying to test on an older iphone 3g. I've used this phone many times for testing but this new app for some reason will not accept the build.
I've done some searching and found that I need to charge the architecture from "armv7" to "armv6", I did this in both the project and target. After doing that I get the following error when trying to build to the device (construction is the name of the app)
Could not launch "construction"
No such file or directory (/Users/Matthew/Library/Developer/Xcode/DerivedData/Construction-cqtujdbjhpvbkrehtfzwvuhvxdrs/Build/Products/Debug-iphoneos/Construction.app/Construction)
But I can build in the simulator at it works fine... any idea?
thank you so much - clearing UIRequiredDeviceCapabilities in Info.plist would have never appeared to me.
None of these solutions worked for me. I'm using XCode 4.5 and ML. What I ended up doing (and still need to test thoroughly), was to re-create my project, started clean and then moved all sources and libraries to the new project and chose my provisioning profile for this new project. In the copy, I also manually copied the contents of the old Info.plist file and pasted them onto the newly Info.plist replacing them all.
In my case, I'm using CorePlot and that library needs armv7 (according to linker), so I can't just go armv6.
What I'm trying to figure out is when (cheap) XCode changed some settings to not run as a debugger on the device. I'm guessing something in the 'project.pbxproj' file. Otherwise I can't explain why the newly created project works and the old one doesn't.
I know this solution might not work for everyone, as in my case, as would lose all svn changes.
I'll post any progress on this.
My next step is to add CorePlot and let the project build it and not use the prebuilt one.
None of these worked for me either. But this DID work...
DO THE USUAL THINGS:
I cleared the build directory (cmd-k),
cleared the DerivedData (see prefs|Locations),
deleted the app from my iPhone 5,
unplugged the iPhone, and
restarted Xcode.
AND LASTLY DO THIS:
Open Xcode Organizer. Click on Devices | (your device name) | Applications. And finally, delete your application from here (aka. delete the app from your device, AGAIN).
Build and run...
Sorry I answered my own question! I figure I should leave this up in case anyone else has the same problem... I didn't update the plist setting to armv6 before... I did have to delete the armv7 in the plist to make it work
I was given a build succeeded and the iphone simulator worked well after building and running, but the .app under the product group is in red.
I tried the following ways but none of them worked so far:
(1) changing the Build Locations to a custom location in Preferences and reopened the project
(2) code signing changed to iphone developers
(3)base SDK set to be iOS 5.1
No error came out throughout the building process and the actual .app files can be found in finder when the build location is set to be a custom folder (For the default ~/Library/Developer/Xcode/DerivedData situation, the .app just can't be found in finder but the building went successfully as well, maybe it's hidden?),
So are the .app s found in finder the successfully built packages? But why can't xcode find them?
the .app now still in red, can any one tell me how I can turn the .app to a normal black? :-(
thx˜˜
Have you tried clearing your XCode project and restarting XCode?
Or maybe you have changed the product name in your build settings?
Packaging operation failed - this message now showing while i try to make .ipa file for Ad Hoc distribution in Organizer
I checked certificates, checked project directories (after reading this)
Xcode dont showing any errors or something similar. Log Navigator show no errors (only old warnings).
So here is question: anyone else encountered a similar problem? And if answer is positive any suggestion to solve problem?
P.S.: in Xcode 4.2.1 all perfectly works
Occasionally this is caused during automatic resigning during packaging with a different distribution certificate. This can occur when you start a new project and you're building both dev and release builds with your Team Provisioning profile, then you create a distribution (ad hoc or otherwise) certificate for this specific bundle ID and attempt to sign the archive with that new certificate.
The fix is to dig inside your build settings for the code signing identity and set the build release identity to the same distribution certificate that you're attempting to sign your archive with, either your ad hoc or app store certificate. You can leave debug builds as your team cert.
In the below example, the problem has been fixed. Use the build settings search box to look for the code signing identity. "Release" is probably set to "iOS Team Provisioning Profile" when it should be set to "iPhone Developer: Your Name" which is the same certificate you're trying to sign your archive with.
I had same problem in my project (in xcode 4.3.2) And as per all ans 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 Not Succeeded to solve this problem.
After hole 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 get the same problem.
PNG files starting by ._ are not visible, even if you display hidden files in Finder (defaults write com.apple.finder AppleShowAllFiles 1 in Terminal)
But if I browse my SVN folder using Versions app, I can see there are PNG files starting by ._
For each of these files, I opened it with Preview app, duplicated and re-saved with the same name, then I removed all the ._ files because they are no longer needed.
Now I can create an archive and distribute it through an IPA file.
I hope this will help you!
I had this issue after copying my project on a flash drive with FAT filesystem. Suddenly there appeared a lot of "._" files. One of such files was in Settings.bundle.
I removed these files running
find . -name "._*" -exec rm -rf {} \;
Issue for me was that release Product Name was set twice under Build Settings:
ProductName
ProductName
instead of just ProductName. Interestingly, the newline caused issues for packaging, but nothing else.
In case some file has space in file name which will stop the rm process. use this command instead.
find . -name \._*.* | xargs -I{} rm -v {}
Same issues for me. No folder within a folder, no ._ files, no warnings or errors etc. Archives fine, but when I try to package with the organizer to adhoc it fails and says it is 9kb.
I've managed to fix my issue. Here's how I did it. I went to terminal, typed in
defaults write com.apple.finder AppleShowAllFiles TRUE
Then I checked all the folders with images in them. I found that some of my images had ? infront of the name even though it looks ok in the finder, it showed in the terminal.
So I just renamed it and was able to submit the app.
Note: Check the estimated size of the app in the organizer. If it's way off, it's messed up.
I had a file that contained ^ in the terminal that was the problem.
When looked at in Finder there was no visual clue that it was not labeled correctly. However when I tried to rename it, it failed.
I had the same issue in conjunction with a custom directory-icon. Those are stored as a hidden file (named Icon?) inside the affected folder.
It's probably safe to assume that there is a bunch of desktop/fs-features and conventions which can lead to packaging problems.
I had an issue with my icons or atleast that's what I think. I had to delete the icons and delete the references in my info.plist file. Then after that magically, a option while selecting to distribute the app in the Xcode Organizer came up saying Don't Re-Sign, and after I did that BOOM! It worked! Good Luck for Future Visitors!
I had the same problem in a cordova project, but I could not find any png files starting with '._'. With some luck I found out that the problem for me was that there was some font folder with an icon in the www (blue) folder (www folder is the folder containing the webapp and will be bundled when building). After removing (moved the fonts a level higher) the message 'packaging operation failed' was gone and exporting the archive for Ad Hoc distribution worked again.
In my case I had two issues:
1. the bundle ID was slightly different between the one in the Info.plist and the one used in the iTunesConnect
2. the distribution certificate used for archive creation was not the same that I used to resign the app before validation/submission.
In all cases XCode was opaque. But using Application Loader (you can run it from "XCode menu --> Developer tools") and providing it with the ipa file, the messages were clear enough to help me debugging the issue. So I'm going to radar this to apple: give the user clear messages in XCode exactly as you do with Application Loader! in the meantime, I recommend to use Application Loader when the "package" issue is not clear enough.
I solve it just copying the project folder into the desktop, which (i think) shortened the project file path.
my problem was that I entered a Product Name containing the tilde character: "~xxx~"
it was a temporary build I thought I would highlight it but in the end you cannot use any character in the product name.
Hope this helps.
I installed Xcode 4.3.1 to compile an app for iOS4.2 but I couldn't solve the "Packaging operation failed" problem (I've tried some of the solutions mention above). Later I installed XCode4.4.1 and I was able to compiled for iOS 4.2 without (almost any) problems
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?