Debugging iOS app running on MacOS via Test Flight

I have developed an iOS application which works well when run from Test Flight on my iOS device.

I would like to release the app on Apple Silicon MacOS devices, so I checked the box to specify that the App can be released on Apple Silicon MacOS devices and downloaded TestFlight on my MacOS.

When I launch my app from TestFlight on my MacOS device, the app closed immediately. I cannot locate any error messages in the Console app. What is the best way to debug the problem that's causing the app to instantly close?

Thanks.

Answered by DTS Engineer in 713776022

Now there's a crash report though

Sadly, that’s not useful. I misread your original post and sent you down the wrong path here. Re-reading that post it’s clear that you’re doing the iOS Apps on Mac thing, and I wouldn’t expect you to be able to run such an app from Terminal.

My apologies.

As to what is going on here, it’s hard to say. In general iOS Apps on Mac are meant to Just Work™ — within the documented constraints of that feature — and there are no knobs for you to twiddle.

Earlier you wrote:

the next message that's in the console about the app after the messages stating its launched is:

… termination reported by launchd (0, 0, 256)

That 256 is interesting. I dug into the log message and it seems that this value is a wait status, as returned by system calls like waitpid. If you look at the waitpid man page, you’ll see there are macros to decode such values. Consider:

int status = 256;
fprintf(stdout, "WIFEXITED: %d\n", WIFEXITED(status));
fprintf(stdout, "WEXITSTATUS: %d\n", WEXITSTATUS(status));

So it seems your app has called exit with a value of 1, aka EXIT_FAILURE.

It’s rare for framework code to exit your app in this way. Most of the time when a framework decides it’s time to terminate the process, it traps in some way, and that generates a crash report. Sometimes a framework might call exit with 0 due to normal termination.

My best guess is that some third-party code within your process — your code, or code from one of the third-party libraries you’re using — has detected a problem and called exit. Try this:

  1. Build your app for the device.

  2. Find all the Mach-O images within the app:

    % find MyApp.app -type f -print0 | xargs -0 | grep Mach-O
    % find MyApp.app -type f -print0 | xargs -0 file | grep Mach-O
    MyApp.app/MyApp: …
    
  3. Search each one for calls to exit:

    % nm MyApp.app/MyApp | grep exit
    

    and its low-level equivalent _Exit:

    % nm MyApp.app/MyApp | grep _Exit
    

Any hits?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Does it actually crash? If you run Console and select Crash Reports on the left, do you see reports for your app?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

No, there's no crash report listed for it.

Interesting. In that case, it’s most likely that the app has terminated itself. Run it from Terminal like this:

% /Applications/MyApp.app/Contents/MacOS/MyApp ; echo $?
0

what does it print?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

Now there's a crash report though

Sadly, that’s not useful. I misread your original post and sent you down the wrong path here. Re-reading that post it’s clear that you’re doing the iOS Apps on Mac thing, and I wouldn’t expect you to be able to run such an app from Terminal.

My apologies.

As to what is going on here, it’s hard to say. In general iOS Apps on Mac are meant to Just Work™ — within the documented constraints of that feature — and there are no knobs for you to twiddle.

Earlier you wrote:

the next message that's in the console about the app after the messages stating its launched is:

… termination reported by launchd (0, 0, 256)

That 256 is interesting. I dug into the log message and it seems that this value is a wait status, as returned by system calls like waitpid. If you look at the waitpid man page, you’ll see there are macros to decode such values. Consider:

int status = 256;
fprintf(stdout, "WIFEXITED: %d\n", WIFEXITED(status));
fprintf(stdout, "WEXITSTATUS: %d\n", WEXITSTATUS(status));

So it seems your app has called exit with a value of 1, aka EXIT_FAILURE.

It’s rare for framework code to exit your app in this way. Most of the time when a framework decides it’s time to terminate the process, it traps in some way, and that generates a crash report. Sometimes a framework might call exit with 0 due to normal termination.

My best guess is that some third-party code within your process — your code, or code from one of the third-party libraries you’re using — has detected a problem and called exit. Try this:

  1. Build your app for the device.

  2. Find all the Mach-O images within the app:

    % find MyApp.app -type f -print0 | xargs -0 | grep Mach-O
    % find MyApp.app -type f -print0 | xargs -0 file | grep Mach-O
    MyApp.app/MyApp: …
    
  3. Search each one for calls to exit:

    % nm MyApp.app/MyApp | grep exit
    

    and its low-level equivalent _Exit:

    % nm MyApp.app/MyApp | grep _Exit
    

Any hits?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your help. After investigation by the team that developed one of the frameworks we are using, an issue with the framework was discovered.

The framework has been patched and the app is now launching as expected on MacOS M1.

Debugging iOS app running on MacOS via Test Flight
 
 
Q