Native Android app crashes on open

I am having an issue with one of my apps. I am testing this app over a variety of platforms: Desktop web, iOS native, iOS web, Thunkable Live, Android web, and Android Native. My app works on all of these except for the Android native. I have rearranged things, tried to minimize code, etc. No luck. My test user is able to open the app and get to my “Sign In” screen, and then it crashes. After the first download, it crashes just on the open, so it doesn’t even make it to the “Sign In” page. I will attach screenshots of my first two screens. (It doesn’t get past these) Any help would be much appreciated. My deadline for the demo is early next week. Thanks in advance!
Screen one (Opening loading screen)

Screen two (Sign-In Screen)


You’re not checking that stored variable TechID is not null before you check if your list contains it.

That’s pretty straightforward code, and although I suggested that not checking for null might be a problem, I can’t cause the crash with sample code. I wonder if this is the same bug reported here:

It looked like the “navigate to” blocks were the problem initially (which was really weird!), but turned out to be an invisible web viewer problem, and it was an android specific problem. Any chance you’ve got an invisible web viewer somewhere on one of the screens you’re supposed to be navigating to?

I don’t have any web viewers on either of those screens. I have some later, but I believe they are all visible. They are later in the app anyway.

1 Like


If you put a vibrate block right before the navigate block, does the phone vibrate before crashing?

1 Like

I will give that a try. I am an iOS user, and my primary Android phone walked out of the office an hour ago. I have an old Android I can try it with. But of course, I get to wait the lovely wait time for the APK to compile and send to my email :slight_smile:

1 Like

Does it only crash in a downloaded apk, not in live?

I have not tried it with live on Android (Didn’t think if that)… it doesn’t on web. Again, it’s someone else’s phone for the Android, so I try not to ask them to install too much.

1 Like

What does sthRememberLogInID (in Login screen) suppose to contain?

1 Like

sth Is my shorthand for switch. This is referencing the toggle switch which says “Remember Me” on the login screen.

And I have an update that is essentially saying “Ha, you didn’t investigate, and here are the consequences”. I booted up my old Android which is running 8.1.0, and I installed both the Thunkable Live app and the APK for my app, and it all worked perfectly. I am now thinking the problem was with my tester user’s device and not the app. (Although, I thought I saw something that was saying OS 9 was having some problems, so it might have been in that too.) Thank you all for your help.


Android 9 is more strict and it is where the web viewer visibility issue started.

When you have a chance to test again with a device having Android 9 test you condition in the first screen

And make it only test for null and see if it takes you to your Login screen every time not only the first time.

1 Like

The intervention of Thunkable’s staff is definitely needed. Time to clarify or stop options that would cause failures. I’ve been researching my project for a month now and found that the crash possibilities are endless and not limited to the web viewer, gifs also cause crashes, date viewers can also crash in certain conditions, navigators too. In general, all crashes are caused by parameters in the design of the screen and I think it is caused by the last update of about no more than a month. Before that, my application was running on Android 10. About a month ago, it suddenly started collapsing :slight_smile: . But when it comes to this platform, each problem can be individual

You just wake up in the morning and realize that something is wrong with your app!


Well, now that you mention it, my app does have a GIF on both my loading and login screen. It sounds like you have had an issue with this before?

@muneer Is this issue with only Android 9. I think my test user has a newer phone, so there is a good chance it is running higher than 9. Would they be getting the same issue?


I would not blame Android 9 only. It must be something changed within Thunkable codes or in the updated React Native libraries. Things were working fine but the last couple of updates from Thunkable side really made me re-visit my codes to make them work again. I am sure my web viewer component was working while set to invisible but suddenly stopped.

I use a lot of JavaScript codes to make certain options available like reading and writing text files but since the last couple of updates JavaScript that are loaded as assets in the project do not work on Android.

GIF seems to act weird when made as background of a column in the screen but works well when used directly as the background of the screen and other small issues.

I hope to have answered your question.


Hello everyone,
I have an update on this issue. I opened my testing pool and I tried what @catsarisky said regarding adding a vibrating block before the screen switch. All of the newer devices I tested (Which are somewhere around Android 10 or 11) complete the vibrate but fail and crash (Hard) on the screen switch. Does anyone have any further thoughts?

It’s probably not the navigate block, but where the navigate block is going TO.

Here is the screen I am going to next. It is my home screen which has a navigation, hidden text box (DevMode code), and a data viewer list. It is really simple. Here are the screenshots. What do you think?



I’d speculate its that data viewer refresh - if you disconnect that block, does the crash go away?

Crashes on refresh were reported here:


@catsarisky No, I took the block out and it still didn’t work.

1 Like

Interesting. I’d start unplugging blocks from that screen until it stops crashing.

Does app variable DevMode exist and have a value?

1 Like