I'm working on a multi-platform iOS and Mac app. When I try and Archive and Distribute to the App Store I run into this issue:
ERROR ITMS-90259: "Bad Bundle Executable. You must include a valid CFBundleExecutable key in your bundle's information property list file."
Verified that the Info.plist for the Mac target has a CFBundleExecutable
Tried Xcode 12 & 13
Tried using App Transporter
Used Xcode 13 RC and let that auto-generate the Info.plist
I've tried everything I could find online - there's not much - and I can't get the upload to succeed.
However, I was able to replicate the issue with an entirely empty project. No dependencies, no code, nothing. The project archives successfully, but the upload fails.
Any help would be appreciated. I've spent two days on this already.
An example project that fails: https://drive.google.com/file/d/1qUN5lHEWNyNHQV54fYPXMeRsuO-cpHqW/view?usp=sharing
We had two issues causing this, making it fail when uploading a Mac build to iTunes. The first issue, we had included a package (from Steam), that had its own plist and post build script.
com.rlabrecque.steamworks.net/Editor/RedistCopy.cs - build script
com.rlabrecque.steamworks.net/Plugins/steam_api.bundle.meta - folder with plugin and plist
We renamed the post build script and removed the plugin folder, not 100% sure if the renaming was needed.
Then, we had this in our own post build script that was causing issues, so we removed it too.
rootDict.SetString("CFBundleExecutable", "${EXECUTABLE_NAME}");
Then it worked! Also worth noting that we believe the CFBundleExecutable didnt actually end up matching the file name e.g. the file produced was a.pkg and the plist says:
<key>CFBundleExecutable</key>
<string>b</string>
But seems iTunes was ok with that. We use Unity and it seems in the pList the string was set to the "Product Name" (Edit > Project Settings > Player, at the top, "Product Name").
We also didnt need to use Transporter to upload.
Related
After successful Archive, while exporting the Archive to "Save for App Store Deployment", I got the following error:
"Symbol Tool Failed".
During the Export sequence, I have observed, "Binary and Entitlements" section, has two entries.
1) The app store targetAppName (5 Entitlements). with valid Provisioning Profiles.
2) One of the build files FTALDeviceDetailsViewController.o (o Entitlement) with Provisioning Profiles (none)
I bet the second entry here is what is causing the error. Here is the error log:
Any one know how to remove the second entry?
I found another interesting information, regarding this issue:
Unser Archive folder
ActiveLife\ 11-12-14\,\ 3.56\ AM.xcarchive/Products/Applications/ActiveLife.app/
I found following 3 files those are generated in response to second Entitlement file:
FTALDeviceDetailsViewController.d
FTALDeviceDetailsViewController.dia
FTALDeviceDetailsViewController.o
I have manually deleted these 3 files, and now I am able to generate .ipa file.
Now still mystery to me is; why are these files generated and how to fix the root of the problem?
I experienced the same "Symbols Tool Failed" issue yesterday. With the following more detailed error:
Archive upload failed due to the issues listed below.
Unable to validate your application.
The path '/var/folders/c6/wfv094t921j7q1bzhht5wtdnhvjv1/T/XcodeDistPipeline.blK/Packages/XXXXXX.ipa' does not contain a file.
The cause of the problem was that a third party library (*.a file) had accidentally been included in the "Copy Bundle Resources" "Build Phase". The give-away that this was the problem was that this *.a library appeared in the list of "Binary and Entitlements" screen when submitting the upload:
Ultimately the third party source code had been added to our workspace as a "Folder Reference" and someone had checked the 'target membership' for that folder. This resulted in the the third parties libary folder (which contained the *.a) being included in the "Copy Bundle Resources". Simply unchecking the 'target membership' box for the folder fixed the issue.
The reason for the issue is, some how FTALDeviceDetailsViewController.m file is ended up Copy Bundle Resources causing this is be treated as separate target.
When I delete the file from the Copy Bundle Resource, every thing worked as expected.
Now the mystery questions to me, what are .d .dia generated? This is up for further study.
Unchecking "Upload your app's symbols to receive symbolicated reports from Apple" option fixes the "Symbol tools failed" error when you Archive the app in Organiser window of Xcode.
I faced this too, and trying to find something wrong with the copy bundle resources, as the previous answers, I found a folder being copied, removing it solved the problem.
Basically some framework has been added to Copy Bundle Resources. Remove it to resolve the issue!
Could also be that there is a framework unnecessarily added in 'Embed Frameworks' in Xcode Build Phases
"Symbols Tool Failed" error can also be caused by this.
Xcode 13.1 - Check BuildTarget -> General -> Frameworks and Libraries. If something is marked as Embed And Sign it may need to be changed to Do Not Embed.
I've been reading countless other posts and trying numerous fixes, but nothing has worked for my problem. I'll preface this by saying that I haven't used Xcode on this Macbook in some 2-3 months. This is the only project (out of the 4 or so I've tried) that has this problem. The first thing I did after opening Xcode was I changed the name of the project as well as a .h and .m file. I did all of this through Xcode, not Finder.
Nothing is appearing in the Navigator in red text which would indicate that it can't be found. Here is what I've already tried (many times).
Close/Open Xcode.
Clean both the project and build folder.
Delete Derived Data folder.
Ran a Disk Utility to repair permissions.
Restarted the computer.
Tried different combinations of Code Signing.
Delete App from device.
Searched through project for any duplicate file names.
Here is the warning verbatim:
Warning: Multiple build commands for output file /Users/jinser/Library/Developer/Xcode/DerivedData/Landmarks-bgnzcomxftpffiezmwocaqdydrlj/Build/Products/Debug-iphoneos/Landmarks.app/Landmarks
and here is the error:
GenerateDSYMFile /Users/jinser/Library/Developer/Xcode/DerivedData/Landmarks-bgnzcomxftpffiezmwocaqdydrlj/Build/Products/Debug-iphoneos/Landmarks.app.dSYM /Users/jinser/Library/Developer/Xcode/DerivedData/Landmarks-bgnzcomxftpffiezmwocaqdydrlj/Build/Products/Debug-iphoneos/Landmarks.app/Landmarks
cd "/Users/jinser/Desktop/Kevin/Cocos2D Projects/ARSpaceships"
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/usr/bin/dsymutil /Users/jinser/Library/Developer/Xcode/DerivedData/Landmarks-bgnzcomxftpffiezmwocaqdydrlj/Build/Products/Debug-iphoneos/Landmarks.app/Landmarks -o /Users/jinser/Library/Developer/Xcode/DerivedData/Landmarks-bgnzcomxftpffiezmwocaqdydrlj/Build/Products/Debug-iphoneos/Landmarks.app.dSYM
error: unable to open executable ''
This is Xcode 4.2 on Mac 10.6.8. Please, any advice would be appreciated. I am losing my mind.
Thanks.
So to whoever runs into this problem and all of the other solutions out there do not work for you, make sure you don't have a project folder that shares the same name as the project. For instance, my project is called Landmarks and I had a folder inside the resources also called Landmarks. Once I renamed the folder, all was well.
Not my answer, but LargeGlasses provided the real answer (for me) in a comment, I've formulated it as an answer in its own right because I can't Up Vote the comment.
any two files within your project that have the same name will cause this warning.
In my case, I had an icon with the same name in different subfolders, one was used by the App and the other was part of my help resource located in a different folder. The solution is to just rename one of the two.
All credit and my thanks for this answer to LargeGlasses.
I am uploading ios build on testflight till now. But I am getting the following error on uploading any build (I also tried uploading the previous build again which I already uploaded on it).
Invalid IPA: Couldn't find executable specified in Info.plist - check the value of your CFBundleExecutable key.
I need to upload the build. Can someone suggest me a site other than testflight where I may upload the ios build or ipa file?
The other site you can use is http://diawi.com, i use it on my project now, very helpfull.
We had a problem with CFBundleExecutable ${EXECUTABLE_NAME}. Our iOS app was for example called OurAppName.
Ran fine in Simulator but when archived and deployed via organizer said CFBundleExecutable was not an executable file.
We checked the plist and the value for CFBundleExecutable was 'ourappname'. we unzipped the ipa > app folder (see how below) and there was a fie called ourappname but it was smaller than expected and not a exe (USE:ls -l should have x at end of -rwxr-xr-x ).
Bug was caused by a text file called 'ourappname' and when archive was built it took that as the exe and not OurAppName. Answer was to rename and or delete the file with same name as our exe. Do full clean build. and recheck final ipa.
To see contents of OurAppName.ipa :
Rename to OurAppName_ipa.zip (ignore warnings):
DOUBLE CLICK on OurAppName_ipa.zip to open (creates Payload folder containing OurAppName.app):
rename OurAppName.app to OurAppName_app (ignore warnings will change app bundle to folder).
Open OurAppName_app folder look for ...info.plist for app.
Check CFBundleExecutable is pointing to OurAppName.
Find OurAppName in folder do ls -l make sure it executable (USE:ls -l should have x at end of -rwxr-xr-x).
TIP FOR TEST FLIGHT:
If testflight download fails after 80% with UNABLE TO DOWNLOAD then drag the archive you built to a iOS device using Organizer.
Click on Device > applications and + at the bottom (i think dragging the ipa to the device in the organizer installs it as well).
in your info.plist file open as source code form and check CFBundleExecutable key is there or not and make sure it is written as
<key>CFBundleExecutable</key>
<string>${EXECUTABLE_NAME}</string>
I tried to update an iphone app, which lies in an other "itunes connect" profile. I used "application loader" and everything is fine until I try to upload the zip file
I get this strange message and cant figure out whats going wrong
"The CodeResources file must be a symbolic link to _CodeSignature/CodeResources"
I opened the bundle and the folder _CodeSignature is there.
I compiled the app with my distribution profile (no problems)
How are you zipping it? I'm betting that FooApp.app/CodeResources is a file, not a symlink.
If you're using command-line "zip", you need to use zip -y -r to preserve the symlink.
Had the same issue with XCode 3.2.5 (new submission interface), and all it took was to:
delete the build folder
clean, and then
build and archive again.
I had the same issue. But then I noticed that I was building in release mode to the simulator, and not a device. When I targeted a device, I got the proper application file, which I then zipped with the iTunes Artwork and submitted without issue.
I had the same issue here but I "fixed" it after I changed the "Deployment Target" from 2.0 to 3.0 in the target I was building and removed the "Architectures" to only armv6 (before I had both armv6 and armv7). Finally I had to put 'No' to 'Build Active Architecture Only'.
I haven't figured out why I keep getting this error for every binary I create. I've followed all the standard procedures (double-checking my project settings, deleting build folders, cleaning all targets, removing and reinstalling certificates and provisioning profiles, creating and installing new certificates and provisioning profiles, repairing disk permissions, etc) but none of them seem to solve the problem.
I think the problem is that my XCode installation is unable to create symbolic links. I might reinstall it (or even OS X) to see if that fixes the issue permanently.
But in the mean time, this works for me. I use terminal to navigate into the binary and run the following commands
rm CodeResources
ln -s _CodeSignature/CodeResources CodeResources
This deletes the invalid CodeResources file and replaces it with the required symbolic link to _CodeSignature/CodeResources.
I just ran across this issue. It turned out, I had two info.plist files in my resources folder (one for the iPhone version and another for the iPad version). Once I took care of that, the issue went away.
Try this on the command line:
cd (to where your project is)
ln -s _CodeSignature/CodeResources CodeResources
I've just had the same problem. Turns out the project file project.pbxproj in Project.xcodeproj had been corrupted while uploading to an SVN server.
My solution was simply to revert to an older revision, which worked fine.
You have to:
1. Enter the AppName.app folder
2. Create a file named CodeResources
3. Open the file with a plain text editor
4. Type in _CodeSignature/CodeResources (The path where the actual CodeResources file is.)
{The app will now know where the CodeResources file is, and will have an account for all the files in the .app folder.}
I can install an app on my development iPhone compiled with "Debug" configuration using my Ad Hoc provisioning and everything works OK.
But when I build it using "Release" configuration, iTunes says:
The application XXX was not installed on the iPhone "YYYY" because its resources have been modified.
I've never seen this message before. Does anybody know what it means?
Thanks!
Antonio
We had the same problem during our first Beta. Someone on Windows dug in the xxx.app folder then Explorer created a Thumbs.db file inside and, boom, he got the message "The application XXX was not installed on the iPhone "YYYY" because its resources have been modified." when he tried to install.
He had to remove the app from iTunes, deleted all the Thumbs.db from xxx.app and then it worked.
We finally got rid of the problem. We were trying to include an image for iTunes after creating the build, but when we used this method (http://iosdevelopertips.com/xcode/itunes-icon-for-ad-hoc-distributions.html) everything went smoothly.
Just in case it helps someone: In my case, I copied the .app to a network drive, then to my Win7 computer before dragging into iTunes - then it did not work. When I zipped the .app first before copying, and then unzipped it on the other end - it worked. Of course, I have no real idea why....
Your debug configuration and your release configuration have some important differences, and release is a lot closer to what ad-hoc should look like. So you first need to duplicate the release configuration and make and call your copy "Ad-Hoc", and make sure you use your ad-hoc provisioning profile with it. Then you need to create a new entitlements file. The new version of Xcode has a cool feature where you can build and archive your app into an ipa file that includes your provisioning profile.
How to do all of this is explained here: http://www.tuaw.com/2010/05/23/devsugar-a-better-way-to-share-ad-hoc-builds/
In those instructions, when it tells you to make the entitlements plist file, it says to uncheck get-task-allow in the plist file. When I created the entitlements file, there wasn't a get-task-allow row at all, so I created one, set the type to boolean, and left it unchecked. It worked great for me.
The best solution to avoid wierdness like this is to create an IPA file. A good step-by-step guide to creating an IPA target in XCode is here:
http://idotcomllc.wordpress.com/2009/05/26/how-to-build-a-ipa-file-from-xcode/
It starts out with an introductory project so search for "Aggregate" to find the point where it starts telling you how to create a new IPA target for build.
I directly upload the app to a server where the windows can also visit. Then compress it in Windows.
I had it, did a clean build and never saw it again.
Incomplete ipa/zip archives (received at the installation end) were the cause for us.
I had this problem using a run script to cp -R the .app file to the Payload folder, for some reason when the script copied the file it modified it somehow, if I used finder and manually copied the .app file into the payload folder and manually zipped the .ipa file it worked fine. I tested it several times using codesign -v to verify the .app file. it always through the error after a build and the run script. but no error when I would copy the file manually.
For me the issue was the .Double files being added to every directory on a shared network drive. We are primarily a Windows environment, and the Mac was saving .Double file on the drive, in every directory.
Literally, to fix the issue referenced above, I simply deleted the .Double files in every directory (of the app being copied to iTunes) and it fixed it.
Hope this helps someone!
I was tasked to test some apps and for some reason was the only one on my team getting this this error. I am working on an XP. All the apps we are testing use the same provisioning file yet some would sync while others would not. Not sure what fixed it but I did go into my *My Music\iTunes\iTunes Media\Mobile Applications* folder, deleted the existing .ipa file for the app I was trying to sync and it seemed to sync fine after. It might not be the answer to your problem but give it a try.
If you work with asstes on a Mac, or have versioned content, I had the same problem with .DS_Store files and hidden .git folders. Once deleted from assets, problem gone. It might be an issue with hidden files.