Invalid Bundle - Xcode 9 Beta 2 [resolved]

One of your binaries (app, app extension, or framework) has these compiler options specified:

-fprofile-instr-generate -fcoverage-mapping

Additionally, that target has the GCC_INSTRUMENT_PROGRAM_FLOW_ARCS build setting set to Yes (it defaults to No).

On the Xcode build settings page for each target, you can use the search feature to look for those compiler options to disable them.

Thank you for your response.

It turns out that some of my 3rd party frameworks had "Gather coverage data" enabled in their build scheme.

So this is what I did:

1. I went trough all the 3rd party frameworks build schemes and disabled the above option.
2. rebuilt all the 3rd party frameworks
3. rebuilt app.
4. Finally, resubmitted the new build and this time it completed processing with success

Can you please elaborate which setting I have to look for? I have the same issue but I can't find the culprit.

Thanks a lot!

Check this link: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/07-code_coverage.html Check the screenshot of bullet 3.

Make sure that none of your (3rd party) frameworks or other targets that are part of the app bundle have this option enabled. Unfortunately, several open source frameworks have this option enabled by default. Probably, because earlier this option was not validated by Apple during binary processing when you uploaded your app binary to iTunes Connect. (So, it went unnoticed. )

Hope it clarifies things.

Gotcha, thanks!

It's strange that this is becoming a problem now, though. Sounds like a bug in Xcode 9 or in the iTunes Connect processing backend to me.

Yes, it is a good question if it is a bug or a feature in Xcode 9 - iTunes Connect combo...

What do you think edford? Is this a new bug or a feature?

I found this in the Xcode beta release notes:

Binaries with GCC instrumentation have been rejected for some time, so doing the same for LLVM instrumentation doesn't surprise me - I don't know offhand if this is new or existing validation.

As @FrankSchlegel noted in a different comment thread, the Xcode 9 release notes have this detail:

Schemes with Code Coverage enabled (in the Test action) will now always build with Code Coverage, including for the Run and Launch actions. This reduces the need to build multiple versions of the application. Users who require code coverage to be off for their non-test actions can explicitly use a separate scheme with coverage disabled. (31848014)

I ran a quick test and turned on this switch for testing. I saw that regular builds were indeed instrumented, but the archive builds were not. However, if any of your framework dependencies are copied into the final archived build product through a script instead of letting Xcode manage it for you with an Embedded Binaries dependency, I can see situations where archive builds pull in the wrong version of the built framework and thus copies in a framework build that has the instrumentation symbols present.

Now, I undestand better what's happening. Thank you for the detailed explanation.

Well, I use Carthage dependecy manager: https://github.com/Carthage/Carthage.

With Carthage, frameworks are not built in archive phase but usually prebuilt from command line then in a build phase frameworks are copied to the app's bundle.

So, I guess it's gonna be a problem for many people using Carthage. For many 3rd party libraries (that was possible to submit successfully to iTunes Connect prior to Xcode 9) now have to be changed to clear the "Gather coverage data" in the _Test action_ in the build schemes.

I've also experienced this problem and it was kind of hard for me to investigate further (had to manually check all 3rd party frameworks for their settings).

I noticed that "Validate" option from Xcode / Organizer passes without error, not sure if that's a bug in this case?

Anyway, I was wondering if there's a way to check for this kind of errors locally in a way like it's done on iTunes Connect side, maybe it would help to point us in some direction, like which framework is causing this, via some command line utility or similar...?

Command line instructions for diagnosing this issue are published in QA 1964.

I had this issue recently - and i went through every step that is recommended - even the command line otool grep commands, and nothing was found in my binary, yet testflight kept rejecting my builds.

I finally got around it by disabling bitcode on the submission. - seems like a bug, but if you are stuck - try disabling bitcode.

If you're finding that disabling bitcode is fixing this issue, let's figure out why so you can leave bitcode enabled. A good starting point is seeing what errors appear in the log files by following the Diagnosis section of this document.If that isn't helpful, you can open an incident with Developer Technical Support for us to dig deeper - please provide a screenshot of the orginial error message, as well as the Xcode Archive (.xcarchive) producing the error.