App submission failed - 1+ corrupted binaries/non-public API usage and no additional details

Question

I’ve been submitting my app to the App Store for test flight and after build 11, I’ve been getting failures via email from Apple:

Non-public API usage: The app contains one or more corrupted binaries. Rebuild the app and resubmit

I get no additional details from them. No method names or classes or anything.

I’ve submitted build 15, for example, which is literally an exact copy of build 11 (which went through!) with a version number bump and build 15 failed.

I believe this is an Apple error though I have no way to prove it other than the paragraph above. Builds 1-11 worked fine and were able to be uploaded and distributed.

I’m using Xcode 9.1 and 9.2, both give the same error.

I’ve also contacted Apple via DTS and they said they can’t help me.

What do I do now?

Floating

It says rejected for private API's.. – Ramburt

I understand that, I just don’t know what private api it suddenly thinks I’m using. It gives me no indication about what or where... – Floating

I'm seeing the same thing (in a similar situation; minor changes since the last accepted build, but now being rejected). My current theory is that a new API has been marked as "private", and I have a method with the same name. Concurrently, there's a bug in their naughty-API listing code, which is spitting out "corrupted binary" malarkey. Working theory. Currently trying to submit a bare-bones app and gradually adding stuff to it to get it to fail. – Heideheidegger

That’s my theory too. I just finished my app and went to submit a GM build to my testers and started getting this. It’s annoying – Floating

Testing a theory: are you using CommonCrypto? In a Framework wrapper? – Heideheidegger

Same problem here. – Barbuto

I’m not using common crypto – Floating

same issue having not ablut to submit new build version get same invalide mail from apple – Sunbreak

We have the same problem since friday. We also tried to upload an old version of our app which has been previously approved, but got rejected with the same message. – Jotter

That's great news! I'm not alone. It does seem to be something Apple rolled out Thursday or early Friday morning. – Floating

@Jotter I just got off the phone with Apple Developer support. They've forwarded my case onto some internal team to take a look at (they did this Friday and it's 8:15a in California) so hopefully I hear back this week; will keep this ticket updated – Floating

Any update on this? I'm seeing the same issue here. Build I submitted is barely changed from a version I got approved a week ago. Less than 10 lines different. – Tenotomy

see my answer below. maybe that solves it for you too – Barbuto

Not using Cocoapods in my project. Thanks for the info though. – Tenotomy

i had fix that issue by update swift class and remove unused class or pods. you need to check the pods if there any pod use old then update it and remove if not use in project, – Sunbreak

how ever you are not using cocoapods then check in your project use swift class that need to be update to swift 4 support – Sunbreak

Sometimes, it makes sense to submit the application bundle via Application Loader.app, as it might show more detailed error description then Xcode's Organizer does. – Compliancy

Also experiencing this issue. Any updates? – Fattal

Please see my comment here. It might be helpful. Thank you! – Jost

Answer 1

I had this exact problem. I was using CommonCrypto as a 'fake' framework. I removed that, and switched to the method described by the accepted answer in this thread, and iTunesConnect accepted my build.

Getting a Swift 4 conversion warning by XCode or having "CommonCryptoModule" showing up in cmd output when using pod update seems to be a strong indicator whether you are affected by this issue or not.

Heideheidegger

I had some internal libraries installed through CocoaPods that were using a 'fake' framework installed as a common dependency (also through CocoaPods). I changed to having them reference their own modulemaps in the pod_target_xcconfig setting in their Podspecs, and iTunes Connect accepted the build. – Estivate

Thank you Ben, you really saved my day! ) – Doall

Which method did you use? I'm currently using this framework: github.com/soffes/CommonCrypto which appears to use the module maps methods described in the answers. – Tenotomy

I changed my internal libraries to reference the CommonCrypto module maps inside themselves. I suspect that including a framework called “CommonCrypto” is what was triggering a non-public API error? So maybe that framework is causing problems too? – Estivate

I was also using soffes/CommonCrypto with Carthage. Removed both and added CommonCrypto using accepted answer. Step 5 was not needed like a commenter said. Finally succeeded submitting to TestFlight! – Bovid

Indeed CommonCryptoModule turned out to be the culprit in our particular situation as well. Following along with the accepted answer in the shared thread did the trick. – Turnbull

Answer 2

Our projects that didn't have bitcode enabled started failing on Friday 2018-01-26. Setting Enable Bitcode to Yes in the Build Settings of those projects solved the issue.

Stocktaking

What if you need to disable bitcode in your project though? – Floating

What if you need bitcode disabled in your project though? – Floating

@ZackShapiro this is the same issue we are facing. Bitcode enabled is not required by Apple on iOS. – Rieth

Answer 3

