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

App Store Distribution & Marketing TestFlight
Smithers OP
Created Sep ’15
Replies 57
Boosts 0
Views 22k
Participants 15

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.

Replies  57
Boosts  0
Views  22k
Participants  15
Smithers OP
Sep ’15

What do you mean by components? Do you mean the WatchKit target? And now the app works? Could it be that WatchKit 1 apps are not supported?

0
zulfishah OP
Sep ’15

No, within the main app target, in "Embedded Binaries", remove the appex file. It'll confirm that you want to remove the Watch app from this target (the main app), said Yes to that. That's all I had to do. The app now works fine through Test Flight. Just for kicks, I added the WatchApp back into Embedded Binaries and uploaded a new build, and tested through Test Flight, and the app doesn't work anymore.


Watch1 apps are *supposed* to be supported, but my guess is something in the Xcode is corrupting the build either when you archive or when you upload to iTC. Might try updating to WatchOS2 and trying it out later, but for now, my customers can live without the Watch app for a few days (as long as App Review doesn't reject the app again for removing the watch app!).

0
Smithers OP
Sep ’15

@TidBits - is Watchkit 1.0 no longer supported? Zulfishah mentioned just today that after removing their WatchKit 1.0 app they were able to get past this issue. We've got a Watchkit 1.0 app as well and we're not ready to upgrade to 2.0 just yet. Is that what's causing the slicing bug?

0
Smithers OP
Sep ’15

Thanks Zulfishah - I think you're on to something here. That is the only thing common between us all - WATCHKIT 1.0!!


I'll remove it too but not sure if our users are going to appreciate it. Can't be bothered to update to WatchKit 2.0 only to find out it still stinks 😟

0
ChasingPtr OP
Sep ’15

Apple engineers are looking at this issue. Stay tuned.

0
CTurkoanje OP
Sep ’15

So does this mean we cannot submit any apps to the App Store?

0
ChasingPtr OP
Sep ’15

We are trying to repro the issue. What devices are you testing with?

0
OP
Apple
Sep ’15
Accepted Answer

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.

0
zulfishah OP
Sep ’15

Thanks; you are correct! The WatchKit extension shared the same name as the primary app executable. I thought that was the recommended approach they told us when I was in the Apple Watch Labs in Sunnyvale earlier in the year. In any case, changing the name for the WatchKit extension and adding it back into the primary app works; verified it on TestFlight. Hopefully that will resolve this issue for good.

Thanks for the tip; much appreciated!

0
Smithers OP
Sep ’15

Thank you! Trying now, but I think this might just be it since Zulfishah has confirmed it worked for them too.


However, I am a bit baffled though - I do recall that the Today widget, for example, had to be the same name as the main app. This was suggested in one of the WWDC videos once. Anyhow, if this requirement has changed or is causing to trip TestFlight, there should be clear documentation mentioning this AND TestFlight should at least either a) tell us this is the case, b) reject when uploading the app, c) if none of the above, at least not corrupt our executables when a similarly named extension is found!


I bet this will continue to trip new and old developers alike and needs to be fixed ASAP.

0
WearableDave OP
Sep ’15

Thank You!


Our app didn't have a watch extension, but it did have a storage extension that had the same name as the main executable. Changing the name has resolved this and the app now goes through TestFlight as expected and works on our test devices.


Apple should either fix or document this issue. Even provide an error during submission.

0
OP
Apple
Sep ’15

Yes, you are all absolutely right: this is a serious bug that we need to fix. My suggestion of renaming the extensions is simply a short-term workaround to get you unblocked while waiting for a fix. I don't know offhand if there may be other reasons why the extension should match the name of the app, and I certainly don't want to contradict the design guidance provided elsewhere. This is just a workaround.

0
spacejams OP
Sep ’15

I'm experiencing the same issue with devices running iOS9. However I have been using HockeyApp to dsitribute, not Test Flight.


With that said, devices still running iOS8 are able to launch the app with out any problems.

0
levisol OP
Sep ’15

It was the app extension for us too. I changed it an we finally have a build that made it through TestFlight and launched.


Seriously, Apple?! Seriously!

0
CTurkoanje OP
Sep ’15

Yup. Looks like that was it. My Watch App and Complication were different, but my Today View Widget was the same name.

0
TestFlight corrupting app's executable. App failing to launch only when installed from TestFlight
First post date Last post date
 
 
Q