Request for Assistance: Increasing Crash Rate on iOS

[kbesaha]

Good afternoon,

We are observing a consistent increase in the crash rate on the iOS platform across our projects (for example, the game "Christmas Sweeper 3"). The most significant surge when the crash rate nearly doubled occurred on November 17, 2023, following the release of iOS 17.1.

Additionally, on November 2, 2023, we updated AIR from AIR_SDK_50.2.2.4 to AIR_SDK_50.2.3.6. These two events— the AIR update and the iOS version release—present two potential causes for the increased crash rate.

Despite our efforts to resolve this issue since November 2023, the crash rate continues to rise. We have updated AIR multiple times and are now using AIR_SDK_51.0.1.3.

Also, we don't have a 100% reproduction of these crashes, we only know that they occur on the launch screen immediately upon launching the program.

Could you please suggest a solution or provide guidance on how to address this issue?

Looking forward to your advice.

Best regards,
Khrystyna Besaha,
Product Manager, Charstudio

[FliplineStudios]

Are you packaging the iOS app on a Mac, or on Windows? And if you're packaging on Mac, are you supplying the -platformsdk path to point to the iOS SDK in Xcode?

If not, I'd recommend trying that first, as there were a lot of packaging changes in the 50.2.3.x releases where it's difficult to still package on Windows and maintain compatibility with all devices/iOS versions (often resulting in a crash on startup on those devices).

There's a way to have AIR use a connected Windows PC and Mac together to package things up now, but my personal workflow is to just take all of the files that I would normally have packaged together on Windows, and instead copy them over to a Mac and run adt to package them there.

[kbesaha]

We are packaging on a Mac, so we will try your recommendations, thank you ahead

[kbesaha]

Hello, we did as you recommended and updated the app, but the level of crashes is the same. Do you have any other ideas? Very appreciated. Thank you ahead.

[FliplineStudios]

Hmm, if you see it happening on a device you have, you could check the crash logs on the device to see if there's more information. If it's not happening on your own devices, have you checked Xcode Organizer to see if you can find more information about the crashes there?

(If you have your developer account logged in in Xcode, open Xcode and go to Window > Organizer where you can see crash logs for each of your apps, from anyone who opts in to let them be shared).

If you see the crash logs listed in Xcode Organizer, you could post them here and maybe someone at Harman will have a better idea of what's causing it.

I also saw a newer release of 51.1.3.2 fixed a (startup?) crash on iOS related to handling memory warnings, though I've been seeing what I think are memory warning crashes in our apps at least as far back as 33.1.1.345 so not exactly sure how recent those crashes that it fixes are.

[kbesaha]

Hello, we managed to catch these crashes by accident a few times, but there are no clear and understandable steps on how to reproduce it. Here is an example of a crash and the logs from the device. But unfortunately, we find them not very informative. Maybe you will see something useful there, thanks in advance

FKGX5918_compressed_fast.1.MOV

fc_c-2024-12-13-162507.txt

[FliplineStudios]

@ajwfrost may have a better idea about that crash log, I believe Harman is taking a holiday break right now so might be a little while before he has a chance to respond. At first glance it looks very similar to the crashes we see in our apps too, with the same exception codes and also seeing UIApplication _performMemoryWarning in the log, though I'm not very experienced in deciphering the logs!

I'm wondering if the fix in 51.1.3.2 for handling memory warnings is related (if that's what's actually causing the crash.) I haven't tried updating myself yet though...

[kbesaha]

Thank you for your assistance, and I look forward to any help from @ajwfrost

[ajwfrost]

Hi @kbesaha - thanks for the log there. The error seems to be at the below call stack:

                    "symbol": "-[UIApplication _performMemoryWarning]",
                    "symbol": "-[UIApplication _receivedMemoryNotification]",
                    "symbol": "_dispatch_client_callout",

and as @FliplineStudios has pointed out, we put a fix into 51.1.3.2 for a similar crash that we'd found in applicationDidReceiveMemoryWarning. This may not be exactly the same though, as those symbols are different (and are not mentioned in the documentation about this, or in the UIApplicationDelegate documentation).

performMemoryWarning is not referenced in Apple's documentation at all but does seem to be used by people checking for low memory scenarios as a bit of a hack, e.g. https://stackoverflow.com/a/8727632. We don't have this symbol mentioned in our code...

Do you have any ANEs that may be trying to handle situations and might be triggering this call? From what we can see from Apple's perspective, they should not be calling this, and we are certainly not handling it, so I am wondering if the issue is coming from elsewhere...

thanks

[FliplineStudios]

performMemoryWarning is not referenced in Apple's documentation at all but does seem to be used by people checking for low memory scenarios as a bit of a hack, e.g. https://stackoverflow.com/a/8727632. We don't have this symbol mentioned in our code...

Interesting, since we've also been getting the same crashes starting with 33.1.1.345 mentioning UIApplication _performMemoryWarning even without any ANEs that could trigger that (See #3631). Packaging with 33.1.1.63 and earlier didn't have that issue, but every build we've done after that has been hit with this issue, whether we use ANEs or not (or even the same ANEs that a .63 build used, which didn't experience crashes when packaged with .63)

[ajwfrost]

I can't see any obvious reason for a change in behaviour between different releases there. But if we add a fake call to the below:

[[UIApplication sharedApplication] performSelector:@selector(_receivedMemoryNotification)];

then we see in the console output:

Received memory warning.
Application received a memory warning from the system.

This is a debug build, I'm wondering if there's different behaviour in a release one. No hint of a crash even though we've called this lots of time. It may well depend on the actual memory situation for the application I guess.

Ah ... and actually, the second line of trace in the console is something I just spotted in our code, in the function that we had changed i.e. our applicationDidReceiveMemoryWarning handler. And this is the function that we found had a potential to crash, if the runtime hadn't properly initialised (or potentially if it was being shut down). Hopefully now, it has the protection in place to attempt to trigger GC to release external free memory back to the OS regardless of the state.

So I think, try with that latest version of the AIR SDK, and we should see this start to improve!

[kbesaha]

Hello, thank you for your support, we will update AIR SDK and come back with our results

[marchbold]

@kbesaha Are you using a version of the Debug ANE? Some versions of this extension implemented the performMemoryWarning hack that @FliplineStudios mentioned but this will cause issues in a live application and was only meant to be used for testing in the simulator.