ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary

Hello,

My team is currently having an issue uploading our app to the AppStore because of the following issues:


ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary because it includes assembly source code or inline assembly. To resolve this issue, rewrite the corresponding code in a higher-level language such as Objective-C or Swift and redeliver your app. 

ITMS-90562: Invalid Bundle - There's an issue with the app's bitcode compilation. Rebuild the app using the current public (GM) version of Xcode and upload it again.

Firstly, we do not have a watchOS app at all. Our last release was successful when built on Xcode 11.6 and we're currently using Xcode 11.7. According to Apple, Xcode 12 isn't required until April of 2021, so I'm not sure what it's complaining about. Here's what we've tried.
  1. We created an AppStore build and ran it through the validator and that succeeded. It even uploads fine, but doesn't successfully process once uploaded.

  2. We created an Enterprise version of our app and exported it, making sure to enable the "Rebuild from Bitcode" option to hopefully mimic what the AppStore is doing and failing at and it still succeeds.

  3. We downloaded and used the Transporter app from Apple to try uploading our AppStore ipa, but the logs didn't indicate anything suspicious (perhaps because the bitcode compilation for AppStore variants happen on Apple's servers?)

  4. We searched for anything that could have indicated "watch" or "watchOS" in our codebase and build settings and dependencies (built from Carthage), but we didn't find anything there either.

  5. We went through the Export phase again for the AppStore build and disabled Bitcode.

The only one to succeed was #5, but we don't want to do this as a long term solution, but don't understand how to get more information as to what the problem is exactly.

Does anyone have any information on this?
Answered by JShroyer-Uni in 633985022

Update September 18th, 2020 (Solved for my use-case):


I realize this may not be helpful for some people, but I was able to figure out the problem at least for my team and hope this can assist anyone else with a similar enough situation. My team and I work on a very large codebase and I only started in my role almost a year ago, so there's a lot of stuff in our codebase that I don't have direct experience with. This also includes some third-party vendors' frameworks that exist in our codebase. Most of these decisions and dependencies were made before I joined the team.

With that said, I made a new Xcode project using 11.6 (the last successful version I used for distributing our app to the AppStore) and used the same Bundle ID and Team combination for it. I tested that I could upload the sample "Hello World" application which was successful. I then started introducing things little by little to isolate the issue and found what the culprit was for us.

For us, it was one of the third-party pre-built binaries that was provided to us which was causing the rejection. Submitting a build without that framework resulted in a successful upload and processing, but including it resulted in the error you see at the title of this post. We plan to reach out to that vendor next week to see what we can do about getting this resolved so we can go back to including Bitcode in our releases.

I hope this is helpful to others in similar situations. I would recommend uploading builds to the AppStore with Bitcode enabled and only providing a small subset of your dependencies until you find the issue. Again, this may not be helpful for everyone, but I hope it's helpful to someone. I can only conclude that rules were changed on Apple's side after the September event and that our vendor's pre-built binary has assembly or something of the sort within it. Good luck to you all and I hope you find resolution soon.

tl;dr

It was a problem with one of our third-party vendor's frameworks and we're going to ask them to investigate this.

Steps to find resolution above.
Maybe some help in this recent similar thread?
Code Block
App Store Connect Rejects Binary - Unable to Compile Bitcode
https://developer.apple.com/forums/thread/119012
Thanks, @KMT, but that link doesn't appear to have any suggestions for this either and it looks like the original poster had an issue with the beta versions of Xcode 11. I saw someone else mentioning in that thread that they're seeing the same issue with Xcode 11.7, so I'll keep an eye on it as well though in case they are related and someone has a suggestion there in the future. Much appreciated.
Having same issue with xcode 12.

Update September 17th, 2020:


Because we don't want to keep Bitcode disabled for our builds, we wanted to figure out if the problem was on our side or Apple's servers changed something after the September event perhaps. So, we decided to go back a previous commit that we released successfully using Xcode 11.6 and change the version and build numbers locally, allowing us to upload our "old" build to TestFlight. We also made sure all of our dependencies were rebuilt using Xcode 11.6 and the same versions were built that we released with to make sure it was the same kind of output.

To our surprise we saw the same rejection email as stated above because Apple's servers failed to compile using the Bitcode provided. Again, this all works fine when rebuilding from Bitcode locally for a non-AppStore build (we're using Enterprise for this).

