After updating the Retool Android app to v3.191.0 from the Play Store, the app crashes immediately upon launch. This issue is not isolated — we’ve tested it across multiple Android devices, and the app crashes on every single one where the update was applied. So far, we have tested on over 30 devices, with different versions of Android.
This has had a severe operational impact for us:
We have over 100 mobile users on Android.
Our field operations have come to a complete halt today due to this crash.
Clearing cache, reinstalling, and using different devices has not helped.
We’re extremely disappointed with this instability — especially considering the amount we pay for Retool. Reliability is critical to our operations, and an issue like this should never make it to production.
This isn't the first time we've experienced issues like this on the Android app. This coupled with Retools extremely slow support for non-enterprise customers makes it very difficult to run business critical processes on mobile.
We’ve identified the root cause of the crash affecting Retool Mobile v3.191.0 on Android and have submitted a patched version (v3.191.1) to the Google Play Store for review. Based on typical review timelines, we expect the update to be approved and available for download within the next few hours.
In the meantime, for users currently blocked by the crash, we’re providing a temporary workaround: Link here
You can manually install the patched version by downloading the APK directly from the link above.
Please note that this version has not yet been verified by the Play Store, so you may see a warning during installation. Follow on-screen instructions to allow the installation if you choose to proceed, and agree to update the current app.
We are still experiencing issues with app crash while having data in pending mode. It is affecting our clients so it is very critical. On iOS and android, the offline queue is also not completely removed. Every restart of retool will retrigger the queue data that were uploaded previously.
Do you have an idea how we could solve the issue ?
Hey @Wassim - can you confirm that your clients have updated their app to version 3.191.1? It should also be fine if they're still on the previous stable version (3.183.0). Either version will prevent the crashes described above, but we unfortunately had to roll back the fix to the offline queue issue that you're referencing.
It's unlikely that the new stable version becomes available this week, but I can provide an update here as soon as we push it to the Android/iOS stores.
Every tablet is now on 3.191.1, yet 5 out of 8 still crash on launch (often after a “RAM limit exceeded” toast). Each one’s holding 12–300 unsynced records we can’t afford to lose.
Honestly, this string of bugs is killing our credibility with our clients.
We need a concrete ETA for a real fix and a safe way to pull that queued data today please.
I'm digging into this now, @Wassim, and certainly appreciate the need for a timely resolution. There are a few things I'd like to clarify:
What is the model and operating system of your devices?
Is there any discernible difference between the ones that are crashing the ones that aren't?
All offline data waiting to be synced is stored in the local file system of the device, so it should theoretically be possible to browse and retrieve them by connecting to a computer. The exact steps will be different depending on whether you're on Android or iOS. One thing to keep in mind, though, is that this storage is managed by the operating system and may be cleared when updating the app.
Interestingly, the crashes that you're seeing aren't showing up in our own logs, which makes me think that they are happening at the device level. If you're working with a lot of offline data, one possibility is that loading it all into RAM when initiating the sync exhausts what is available.
If possible, can you share a recording of the app when launching it?
Devices are Redmi Pad SE 8.7.
There is no difference between the ones that are crashing and the ones that aren't. But they are now all crashing. So 8/8 tablets are not responding anymore. When we start retool and our app is loaded, it crashes suddenly few seconds later. Some data are waiting to be synced on (some or maybe all) the tablets.
I will join you screenshots of the error we get. I can't record as it's our client devices and not ours.
Edit : We tried to access pending data, but we just found a 'retool' folder that seems to be empty. Can you please explain how we can manage to data that are waiting in queue?
Thanks for sharing, @Wassim. It certainly feels like the size of the offline queue is ultimately responsible for this, but I've passed the specific error and context on to the Mobile team. I'll give you an update here as soon as I know more.
Out of curiosity, have you tried launching the app in offline mode? Or from a separate device that definitely doesn't have anything in the queue? The other thing that might work is activating the Offline mode delay sync option in your app settings.
I personally don't think that the size of the queue really matter because on one of the crashing tablets, there are only 12 pending requests.
We already did tests as you showed with the offline mode delay sync, but it did not work. It still crashes every time we open retool.
It is very critical for us to save our pending data, can you please tell me if there is a way to get them if it is possible? You told me that data was in localStorage.
Also, I saw in the documentation that it is possible to show info about a pending request in the queue, but I don't find this on the UI. Is it a feature that is not deployed yet?
Source:
"Display body values can help provide context on the pending changes, such as displaying the original and modified values." Offline mode | Retool Docs
Thank you,
Yeah, there's a pretty big variance between the size of the queue on your various devices so that does seem unlikely, but I can't necessarily think of anything else that would require allocating ~200MB of storage. Do you have queries in your app that heavily utilize localStorage? To help us hone in on the root cause, can you share the app UUID or provide a JSON export?
In the meantime, though, let's definitely focus on accessing that queued data, if possible. The Display body feature that you referenced above was deprecated not too long ago and won't be an option, unfortunately. I'll make a note for the Docs team to have that change reflected in the documentation.
In general, offline data is intentionally obscured for security reasons and utilizes the operating system's local file system, not localStorage. Those files aren't typically browsable by default, especially on iOS, but there are certain apps you can install to expose them. In extreme cases, you may even need to resort to ADB.
I don't currently have an Android device that I can use for testing, but I'll do some research here and get back to you as soon as possible. I'm hopeful that looking at your app JSON will help uncover the underlying issue, though.
Here is a potential solution that utilizes Android Studio:
1. Connect your device via USB.
2. Enable USB debugging:
a. Go to Settings > About device
b. Tap Build number 7 times to unlock Developer Options.
c. Go to Developer Options > Enable USB debugging.
3. Open Android Studio.
4. Open any project or create a new one.
5. Go to View > Tool Windows > Device File Explorer.
6. Select your connected device in the left panel.
7. Navigate to `/data/data/retool.package.name/` (not sure exactly what this will be)
8. Inside, you should see a `/files/` folder where the app writes internal files
This does require that the app be debuggable, which I'm not sure it is by default.
Hi @Darren,
Thank you for your response (i work with Wassim in the same team), i have tested the procedure for find the offline pending data but the file is not available (the app must be debuggable). Can you send us an APK of the retool app with debuggable mode activated ?
Thanks for your patience, @marcchevalaz! Unfortunately, I'm fairly certain that installing a debuggable version of the Retool app wouldn't give you access to the data associated with the already installed version.
Do you know if your app currently has any queries running on initial page load that write data to localStorage? If so, temporarily pausing those queries might allow your app to load and to process the offline data that has been accruing.
Do you have queries in your app that heavily utilize