TestFlight corrupting app's executable. App failing to launch only when installed from TestFlight

I've got an app that runs perfectly well when run from the debugger. When uploading to TestFlight it goes through fine and am able to download using the Testflight app.


However, the moment I launch the app, it displays the splash for 20 or so seconds before closing. No crash report as such is generated but was able to extra a '.ips.beta' file from CrashReporter and it looks like this:


Exception Type: 00000020 Exception Codes: 0x000000008badf00d Exception Note: SIMULATED (this is NOT a crash) Highlighted by Thread: 0 Application Specific Information: com.some.app failed to launch after 20.00s (launchIntent: foreground-interactive) Elapsed total CPU time (seconds): 30.760 (user 30.760, system 0.000), 77% CPU Elapsed application CPU time (seconds): 0.080, 0% CPU Filtered syslog: None found Thread 0 name: Dispatch queue: com.apple.libdispatch-manager Thread 0: 0 libsystem_kernel.dylib 0x3805e3c0 0x38048000 + 91072 1 libdispatch.dylib 0x37f749a6 0x37f64000 + 68006 2 libdispatch.dylib 0x37f66b2e 0x37f64000 + 11054 Thread 1 name: Dispatch queue: com.apple.root.default-qos.overcommit Thread 1: 0 libsystem_kernel.dylib 0x3805d54c 0x38048000 + 87372 1 libdispatch.dylib 0x37f727f0 0x37f64000 + 59376 2 libdispatch.dylib 0x37f727da 0x37f64000 + 59354


I can see it says '8 bad food' and that it's closing before it's able to initialize - but - it produces no statements in the console, and it's running absolutely perfectly on a device when run using the Debugger or even when I install a Adhoc copy (manually from Xcode or using Fabric). Why would it fail only when coming from TestFlight? How do I go about debugging this when it's working fine otherwise. It's failing on every device that it otherwise is able to run using the debugger.

I have even tried putting a NSLog statement in the main() method before the delegate gets passed control - that doesn't get logged to the console (I'm using the Device Manager to see raw device logs). Furthermore, every time I launch the app, I see this before the app closes:


AppName[640] : Bogus event received by listener connection: { count = 1, contents = "XPCErrorDescription" => { length = 18, contents = "Connection invalid" }

What does this mean?


UPDATE: Please see my comments below - it's not the app, it's TestFlight.

Accepted Reply

I looked at one particular report of this problem, and my preliminary conclusion is that there is a problem when there is an app extension with the same name as the main executable file for the app. If you're seeing this problem, you can try renaming one of those so that they have distinct names. There's a good chance that will avoid the problem.

Replies

Our bundle ID doesn't have anything strange in it. No symbols or numbers.


Just the Display name has a "+" at the end, and the entitlements file name ends with a "+".

We are having the same problem. Completely ruining our iOS9 launch. Any updates from Apple?

Do you happen to have "Include Bitcode" checked when you export the ipa for upload? http://d.pr/i/1j1aP/4VdNpP1L

I am having the same issue with TestFlight. But it appears that is also how Apple tests apps once submitted, so now they rejected my app for this reason.

I've finally received a reply saying they've looked into this and they *may* actually really be a TestFlight bug - HOWEVER they've asked me to contact Apple Technical Support team (i.e. create a ADTS ticket) as they may be able to help by explaining how to tweak the build settings. I had already contacted them 4 days ago but they never responded. I suspect there must be some setting in xcode build options that allows us to disable Slicing / App-Thinning. I'm going to hunt this down and report back if I have any luck. Stay tuned.

Just got a reply from Apple Technical Support saying we only help with code level issues. Great. How awesome is this! Developer support says it's a bug that ATS can help with, ATS says we can't do anything about this. Bug reports going unanswered for.


Seriously, is this really happening? This has to be the worst iOS launch EVER. Reminds me of how it felt like working for Nokia back in those days before their arrogance got the better of them. I urge you all to kindly log a bug and please call / email ADS for help. Someone's gotta be willing to help!

Hi Smithers,

I'm sorry you're having a rough go here - thanks for filing the bug. Investigating.

I ran into the same issue with my app, only this time during App Review, which rejected my update saying the app was crashing on launch. The crash logs they sent were consistent with this same problem (app doesn't launch for 20 seconds), with the same exact trace:


Exception Type: 00000020 Exception Codes: 0x000000008badf00d Exception Note: SIMULATED (this is NOT a crash)


This is only for the iPhone version of my app. The same app has an iPad version, with exactly the same code-base but different bundle ID, and it went through App Review just fine. So the issue might not be TestFlight specifically, but generally the iTunes Connect binary management system.



@TidBits: the Apple ID on this app is 327685977, if you want to have a look.

Thank you TidBits! I truly am having a rough time, as well as users who have been waiting for an update (as we have some critical bugs fixed) and there's nothing I've been able to do about.


I even watched the Keynote on App Thinning - clearly it's removing 'Slices' of the binary, but in our case, it's removing ALL of the slices irrespective of what device I try this with. I even tried setting 'Enable Building Only Active Resources' to NO (as per the WWDC tutorial on App Thinning) but that seems to only affect the resources and not the binary.


I've tried it:

  • with or without bitcode
  • with or without optimizations
  • with or without all code commented
  • with or without 'Standard architectures' vs. manually setting it to 'armv7, armv7s, arm64'
  • with or without stripping debug symbols
  • with or without a dozen other changes to build settings (libraries, frameworks, weak frameworks etc)
  • with everything and anything but it just wont stop slicing my binary down to 450kb!


Before the 11th we couldn't upload the app even for internal testing as it had the 'Invalid Watchkit blah blah' error that dozens were seeing. Then on the 11th after waiting for WEEKS to be able to test even ONE build with iOS 9 - I get the above. On top of that to put insult on injury, Apple emails us with "Submit your iOS 9 apps today!". Woo hoo!


I realize we're all humans here with human errors and mistakes, but the fact that Apple's code is degrading over the years with apparently more and more issues cropping up without adequate testing / QA (I've got a story to tell about the 10.11 GM, but I digress) is depressing. We respect everyone working in or for or around Apple as you guys make amazing things happen. Please don't let this slip. The above is what I believe a SERIOUS issue. People can't actually submit their apps. If it won't fail in TestFlight it's failing in Review. Many of us have logged a bug on the 11th. Many of us called ADS. Many of us have been going to and fro between emails and phone calls, quite literally begging the receiving end for a miracle (i.e. for the right technical folks to see and fix this or at least advise what we need to do).


I'm sorry for going on and on, but quite simply I'm frustrated, have had lack of sleep, and have persistently tried to solve this on my own for too long and it just won't work.

Yes I do, it's not bitcode it seems or any other build setting as far as I can tell. They should have allowed developers to 'Beta' test their TestFlight slicing mechanism before launch. They never fixed the initial bug preventing most developers from submitting internal builds and suddenly they go GM with heaps of issues coming up. If only Apple had tested this thoroughly out in the wild with real apps, they would have sorted this out much earlier. Hopefully a lesson learned for iOS 10 because unlike previous iOS GMs, this one felt haphazard. I suspect it's because of their tvOS - core engineers assigned to the new project, thus creating an imbalance.


Any way, don't mind me. I'm annoyed, frustrated, angry, depressed and sad. I am entitled to say all of the above and more!

Same issue


Bug #22677055

The Apple ID for our app is: 432347219


Tried the same permutations as Smithers still no luck either.

Same problem.


I filed a bug too: 22721370

Filed a bug: 22723131

FWIW:

- my app has three versions: iPhone, iPad and universal. Only the iPhone app is running into this problem. The iPad and universal versions went through App Review and are working fine.

- I spoke with an App Review person on the phone (who called to tell me my app was crashing and they were rejecting the update) ... he said they don't use TestFlight for testing. So it might be a wider issue than TestFlight per se; it's probably a bug in Xcode when it buids the app archive and/or uploads to iTunes Connect.

- I was able to reproduce the same issue in TestFlight though; app fails to launch, then crashes after 10-15 seconds

- I don't have Bitcode enabled in my app, since I use the Dropbox SDK which isn't built with it

- I have a watchOS 1.0 component that I hadn't updated to watchOS2

- removing a couple of external libraries hasn't helped the cause

- I also tried setting "Enable On-demand Resources" to No (I wasn't using any) ... didn't help


Open to suggestions as to what to try. Truly maddening. On top of that, half the time I upload a build to iTunes Connect, it gets stuck in "processing", and I have to upload a 2nd build and that magically works! What a waste of time though.

Further notes: removing the WatchKit component from my project settings and uploaded to TestFlight, and voila, it works!


You guys should try it. Might not be feasible to submit this to App Review, but at least can get TestFlight build up and running.