This leads me to believe that some rules may have changed on Apple's side even though our binaries were fine before as they no longer are. Still looking for leads that may help resolve this issue.
We have the same issue and we don't have any watchOS app, we finally migrate to Xcode 12 (12A7209), sent a build and it is still rejected by Apple with the same error
Has anyone tried on macOS 11?
Uploaded build successfully through Xcode12 after disabling bitcode checkmark at uploading build to App Store.
I've also been having this issue since the other day, as well as another one where I'm unable to test via USB ("the service is invalid"). I'm not certain these issues are related because I'm stuck on Xcode 11.3 and have been adding device support manually- although this has worked fine up until now on OS 14.

@JShroyer-Uni thanks for keeping us up to date on what you've tried and I'll do the same if I figure something out.
We couldn't make it work with bitcode, we ended up sending a build disabling it, the app download/install size wasn't affected which was our major concern
Accepted Answer

Update September 18th, 2020 (Solved for my use-case):


I realize this may not be helpful for some people, but I was able to figure out the problem at least for my team and hope this can assist anyone else with a similar enough situation. My team and I work on a very large codebase and I only started in my role almost a year ago, so there's a lot of stuff in our codebase that I don't have direct experience with. This also includes some third-party vendors' frameworks that exist in our codebase. Most of these decisions and dependencies were made before I joined the team.

With that said, I made a new Xcode project using 11.6 (the last successful version I used for distributing our app to the AppStore) and used the same Bundle ID and Team combination for it. I tested that I could upload the sample "Hello World" application which was successful. I then started introducing things little by little to isolate the issue and found what the culprit was for us.

For us, it was one of the third-party pre-built binaries that was provided to us which was causing the rejection. Submitting a build without that framework resulted in a successful upload and processing, but including it resulted in the error you see at the title of this post. We plan to reach out to that vendor next week to see what we can do about getting this resolved so we can go back to including Bitcode in our releases.

I hope this is helpful to others in similar situations. I would recommend uploading builds to the AppStore with Bitcode enabled and only providing a small subset of your dependencies until you find the issue. Again, this may not be helpful for everyone, but I hope it's helpful to someone. I can only conclude that rules were changed on Apple's side after the September event and that our vendor's pre-built binary has assembly or something of the sort within it. Good luck to you all and I hope you find resolution soon.

tl;dr

It was a problem with one of our third-party vendor's frameworks and we're going to ask them to investigate this.

Steps to find resolution above.
Same issue.
Hello, thanks for your feedback. Can you share the name of the third party library involved ?
my team is experiencing the exact same issue.
Thanks !
Hi. Disabling bitcode worked for our case. However, does anybody know the implications of disabling it? Right now, I have only uploaded it on TestFlight, but I still have to upload it to App Store soon, that's why I want to know what will we miss out on if I disable bitcode.

I saw the following on SO, but it's not a very recent answer, so this might be outdated by now:


Turning it off simply means that your app will live on the app store the same way it did before Xcode 7 & Bitcode. When it's downloaded, binary code for all supported architectures get downloaded from the App Store. If you turn BitCode on, then the intermediate representation of the compiled program gets uploaded and Apple will able to recompile and/or optimize your apps for future architectures (as described here).

We recently upgraded our build machine to Catalina from Mojave and at the same time we upgraded from Xcode 11.2.1 to Xcode 11.7. After the upgrade, one of our two applications's builds started getting rejected from the app store with ITMS-90562.

I tried building the application from our last successful commit using Xcode 11.2.1 on Catalina and still received a rejection for ITMS-90562. After comparing the build settings between the failing app and the successful app, I found a framework search path that was unnecessarily set as recursive. Changing this path to non-recursive fixed the issue.

broken:
Code Block
FRAMEWORK_SEARCH_PATHS = (
"$(inherited)",
"$(PROJECT_DIR)/**",
"$(PROJECT_DIR)/SomeModule/Dependencies",
);


fixed:
Code Block
FRAMEWORK_SEARCH_PATHS = (
"$(inherited)",
"$(PROJECT_DIR)",
"$(PROJECT_DIR)/SomeModule/Dependencies",
);


I recognize this might be project specific but wanted to share our experience in case it helps others.
Hi  JShroyer-Uni ,

We are also facing the same issue of "This build is invalid" message on App Store connect during processing state. The only way to get to TestFlight is to disable bitcode.
Did you find solution for it?
Also can you let us know which third party SDK you were facing with issue with and got it resolved it might help us too.


When we connected Apple, we received following email "App Store Connect does not allow uploading an updated version of an app when the update runs on fewer devices than the version of the app currently in the App Store. This is by design because an update to an app must work for every customer who has already purchased the app.
Additional information regarding this issue can be found in Technical Q&A article QA1623.
Explore developer resources to get answers to frequently asked questions, watch video tutorials, stay up to date with the latest news, and more."

Thank you,

ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary
 
 
Q