Today I cannot submit the binary to App Store, with the error "Invalid binary, the binary is missing architectures[arm64]".
But in "build settings"->"architectures", it does have arm64.
The previous version can be submitted successfully, and I haven't modified project settings.
As TimT stated in this thread: https://devforums.apple.com/thread/244448, It is apparently a bug.
However, it's still not resolved...
Not enough reputation to post image, please search "TimT" for his reply.
UPDATE:
It has been fixed. "Yes, there was a fix recently applied to the server. Everyone should be able to submit 32-bit apps again." - by TimT in the same thread. I tried again and everything is fine now.
After a long period of trying and trying to fix this issue, I haven't got any solution, but to install the older version of Xcode 5.0.2 and submit the binary with that one.
Cheers :)
I had the same error in the morning and apparently it was one of the 3rd party library/framework that it was missing architectures[arm64].
Seems that app must support arm64 now.
In my situation, I used some third party Library which doesn't support arm64.
I deleted the Libraries, and it's OK now.
The Architectures setting looks like below:
Related
I've had an iOS project in fairly stable condition up until Xcode 8's public release. After a bit of confusion with the Migrator, I finally convinced the compiler that I did not want to go Swift 3 yet, and that my code was indeed valid Swift 2.3. Not sure if this at all relates to what the Organizer does in validating my long-awaited archive with some long-overdue fixes for iOS 10, but we'll see...
Anyway, I got Xcode to archive my latest build (which runs fine on my iPhone 5s by the way). I tell Organizer to "Validate..." in preparation for an upload to iTunes Connect. After a good deal of doing its thing, it finally spits this at me:
Been at this for three days now. Application Loader gives me something similar, but not much more helpful:
Following the suggestions in this answer, I find that every single one of my compiled assets read as sRGB, not 16-bit, or P3. Aside: When does an API analysis file get "too large"? I mean, sure I use Apple's APIs a lot, but I can't be alone in that. That's what they're for, right?
I've tried (almost) everything I can think of. I've redone my code signing a dozen different ways, read and recombobulated the build settings wherever I thought could be relevant, and tried every combination of bitcode and symbol inclusion available to me. Just about everything I could come up with short of migrating to Swift 3! Could that really be my solution? It's a rather big jump, and with the time I have, I'd prefer to get this working build out to my users before I'm slammed too hard to shore up the updated codebase.
I can't seem to find anything on "ITunesSoftwareServiceAuthenticationErrorDomain", or this mysterious "error 434". The only reference I've found so far leads to a dead StackOverflow question. Really wish the author hadn't removed it... Wonder if he found his answer?
So my question is as follows: What am I doing wrong to get these errors, and how can I fix them? I'd rather not have to upload without symbols or bitcode, so if that's the workaround, I'd like to know why, so I'm not limiting myself for something dumb.
Cheers!
I had the same problem with Xcode 8.2 while submitting my application:
ITunesSoftwareServiceAuthenticationErrorDomain error 434.
Solution: I switched to different network and it worked for me.
Bump the build number and validate again.
Had the exact same problem. I tried upgrading to Sierra which seemed to update bits of Xcode etc. The new error message was formatted differently, so I could not see the "434"
(With 1 success in 15 attempts (I had to tweak a version number in a string in the app, so didn't choose to upload after that brief moment of joy), i just uploaded the archive anyway, and after 2 hours of processing, it was accepted. I will update when my new app version is live to verify this error can be safely ignored, at least in some cases (e.g. I checked all my graphics' color profiles, etc.).
Do the below steps :-
1. Analyze the project. (From Product Menu)
2. Click on Archive. (From Product Menu)
3. Select the development team for provisioning.
4. From summary window unselect "Include bitcode" and click on Validate button.
Now, It will working fine.
I solved it by uploading my app through Application Loader.
Archive app Export ipa iOS Deployment
Xcode-> open developer tool -> Application loader
I had the same problem while I was trying to submit the app to client's iTunesConnect account. I've signed in with new apple id, downloaded the certificates and provisionin profiles but still got this error:
(ITunesSoftwareServiceAuthenticationErrorDomain error 434.)
How to fix this error?
Try to remove Provisioning Profiles files at ~/Library/MobileDevice/Provisioning Profiles/
Make new Build and Archive the app. Xcode will create new Provisioning Profiles and submit the app to iTunesConnect.
Just to share this.
Quit xcode and re-login as suggested by members does not work for me. I solved it by using "Application Loader"
Steps: 1) change the version and build in your App 2) archive again for new file submission and export file to desktop 3) goto top menu: Open Developer Tool > Application Loader (if you don't have this , search, download and install this plug init) 4) upload the new version archived file. Done
You will find them in iTune Connect. From here process to My Apps > choose the rejected app > change the version and click on the new uploaded archive file, file will be processing..
5) time to resubmit :) cheers
Clicked Valid until it succeeded, 3rd time.
Since there seem to be many solutions to this problem, it may just be an issue not related to anything developers have control over and the "solutions" seem to be "solutions" because after some action was taken, it succeeded. The action I took was the non-action... and it was successful.
Hope this helps, as this is a stressful problem to have when you cannot upload your app and muddling around in Xcode to fix it you might break something else.
I fixed it by upload using Application Loader.
Besides, after upload the app i receive the warning about Privacy - Photo Library Usage Description and Privacy - Camera Usage Description, so that, please make sure you have them in your info
Hope it help!
I had the same problem. In my case it was caused by following. I had a lot of png-files in assets.xcassets and some of them had AdobeRGB Color profile. I changed the profiles to sRGB and xcode validated the archive with no error.
Frankly speaking, when I changed the profiles some other strange errors occured, but they dissapeared by themselves when I tried to re-validate the acrchive several hours later (I did nothing just waited).
If this occurred randomly, try to delete that archive and make sure you have "Generic iOS Device" selected as target when you run Product > Archive again. This solved it for me.
I Got the same issues when i try first time.Next time it Validated successfully. Please check network once before trying second time.
1.Cmd+Shift+K
2.Close Xcode
3.Open Xcode
4.Cmd+B
5.Product->Archive
Just Clear all file in Path ~/Library/MobileDevice/Provisioning Profiles
Go to Xcode Select Provisioning profile again and then it auto-generate again.
So It will be working fine.
In my case it was the following:
my account had been logged out and I had to enter the password again
Xcode v8.0 had to be updated to 9.x to be able to publish to the App Store (as of July 2018)
I fixed this problem by updating Xcode from 8.2 to 9.
Apparently there was a compatibility issue with an SDK used internally. Xcode was not helping with it's error message. I discovered it by using the Application Loader to upload the archive. Application Loader's error message made some sense.
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
This is quite linked to this question but it doesn't have any solution.
On uploading a build to iTunes Connect, I received the following message:
We have discovered one or more issues with your recent delivery for
"Hurdal IL". Your delivery was successful, but you may wish to correct
the following issues in your next delivery:
Unexpected Machine Code - Your upload contains both bitcode and native
machine code. When you provide bitcode, it's not necessary to include
machine code as well. To reduce the size of your upload, use Xcode 7.3
or later, or any other toolchain that removes machine code.
After you’ve corrected the issues, you can use Xcode or Application
Loader to upload a new binary to iTunes Connect.
What is the resolution?
Will the app approval be affected if this build is uploaded ?
I just talked with the Apple Developer Support, the official one. They don't said it clearly, but yes it's a bug.
So, it's confirmed that there's some malfunctioning in their side.
UPDATE: It won't affect the Apps in Production neither Testing!
I have same issue but in my case I set in Xcode Build Setting Enable Bitcode to NO. After this error I change it to YES and it works
No, its not effect app approval and the binary seems to be accepted by the iTunes store.
I just uploaded a binary recently (like 20m ago). They did sent me a note just like you. After that, I just re-built it again, only update the build version (1943) and upload. Now it seems like there's nothing happened anymore. And the previous build (1942) has completed processing without failure. So I doubt it's a bug from Apple.
Just ignore it. You may want to build another binary to fix the warning tho.
I've the same problem, I send my application to review with that issue.
Result:
My app pass the review and already in publication. No problem... I think it's a issue from iTunes Connect.
The app which I published with this waring was just approved by Apple. So to answer my question, this won't affect the app approval.
Also, I am accepting #Helen Wood's answer as she was right that this is an apple bug.
Just got this as well, it's a bug. I uploaded the near exact same binary as I did a couple of days ago which went through fine (only change was to the version and build number). Developer support confirmed this.
If you do get the e-mail, don't worry about it. Your binary will still process and you'll still be able to submit it to the app store.
I regenerate all of the certificates, update the version number of the application, but the problem persists.
Follow the below steps.
Go to My Apps Page.
Remove the Build. Then Save It.
Re Add your Build. then Save It.
Now try to Submit It must work.
I do not know what the reasons are, how to do?Thanks!
In Prerelease section the status of your build should not be "Processing". Just wait some time (10-20 min) after build upload, and it will be ready to use.
I got this problem in Chrome browser. Switching to Safari worked like a charm for me.
I had the same issue. To solve it, the unique thing I had to do was "Clear History and Website Data..." within Safari (version 8.0.3 in my case).
Please, keep in mind that I speak from my experience and that worked for me. I cannot guarantee this as a general rule to fix the problem. Nevertheless I can assure that I tried several alternatives explained here and the one I just described was the solution for me.
It seems to happen if you are too quick between the build finishing "processing" and it being attached to a version and the version being submitted. I just published two apps in quick succession and the second submission had this problem while the first was fine. The only difference - speed of clicking the submit button.
Logging out and back in made no difference - the "problem" is with the submission.
I removed the just uploaded build from the version and then re-attached it, proceeding as normal to submit the release to Apple with exactly the same build and submission artifacts as before, except this one "saved" and went into the review queue.
I got the strange but working solution.
I had tried submitting the app using Safari browser but it didn't work and showed same error. Submitting the App using Chrome worked for me in the first go...
I'm stuck on this too; and have had to work around several other iTunes Connect bugs just to get to this point. What were Apple thinking by releasing this iTunes Connect version? It's completely ridden with bugs!
Sorry, I've tried everything I can: Filing a support case with Apple appears to be the only 'solution' at this point.
Make sure the Version you have on iTunes Connect and the version you gave in the Info settings in xCode are exactly the same.
I had 1.0.0 in iTunes Connect and 1.0 in xCode and it kept giving me this error message. I changed it to 1.0.0 in xCode and it worked perfectly.
I had the same problem. just sign out and sign in again. it should work.
I had the following issue when submitting a build which was uploaded couple of days ago for test flight testing. Then figured out that the provisioning profile of the application has expired so I renewed the prov profile and downloaded and re-archived the application (by increasing only the build number ) and uploaded and submitted it. And it worked like a charm.
I guess apple need to be specific of these error scenarios
In my case we contacted apple and they said the issue is that it seems that we don’t have a correct certificate generated on developer.apple.com. We use Xcode automatic signing management. I refreshed correct profiles, rebuilt and I could submit successfully.
I had the same problem. Tried from different system and it got saved
I am getting this warning when submitting an iOS binary to Apple:
"This app references non-public selectors in Payload/x.app/x: base64EncodedString, dataFromBase64String"
I do not get a warning during the build in xCode.
I am using xCode 5.0.2 and Phonegap 3.3.
I don't know if Apple will reject the binary for this reason, but I don't want to wait to find out. Also, I like to resolve all warning errors the "right" way.
I have found other people having similar issues (different third party libraries) and it seems their solution is to get updated third party libraries. I am already using the latest phonegap and there has been plenty of time for this to have been resolved, so I suspect this problem is unique to something I am doing.
I have greped by project and the two symbols are referenced here:
Cordova/NSData+Base64.h:+ (NSData*)dataFromBase64String:(NSString*)aString;
Cordova/NSData+Base64.h:- (NSString*)base64EncodedString;
My two questions are:
1) Will Apple reject this binary because of this warning?
2) How can I resolve this warning message the "right" way?
I am answering my own question....
Upon further investigation we determined the problem was that we only
included libCordova.a in the project. This worked okay when testing
in simulator and on device, but gave the above warning on submission
to the appstore.
The solution to avoid the warning on submission was to copy all the
source code for libCordova.a into /platform/ios. That source code
originated from the "cordova create" command.