After a LOT of investigations on this part we finally found the problem for this issue: It seems like Apple gives this error for applications that suport both 32 and 64 bits.

Apple gave this reminder for Mac Appstore, but it seems that iOS applications are affected as well.

So a solution for this is to support bitcode OR to drop support for 32 bit devices by removing support for ARMV7 and ARMV7S or bellow from Valid Architectures from build settings. This will mean your application will work only on iPhone 5S and above. I hope this helps someone. Thank you!

Jost

Also no support for iPad 4th gen and below. No iPad mini either! – Rieth

Found that CommonCrypto was the root problem. It seems like they use some un-documented API usage. If you remove this from your project, the submission will work fine. – Jost

Answer 4

Had the same problem since Saturday. Took long trial and error in our case, turning on Bitcode didn't work. The following part of my podfile was the reason:

post_install do |installer| 
  puts("Set deployment target")
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '10.3'
    end
  end
end

After I removed this one it processed without an error (still with Bitcode turned off). It really puzzles me though why setting the deployment target suddenly causes a rejection.

Barbuto

This fixed our app store reject issue as well. Thanks for sharing this information! – Uptrend

Answer 5

Seems like the problem was fixed in the iTunes Connect backend. After build 45 we got through yesterday evening. Tried to find out what fixed the problem from all those changes - seems to go through with the inital build as well now.

So three days I could have spent outside...

Serf

Amazing! Gonna try to resubmit today. Thanks for the update – Floating

I just tried to re-submit and got the same failure error: Non-public API usage: The app contains one or more corrupted binaries. Rebuild the app and resubmit. – Floating

@Zack Shapiro do you use cocoapods? – Rieth

Got that error again yesterday afternoon. Really strange. It's gone now after we've enabled bitcode (which was disabled) but not sure if it's temporarily working now and will come back again or if this really fixed the issue – Serf

Answer 6

Recently from 26th Jan 2018 Without any notice or announcement apple did some change related swift old code does not longer work with submission of application at app-store. I did not use CommonCrypto in my project at all

I am also face that issue and i do lots of search and posting a question at apple forums and various platform about Non-public API usage: The app contains one or more corrupted binaries. Rebuild the app and resubmit

After get to know that for that kind of Invalid Binary rejection have not single solution. I mention some possible solution that works for some user recently.

1. Update your cocoa-pods if you are use since long and that contain some swift framework or class since swift 2.0 then just update your cocoa-pods with swift 4 support and target 10.0 that error goes away.
2. One of user i have talk he enable bitcode on from Build setting and that issue solve for him.
3. Some of user remove unused code, class and framework that directly use in code without cocoa-pods issue solve for them.
4. For me i get warning in left panel like following image

• Once i conversion to swift4 i get following warning:

The use of Swift 3 @objc inference in Swift 4 mode is deprecated. Please address deprecated @objc inference warnings, test your code with “Use of deprecated Swift 3 @objc inference” logging enabled, and then disable inference by changing the "Swift 3 @objc Inference" build setting to "Default" for the "appname" target.

• For fix this warning i use that answer: The use of Swift 3 @objc inference in Swift 4 mode is deprecated?

• After that i need to add @objc in swift3 class public method that i used in my objective-c class using bridge

• I also check other warning in left side panel there is some other dependency warning of application target might be that also helpfup for other.

Hope this answer can useful for some of user who does not find the answer yet and that might be helpful.

Sunbreak

Answer 7

I was able to resolve it for myself, here's what I did:

• Bitcode is disabled in my project and stays disabled
• I removed a 3 pods, one being CommonCrypto, which I'd forgotten I had (the other 2 were QRCode and SwiftyJSON)
• I removed their Linker Flags as well in Build Settings

I hope that helps!

Floating

Answer 8

I found the solution by my self after uploading the 9th build.

1. I have used some swift class in the objective-c source code that I used by a bridge. While you build the project you can see left panel warning of project related and there is one line said update for swift 4.
2. After converting swift 4 I get some more warning like use @objc to use swift 3 to latest swift 4 code.

3. You can check how to use @objc at swift class check this link: The use of Swift 3 @objc inference in Swift 4 mode is deprecated?

4. Then I have change unused profiles.

Then I upload the app and it works. Let me know if anyone need help

Selfemployed

But mine is Xcode 8.3.2, and such warnings of Swift-4 is not coming, as Swift-4 comes from Xcode-9. I don't want to upgrade to Xcode-9 as for now. But still I am getting this issue, what to do ?? – Jaddo

Answer 9

I used soffes/CommonCrypto with Carthage. Remove the CommonCrypto.framework are work for me, and please check this link how to import commoncryto framework: http://ioscake.com/importing-commoncrypto-in-a-swift-framework.html

Altman