App immediately crashing from TestFlight

Hello all, any help would be greatly appreciated.

My TestFlight builds are crashing immediately after launch. I’m successfully pushing new builds from the editor but not sure what’s going on with the native app. I have around 100 screens and have been building this app for a little over a year now and haven’t had this happen in a long time. My app is being prepared to be submitted to the app store so I’ve started prepping the database by deleting test users and clearing out test data. I also changed my “home” screen to a newly “added” screen from the side panel. I’m not sure if it’s having a hard time finding authenticated user data when launching from TF or if it’s related to the Home Screen switch or what is prompting the crash as I can’t find any crash logs on TF’s end or anything in my Apple Connect account. I’m an Adalo expert and I’m very familiar with the platform and all workarounds. I’ve tried stripping newly added components and various groupings/positioning of said components one at a time to diagnose with new builds and it’s been consistently happening so I’m running out of potential solutions. I was having successful builds a handful of days ago so I’m not sure what’s going on. I’m frantically trying to get this sorted as I’m trying to launch my app and have it sent off for approval ASAP, this is the last hurdle here so any help or guidance is appreciated.

Hey @CM11,

Here is the way to find crash logs: Acquiring crash reports and diagnostic logs | Apple Developer Documentation.
In brief, it’s Settings app → Privacy > Analytics & Improvements (this one on the bottom) > Analytics Data → then you find your app in the long list of logs there.
Did you try to locate it on your device? If none exists, that’s kind of weird - never seen this :-/.

If a log exists, you might find something useful there. However the best way to proceed is to submit a ticket to Adalo support.


P.S. I tried to debug crash logs few times - but in all cases they were caused by a crashed thread “Thread number Crashed:: Dispatch queue: com.facebook.react.ExceptionsManagerQueue”. And then it seems that the crash is caused by some deep things in React Native components - and we can’t do anything with that.
If you find something interesting - please don’t hesitate to share :slight_smile:

Thanks @Victor , I appreiciate the guidance. Didn’t know those were accessible in settings. I have no idea if this is the significant part of the log or just a snippet that I found but the log is extremely long so here’s a small snippet I put into ChatGPT to try and find what it could mean.

“asi” : {“libsystem_c.dylib”:[“abort() called”]},”

ChatGPT responded with this:

The log snippet you provided indicates that your iOS app crashed due to a signal SIGABRT, which typically means that the app was forcefully terminated by the system or a critical error occurred. The “abort() called” message points to the fact that the crash was initiated by a call to the abort() function in the libsystem_c.dylib library.

Here are some common reasons why this could happen:

  1. Exception Handling: An unhandled exception in your app’s code or a framework/library it relies on may have caused the app to abort.
  2. Memory Issues: It could be related to memory issues, like accessing a deallocated object or attempting to allocate too much memory.
  3. Resource Constraints: Running out of system resources or exceeding CPU time limits can lead to an app being forcibly terminated.
  4. Invalid Operations: The app may have attempted an invalid operation or accessed a resource that it doesn’t have permission to access.

I’m thinking #4 is closer to what might be going on, if there’s data missing from the authenticated users data that is no longer there when launching the app? I used my Apple ID email for my test user account that I’ve had in my app for a really long time now and just recently cleared that out alongside other made up test accounts I had. Not sure if I logged out of that account on the native app before pushing the newest build from Adalo.

Hi Connor @CM11,

Yes, crash logs could be quite long…
Here is a bit more info what SIGABRT means: Understanding the exception types in a crash report | Apple Developer Documentation.

There might be some useful info in the “Last Exception Backtrace” section right below the crash description. Also usually you see what Thread has crashed and its backtrace as well. The order of entries is reverse (most recent functions are on the top).
Binary file names (on the left side) and function names (on the right side) may give you a hint of what’s happened.

What I suspect though is that in order to understand which functions inside the app itself might be causing the crash, you will need to “symbolicate” the crash log. For example, in my crash log I see function names like “0x10256c000”, which doesn’t provide any info. Symbolicating the log requires some additional tools (seems XCode is needed).

A couple of useful links:


Thanks for the help @Victor, I did look through the docs but didn’t make any progress towards a solution on my own. I went back and forth with Apple developer support only to come to the conclusion through them that it was on Adalo’s end. The app finally launched after a few days and what seemed to be 6 trial builds later to TF. It’s a bit unsettling to not know what caused this as I’m on the brink of launching the app and question the stability of Adalo long term. I never received an email back from Adalo support either when reaching out to them over a week ago. I understand this forum can be helpful but a more personal line of support for long term paying members should be able to be relied upon.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.