Im able to submit my app through Xcode 6.3.2 perfectly fine. Validation and analyzing pass perfectly. Once it successfully submits to the app store though I get an email from Apple:
"Dear developer,
We have discovered one or more issues with your recent delivery for "App". To process your delivery, the following issues must be corrected:
Invalid Signature - Code object is not signed at all. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
Once these issues have been corrected, you can then redeliver the corrected binary."
I have tried redownloading the distribution cert, regenerating the distribution provisioning profile, added "--deep" to the code signing "Other Code Signing Flags." I even checked the bundle name etc, everthing is alpha numeric. I was able to submit fine on May 22nd, now on June 3rd everything breaks.
Doesnt make any sense, any help would be appreciated!
UPDATE & SOLUTION:
While I don't have a good explanation of why this suddenly has happened within the last week, I finally found a solution this morning.
I started with a new project and submitted to the app store with nothing but the identifier and correct version and build numbers, which processed fine. After that I started piecing in any assets that wasnt my own code until I got the "Invalid Binary" email. I narrowed it down to the Hockey App SDK (embedded framework) which was causing the issue and not even being used anymore so I removed it from the project (problem solved). The disturbing part is that nothing fails on my end during validation or submission and according to github this directory and content hasn't changed in a year, which leads me to believe something changed server side at Apple.
I did see a lot of posts via google saying that frameworks needed signed etc and when using Xcode 6 and iOS 8 it seems to be the standard which is why I assumed it might be something along these lines.
Im not sure how helpful this is as I was building for iOS and this article is in reference to Mac, but HockeyApp explains in order to distribute to the app store you need to sign the framework with your own identity here:
http://support.hockeyapp.net/kb/client-integration-ios-mac-os-x/hockeyapp-for-mac-os-x
If anyone has anymore technical notes on this or why this suddenly changed Id love to understand this better.
I've checked a variety of places and there seem to be several things that are now being rejected by iTunes Connect. The solution is typically to remove the offending resource from the Target -> Build Phases -> Copy Bundle Resources (as #azizus mentions). Unfortunately Apple doesn't tell you what file causes this issue with your builds so you have to go hunt for yourself. Here are some items that I've found that will do it:
Shell scripts (Look for .sh files, though they could have a different
extension)
Also, look out for files that are listed as executable, when they
shouldn't be. Those might be a good place to look for shell scripts
that you might have missed.
Frameworks (Framework bundles, even .a or .o files - you
don't need them as they will get compiled into the executable binary)
DocSets (I don't know why, but I found that the HockeyApp SDK
includes a DocSet bundle which was the cause in my experience)
Sometimes this might also happen due to some weird entitlements
issue. The entitlements you have may not match up with the App in the
provisioning portal.
Look out for invalid characters in your app name or file names (like
wildcard characters)
This is a pretty broad list, something I did to help in the search is build an archive and then show the contents of the .app in the archive using finder, sorting by file type. The strange thing is that these files actually exist in the _CodeSignature/CodeResources file.
My own theory on why this is happening is that Apple made some changes (or is making some changes) because of Extensions and WatchKit apps. Essentially, you are including a couple of binaries in the packaged IPA (phone app, extension, watch app). They probably want to make sure you're not including something else that could potentially be executed. Unfortunately, the error message is too vague (really it's incorrect) for most.
This took me 3 days to debug.
In the end it was due to an external framework I created (lets call it X) that I was importing via carthage. X had its own dependencies that it was importing via carthage as well. In order to link these frameworks it had a path in the build settings called Framework Search Paths set to the location of the frameworks. For some reason it was this flag in this framework that was causing the problem specified in the questions. I eventually imported X's dependencies with Git submodules so that I didn't have to set the Framework Search Paths flag. I the exported the framework and manually added it to my project I was submitting to the AppStore. Then it worked.
I can reproduce this when I 'create folder references' for my resources folder as opposed to 'create groups' when adding in.
I contacted HockeyApp and they suggested not to add the SDK to app bundle. So I navigated to Target -> Build Phases -> Copy Bundle Resources and removed HockeySDKResources.bundle from there. iTunes Connect accepted my binary.
In my case it was a info.plist duplicated that was not used. (it wasn't easy find out the problem). I removed almost all the files of my project until remove this one and.. it worked
Clearing the value for Code Sign Resource Rules Path in each target resolved the issue.
Related
I am trying to archive and distribute my ios app but out of nowhere it just stopped working. I have deployed my app many times and also had this problem before because xcode somehow creaded some bad xml lines in my project.pbxproj file, but eventually I edited the xml source code and it was ok (app archive and upload/distribution to AppStore). Now xcode is showing my new created archive in "Other items" sections and i cannot upload to AppStore. I opened the archive and I noticed that key elements are missing from the Info.plist file inside:
I looked into other archives (after upload/distribution) and it should look like this:
I tried about 10-11 links on google or stackoverflow, summerized very well here (see accepted answer): Xcode creating generic Xcode archive instead of iOS App Archive?
I tried everything and also cocoapods update to 1.10.0, cleanup cache, reinstall pods, no luck.
My app uses another framework project (developed also by me as described here: https://www.raywenderlich.com/5109-creating-a-framework-for-ios) but I haven't changed that one either. I set Skip install to YES to everything except my app's main TARGET and PROJECT Build settings and checked for private header files. I also distributed another app that uses that exact framework project and everything is ok there.
I checked the new changes compared to last commit and the only modifications (except the source code files) was the build and version number of my app.
In the end, I opened my archive and added the missing entries manually in with an xml editor inside the Info.plist, and restarted xcode (as described at the end of the accepted answer in the link above). After that I was able to distribute my app. The problem is that I do not want this approach because I do not know what is causing this and also what other problems it may cause. Does anyone have any other ideas? It seems a lot of people come across this issue, it has tens of possible causes and it makes me lose hours of work everytime it happends (about once every few months this issue just pops out of nowhere).
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
I have a lot of frameworks in my app. App works fine in adhoc/enterprise release. Only if I submit to the app store for testflight testing I get this error email from apple:
Dear developer,
We have discovered one or more issues with your recent delivery for "My app's name here". To process your delivery, the following
issues must be corrected:
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
Once these issues have been corrected, you can then redeliver the corrected binary.
Regards,
The App Store team
there is no specific information here. How can I debug it?
Got an answer from Apple Developer Technical Support which says it is a bug on Apple's side. this is the suggested workaround below which did not work for me:
To diagnose this issue, you should export the IPA you are sending to
the App Store from Xcode. Since IPAs are zip files, you can
decompress it by right clicking and saying Open With > Archive
Utility. You should find your main executable inside the unzipped
folder structure and run otool at the command line to see the library
list: otool -L
The list of paths you get should match what you find inside of your
IPA. All of your libraries should start with #rpath. A simple
comparison of everything in this list with the unzipped IPA folders
should reveal what is missing.
Once you know what is missing, go to your Xcode build phases setup.
There should be a build phase for either Copy Files or Embed
Frameworks that includes the missing library — you should just add the
library to the list. If you don’t see either of these build phases,
you can recreate it by adding a new Copy Files build phase, setting
the Destination to Frameworks, and adding the library to the list,
ensuring that Code Sign On Copy is checked.
If you don’t find anything missing in your main binary, make sure to
do the same search on any other binaries you may have, like for a
watchOS app or an iOS app extension.
If you find that all of the frameworks are in this build phase, please
take a look at the Embedded Binaries section of your app target’s
General page, and let me know if you see multiple levels of ../ next
to the binary that you found is missing.
Please let me know if it works for you!
I have encountered the same issue when uploading an app with watch support to the app store.
I was able to solve it with the hint from the first answer, using otool -L to analyze the binary from the ipa or xcarchive.
However, the problem was not with my frameworks (at #rpath) but with a swift lib. I noticed that libswiftWatchKit.dylib was missing in the frameworks folder.
The solution that worked for me was as simple as to set EMBEDDED_CONTENT_CONTAINS_SWIFT=YES in the build settings of the watch app (or the watch app extension, but not both). After that, all necessary swift libraries were correctly copied to the watch app path in the archive and upload to app store was working correctly.
Apparently, the watch app works and upload passes if you provide the necessary swift libraries only in the main app's folder.
After adding the custom Swift framework to my project I got this email after uploading the app to iTunes connect.
I got this email from iTunes store,
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
The fix is simple for this issue,
Step 1: Make sure your Custom framework is added to Embedded Binaries in General tab of your target.
Step 2: Under build settings,
Set Always Embed Swift Standard Libraries = Yes for your main project target.
And Set Always Embed Swift Standard Libraries = No for your custom framework target.
This solved my problem and I was able to upload binary to iTunes connect.
Ref
Tried all the above solutions and did not work for me.
I was experiencing this issue in Xcode 10.1 recently and all my frameworks were referenced correctly (did otool -L and everything lined up).
Seems there were some changes in the apple validation process, may be a bug, may not be on Apple's end, but all my prior builds uploaded and validated fine -- and I did not add any new frameworks since.
Upon uploading the binary to iTunesConnect, I'd see the following error:
Invalid Bundle - One or more dynamic libraries that are referenced by
your app are not present in the dylib search path.
Invalid Bundle - The app uses Swift, but one of the binaries could not
link to it because it wasn't found. Check that the app bundles
correctly embed Swift standard libraries using the "Always Embed Swift
Standard Libraries" build setting, and that each binary which uses
Swift has correct search paths to the embedded Swift standard
libraries using the "Runpath Search Paths" build setting.
MY SOLUTION:
After days of debugging, what worked for me was to disable 'Include bitcode for iOS content' upon uploading the archive from Xcode organizer. Seems that this option modifies the binary which caused the validator to fail.
Or you can disable bitcode in your Build Settings
My Problem:
I had the same error with embedded frameworks.
The App project has Custom Framework project
Inside the Custom Framework project is another Custom Framework project
The app built to the simulator and to devices with no problem but failed the Apple test, returning "Invalid Bundle".
I inspected the package just like Taha had been told to by Tech Support and everything was present and correct!
My Solution:
I restructured the project so that the two custom frameworks sit side by side and one is no longer embedded within the other.
This looks to be an Apple validation problem since everything works fine on devices and the simulator but the work around was straight forward.
In my case, in the build settings, this was fixed when I added the following to the build settings for the library:
DYLIB_INSTALL_NAME_BASE = #rpath
The clue was a linker warning: 'YourLibrary has an install name beginning with “/”, but it is not from the specified SDK'
Had same issue. This happened to me because one of my Framework target was added to main target in "Link Binary With Libraries" but was not added to "Target Dependencies" and "Embedded Binaries"
I also received a similar mail from Apple:
Dear Developer,
We identified one or more issues with a recent delivery for your app,
"********. Please correct the following issues, then
upload again.
ITMS-90562: Invalid Bundle - One or more dynamic libraries that are
referenced by your app are not present in the dylib search path.
Best regards,
The App Store Team
I used my own framework for my watch app. I solved this issue by changing the framework option to "Embed Without Signing" in the Extension Target. The default option was "Do Not Embed".
I had the same problem, it was due to one framework not being present in the Frameworks subfolder in the app bundle.
I fixed it by adding a Copy Fields build phase, and adding the missing .framework file there.
This error message is also addressed in Apple Technical Note TN2435
Embedding Frameworks In An App: https://developer.apple.com/library/archive/technotes/tn2435/_index.html
You can find the error message under the heading "Missing Framework Bundle" with troubleshooting steps.
We had the same problem, and even after going through all the steps (see "Missing Framework Bundle"), the only thing that worked was disabling Bitcode.
So I struggled on this for two days. What it turned out to be was I had UITests checked in Archive for the Build for the Scheme I was archiving.
After unchecking it from Archive, re-archiving it, validating it (although validating it before always passed), and "Upload to AppStore" I did not get the e-mail from Apple informing me of Invalid Swift Support. Instead I got the e-mail that it'd been processed and is good to go!
In my case, I've had to add a framework from Notification App Extension to the main target (embed & sign in the main target, do not embed in the extension) - even though there was no mention about it in otool -L output.
Funny thing that Iterable official doc says that the framework should be embedded & signed in the extension - which would lead to another upload problem because of nested bundles.
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?
Recently I created an application for iPad. I created the binary(something.zip) and uploaded that via Application Loader, but the result of uploading was 'Invalid Binary' always.
and I received this email from apple when my app was denied from them due to the issue 'Invalid Binary' :
"Invalid Signature - Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target."
I searched the web from around the world to solve this annoying problem, but I cannot see the good answer. Here's the data of my application's info.plist :
Localization native development region : English
Bundle Display name : $(PRODUCT_NAME)
Executable fike : $(EXECUTABLE_NAME)
CFBunldleIconFiles :Icon-Small.png(29x29), Icon.png(57x57), Icon-Small-50.png(50x50)
(all files were created as 72ppi, RGB, flattened, No transparency)
InfoDictionary version : 6.0
Bundle name : $(PRODUCT_NAME)
Bundle OS Type Code : APPL
Bundle creator OS Type Code : ????
Bundle Version : 1.0
LSRequiresiPhoneOS : Enabled
UIPrerenderedIcon : Enabled
UIApplicationExitsOnSuspend : Disabled
UIStatusBarHidden : Disabled**
and I created this application with these tools -
cocos2d Ver0.99.4-rc3 /
xcode Ver3.2.5 64-bit /
iOS SDK 4.2
I tried to solve this problem for 3 days, but I couldn't.
Is there anybody who can solve my application's problem, It's an emergency issue of our company.
Thanks everyone
It seems like there are a LOT of causes for receiving this cryptic and mostly unhelpful email. Even after verifying the use of distribution certificates, cleaning & rebuilding my project, and checking with codesign from the command line (and following instructions from the email), no errors showed up—-but I'd get the "invalid signature" email right after uploading. All the solutions seem anecdotal and obviously depend on what secret error is causing the problem. I've spent the last week pulling my hair out, trying to figure it out for my app—-and finally got it successfully submitted today—so let me share my story and see if it's relevant to your situation.
In my case, I seemed to have a complex cause of having my Entitlement.plist set with an incorrect variable along with the holdover of an old provisioning profile (from a previous Xcode version?) buried deep in the project.pbxproj component of my Xcode project file.
The "aps-environment" variable in my Entitlements.plist was set to "distribution" instead of "production" (I swear I read somewhere in the developer docs that it was supposed to be "distribution"!) But fixing that alone wasn't enough to get my app through. (I must have submitted 100 different combinations of app configurations trying different variables!) Starting with the helpful suggestions from this post on another forum, I dug through the distribution profile and found duplicate entries for some variables. The duplicates had empty quotation marks (i.e. nothing set for the variable) or strange variables or old provisioning profiles which seemed to be causing problems (somehow). Cleaning this up and removing the duplicate lines with bad variables worked in my case. YMMV. But carefully examining the project files ("show contents" on the Xcode project file in finder) seems like a good idea for diagnosing. Good luck!
This is a very annoying issue, I spend a lot of hours in trying to find a solution but at the end this was corrected for me by removing the Entitlements.plist (as I understood it is only needed when deploying for ad hoc), removing any duplicate field in the Info.plist, setting the target to "Distribution" with the correct configuration of the certificates and using the method of "Archive" then "Validate" and at last "Submmit" in XCode