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

Your app is taking to long to launch so it's killed by the system which is what 0x8BADFOOD means. When you use the debugger, that launch timer is disabled. If you have a bunch of stuff to do on launch, defer it and run that code in the background.

As pointed out above, even main() does not get called. Moreover, with the debugger, the app was launching within 1 second. It's wasn't that straightforward.

After around 16 hours of head banging, I think I am begining to see what's happening. I think TestFlight possibly optimizes the build further on top of the otimizations already applied locally (since Adhoc builds were also working fine) - with these optimizations, the code was possibly running into a deadlock. I'm still hunting this down, but essentially where I had a '+(void) load' method or '+ (void) initialize' method in any of my frameworks / libraries etc, somewhere I was running into a deadlock with an exclusive lock that I frequently use, i.e. @synchronized(...). I disabled some of these methods and I finally saw one debug statement on the Console before it crashed again.

So any way, if someone else runs into this and they've tried everything (including disabling everything under 'applicationWill / DidLaunch, as well as disabling loading of the storyboard) - it could be a deadlock in one of these 'load' methods elsewhere since these get called before main().

I'm seeing the same thing. I've commented out all code in `view` methods on all controllers except a single NSLog call, and the app delegate is only logging a start up message, but I still see the error (and the app fails to launch). The app had been working fine when launch through TestFlight yesterday. Any other suggestions???

Ah, I see. You might want to check out Mike Ash's blog post on load and initialize, might have some info you can use. As he mentions in his post, load is called before main, and initialize is lazily called, sometime after NSApplicationMain(). At least you might be able to get it to crash with a log in that case. Be sure to read the comments after the post, there's some good stuff there too.

www.mikeash.com/pyblog/friday-qa-2009-05-22-objective-c-class-loading-and-initialization.html

Actually I'm back to square zero - it wasn't load or initialize. I've been banging against the wall for two days and it WONT WORK.

Finally I *****broke* my device (sorry!) but I had no other choice. I went into the directory and to my shock the actual binary is 445kb!! It should be 24MB!! TestFlight is doing something to my binary!! So because it downloads partially (is it doing some kind of app thinning - something I don't use - I don't even use bitcode!)?? Anyone else seeing this?

Bug logged as ID: 22677002

I've quadruple checked. Essentially this is what's happening (On 10.11 GM, Xcode 7 GM, iOS 9 GM. Even tried it on 10.10.5 and Xcode7 GM):

1. The app works as Debug, Adhoc and Release (when manually installed via iTunes) just fine. The app's executable is around 9MB when optimized and uploaded to TestFlight.

2. I then download it from Testflight once it gets uploaded. All extensions and widgets work just fine and their executable sizes do not change. HOWEVER - the main bundle that gets download (and like I said, I had to 'get into' my device to be able to check and verify this) gets trimmed down to 445kb, thus corrupting it completely. No wonder no entry method ever gets called or any framework gets loaded. The app just launches, hangs and crashes.

I suspect TestFlight is doing something to the binary, eventhough I have turned bitcode OFF. Even when bitcode is ON (I tried that), the app still does not launch. My project is quite complex with tons of frameworks, libraries and a lot of code so it's hard to say what's making TestFlight do this. I may not be the only one though! If your app isn't launching from TestFlight and is working otherwise, and you get the 8badf00d error pointlessly only from your TestFlight builds, the same may be happening to you. Please kindly log a bug.

As an experiment, I copied over the executable from my distribution archive to the device where the app was installed, thus overwriting the corrupt 445kb file from TestFlight. After copying it over, I launched the app as I would from the device and like magic! IT WORKED!

Thus showing the binary is indeed corrupted by TestFlight. I bet I'm not the only one, and I hope this thread finds more like me so this issue is raised and fixed ASAP! I can't believe this is happening on a GM build!

Bug logged: 22677055

We are having the exact same problem. Everything works just perfectly until TestFlight gets ahold of the app. Our 3 extensions work just fine it is only the main app that has this issue.

You are not the only one. TestFlight with the GM is indeed doing someting strange (and bad). Everything worked just fine on the last beta.

Out of curiosity, did you have Bitcode disabled as well? I suspect TestFlight is incorrectly thinning the binary and then allowing a bogus executable to be downloaded, which is almost empty.

I'm now trying again with bitcode enabled to see if it detects this. I recall running into the same issue with bitcode enabled but given my frustration and the time I've lost, it's worth another try.

No luck.. tried just now with bitcode enabled on everything (all frameworks, extensions and main app). TestFlight still downloading a '450kb' file as the main binary, instead of, say 9mb.

Bummer.

Yeah I went down that road too, tried with bitcode and without, also tried different levels of optimization in the build settings to see if that would do anything. No dice. I think I'm up to around 20 bullds submitted to testflight since the GM 🙂 all of them result in the exact same issue.

:D I tried just the exact same things! In my case I may have had 50 or so builds with at times 99% of my code disabled, still no luck. Hoping they sort this out. Ball's in Apple's court.

Did you receive any confirmation from Apple? This is starting to worry me as the bug is still there and we can't test the app or submit it.

I've called Apple Developer Support and they said they would pass this over to the correct team, but haven't received anything else from them.

In the meanwhile I've tried building again with more configuration options and trying various new things, each one resulting in the same issue.

I have not had any response from Apple. I feel your pain as we are in a holding pattern and can't really do anything until they resolve it (or at least provide some insight). Of course somehow our apps are "special" which means that even a hint into what is causing it would be very helpful. I did not try any other builds yesterday as I'm responsible for multiple apps on different platforms so I've been working on things that actually work.

I was thinking however, I wonder what does make us "special" the app I have a problem with is "AirStash+" : https://itunes.apple.com/app/airstash/id432347219?mt=8

I don't know if your app has any similar features or behavior.

Does your bundle ID have some sort of + or digit in it? We do too - our app isn't similar to yours but the only thing that's similar is that our bundle ID starts with a number (and so does the executable). Maybe that's tripping it? Non-latin characters in executables is confusing their app thinning process? Just a wild guess of course. I can't think of anything else.