AppStore Review crash report

Hi,

I’ve submitted a new version of my app which is rejected because

The crash log significative lines are

AppStoreTools: 11E608a Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] OS Version: iPhone OS 13.5.1 (17F80) Release Type: User Baseband Version: n/a Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0

The rest of the crash log is not helping (me). It seems to be ‘unsymbolicated’:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:

0 libsystem_kernel.dylib 0x00000001b599cd88 0x1b5977000 + 155016 1 libsystem_pthread.dylib 0x00000001b58b51e8 0x1b58b3000 + 8680 2 libsystem_c.dylib 0x00000001b5808934 0x1b5796000 + 469300 3 libsystem_c.dylib 0x00000001b5807d54 0x1b5796000 + 466260 4 Babel O'Clock 0x0000000103296cec 0x102ff4000 + 2764012 5 Babel O'Clock 0x0000000103297050 0x102ff4000 + 2764880 6 UIKitCore 0x00000001b9c44c74 0x1b9220000 + 10636404 7 UIKitCore 0x00000001b9c46a00 0x1b9220000 + 10643968 8 UIKitCore 0x00000001b9c4c29c 0x1b9220000 + 10666652 ...

App developed with Xojo 2019r3.1.
macOS 10.15.4
Xcode 11.5

This app works without any problem in the simulator for many iPhones & iPad models, from iOS 11 to 13.5
The app was tested on physical devices:

  • iPhone SE 13.3
  • iPhone 11 Pro 13.5.1
  • iPad Pro 12.9’’ 13.4

There are no errors.

The app.UnhandledException event is implemented with Return False

Is it bad practice to ‘Return True’ in app.UnhandledException event ?

How can I decode the crash log ?
I found a tool from Jason King here but its 32-bits.

Does someone have a idea on how to proceed to find the error ?

Thanks !

For the Mac, there’s a MacSymbolicator app that you can try, but I haven’t had too much luck with it.

https://github.com/inket/MacSymbolicator

@Art Gorski
Thanks. I downloaded the MacSymbolicator and got a little more info.
Here is the partial crash log:

Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000001b599cd88 0x1b5977000 + 155016 1 libsystem_pthread.dylib 0x00000001b58b51e8 0x1b58b3000 + 8680 2 libsystem_c.dylib 0x00000001b5808934 0x1b5796000 + 469300 3 libsystem_c.dylib 0x00000001b5807d54 0x1b5796000 + 466260 4 Babel O'Clock 0x0000000103296cec UnhandledException(RuntimeObject*) (in Babel O'Clock) (iOSApplication.mm:0) 5 Babel O'Clock 0x0000000103297050 -[XOJAppDelegate application:didFinishLaunchingWithOptions:] (in Babel O'Clock) (iOSAppDelegate.mm:59) 6 UIKitCore 0x00000001b9c44c74 0x1b9220000 + 10636404 7 UIKitCore 0x00000001b9c46a00 0x1b9220000 + 10643968
I’m asking the reviewer to send me the app logs, created in UnhandledException, if the app could write them.

Let’s see what I get…

Just out of curiosity, are you using any technologies that would ask for the users privacy permission? Location, Microphone, Camera, Photos, Touch or FaceID, etc? If so, have you included the relevant plist entries?

Also, in your crash log, there’s usually one or two lines of info between the header and thread stack that you posted. If there is, could you post that?

[quote=492703:@Olivier Colard]The app.UnhandledException event is implemented with Return False

Is it bad practice to ‘Return True’ in app.UnhandledException event ?[/quote]
I wouldn’t say there is good or bad practice to return True in UnhandledException event.

But returning False will let the app crash whenever there is an exception. Returning True prevents that but the app may become unresponsive or not behave as expected.
In my apps, the UnhandledException event logs the error in an online database and sends me an email directly. Then it returns True to let the app continue.

From what I read in the crash log, the exception seems to be in App.Open event.

A couple of times, after receiving such reason (crash at start) for rejection, I just resubmitted a new binary (with increased “Non release version”); and the crash did not happen anymore.
I guess something had gone wrong during the uploading process.

Edited: I just resubmitted the same binary with increased…; obviously a binary with increased number is no more “the same”.

No, I don’t use any of this.

It was in my first post, here again with MacSymbolicator update:

[code]Process: Babel O’Clock [10902]
Path: /private/var/containers/Bundle/Application/03FDC448-6C84-4E5F-9F32-6F5DF84C1B5A/Babel O’Clock.app/Babel O’Clock
Identifier: com.babeloclock.ios
Version: 1.1.5 (1.1.5)
AppStoreTools: 11E608a
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.babeloclock.ios [4191]

Date/Time: 2020-06-17 06:17:03.0893 -0700
Launch Time: 2020-06-17 06:17:02.3581 -0700
OS Version: iPhone OS 13.5.1 (17F80)
Release Type: User
Baseband Version: n/a
Report Version: 104

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001b599cd88 0x1b5977000 + 155016
1 libsystem_pthread.dylib 0x00000001b58b51e8 0x1b58b3000 + 8680
2 libsystem_c.dylib 0x00000001b5808934 0x1b5796000 + 469300
3 libsystem_c.dylib 0x00000001b5807d54 0x1b5796000 + 466260
4 Babel O’Clock 0x0000000103296cec UnhandledException(RuntimeObject*) (in Babel O’Clock) (iOSApplication.mm:0)
5 Babel O’Clock 0x0000000103297050 -[XOJAppDelegate application:didFinishLaunchingWithOptions:] (in Babel O’Clock) (iOSAppDelegate.mm:59)
6 UIKitCore 0x00000001b9c44c74 0x1b9220000 + 10636404
7 UIKitCore 0x00000001b9c46a00 0x1b9220000 + 10643968
8 UIKitCore 0x00000001b9c4c29c 0x1b9220000 + 10666652[/code]

[quote=492759:@Jeremie Leroy]In my apps, the UnhandledException event logs the error in an online database and sends me an email directly. Then it returns True to let the app continue.

From what I read in the crash log, the exception seems to be in App.Open event.[/quote]
I’m storing the info in a log file and the user can send it thru the contact form. Useless if the apps doesn’t even start.
I’ll send a mail directly in UnhandledException.
I’ll also double check the Open event.

Also, FYI, I’l using the ImprovediOSApplication class to handle DidBecomeActive & WillResignActive events. I’ll check that again.

Did you get any resolution here? I just had the same thing happen to me. App runs fine on all my devices. Crashed on startup for the reviewers.

Where/how do you add the PLIST entries? My app asks for permission to send notifications. It works fine in all the development builds.

Thanks.

I still haven’t solve this. Same problem. Runs on all physical devices and simulators. Crashes at startup with reviewers.
They don’t want to tell which devices, physical or simulator they are using.
I don’t have more time to lose now, maybe later this year.

I figured out how to solve this!

First the device type is shown in the crash report.

Second, what you need to do is set yourself up as a beta tester in TestFlight and then test the .ipa file that comes from the store. I found my crash doing this.

The problem is that I had a file that I copied over to the Resources folder and was using Xojo.io.GetResource to access. This works fine with the .app files that you use when you install the app using Xcode. But it does NOT work with the .ipa files. It’s yet another significant bug in the Xojo iOS framework. I’ll be filing a bug report once I get my app released.

But yeah, test with TestFlight. I am sure you will find the problem.

2 Likes

Hi @Jon_Ogden I think I am having the same issue. All is working fine on test devices and simulator but rejected 3 times from the store. I too am loading text files from CopyFiles in Resources. Did you find a solution?

Yes. Set yourself up in TestFlight so you are actually loading/running the IPA. It is likely a file signing issue or something like that. Once I was able to duplicate the crash it was an easy fix. Don’t assume that the .app file generated and copied to your device in XCode works the same way as the install of the IPa from the store or TestFlight.

2 Likes

If you don’t mind what was your fix for the GetResource issue?

I believe it was a signing issue. The copy was happening after the signing step in the build process. This doesn’t affect things when copying the .app file in Xcode but it does matter when using the IPA installed by TestFlight or the AppStore.

I believe this was the issue.

1 Like

Yes, it was definitely a signing issue. I just had a chance to go back and look at the code. I still use Xojo.IO.SpecialFolder.GetResource. What had to be changed was that the build step of the file copy to the resource folder HAS to take place BEFORE the signing step of the build process. Otherwise the file is not signed and iOS pukes.