Every time I try to take a photo directly from the app in a nested table it forces a Sync, I go back to my starting view and I lose all the progress made on the form. This does not happen uploading and image. (I’m using the app from my android phone)
1 Like
This is expected AppSheet behavior on Android and usually happens because camera capture triggers an automatic sync to save the image file to the server.
Key points and ways to reduce the issue:
-
When you take a photo (camera), AppSheet must sync immediately to upload the file, which can reset the current view and discard unsaved form state. Uploading an existing image does not force this.
-
This happens more often in nested tables / inline forms, where the parent form is not yet saved.
-
To avoid losing progress:
-
Save the parent form before opening the nested table.
-
Disable Auto Save only if your workflow allows it.
-
Use “Delay sync” = ON (Settings → Offline/Sync), though camera capture may still override it.
-
Consider collecting photos in a separate form or step, then linking them after the main record is saved.
-
This is a known UX limitation on Android rather than a bug, and restructuring the form flow is currently the most reliable workaround.
This is the first I’ve heard of this.
1 Like
You’re not alone, Steve — it’s not widely documented, but it’s a well-known Android-specific AppSheet behavior, especially once you mix camera capture + nested forms.
What’s happening isn’t random:
On Android, taking a photo triggers an immediate file upload, which forces a sync so AppSheet can persist the image and generate a valid file path. If the form (or parent row in a nested table) hasn’t been saved yet, the sync can reset the view and discard unsaved form state. That’s why uploading an existing image doesn’t cause the same issue.
This shows up most often when:
-
Using nested / inline tables
-
The parent form isn’t saved yet
-
Capturing photos via the in-app camera
-
Running on Android (much rarer on web/iOS)
It’s generally considered a UX limitation rather than a bug, and the usual workarounds are restructuring the flow:
-
Save the parent record before opening child forms
-
Capture photos in a separate step or table
-
Avoid camera capture inside nested forms when possible
So it’s understandable you haven’t run into it before — it only bites when a few specific conditions line up.
1 Like
I’m guessing it happens when “Save images to gallery” is disabled? If so, I suppose the behavior makes sense: the app is explicitly configured to not keep the photos on the device, so the only option is to upload them immediately and discard them.
Disabling “Save images to gallery” does not control whether AppSheet forces a sync. That setting only affects whether the photo is copied to the device’s local gallery after capture. Even when it’s enabled, AppSheet still treats the image as a server-backed file.
What actually forces the sync is this chain of constraints:
When you take a photo, AppSheet must immediately assign it a stable storage path (Drive/OneDrive/etc.).
To do that, it needs a successful backend write, which requires a sync.
If the row doesn’t yet exist (common in nested forms), AppSheet can’t safely defer that write.
So the forced sync happens regardless of the gallery setting.
Why your intuition still makes sense
You’re thinking in terms of buffering: “If it’s not kept locally, it must be uploaded now.” That logic would be elegant, but AppSheet doesn’t implement a durable local image cache for unsaved rows. Instead, it prioritizes avoiding orphaned files and lost photos over preserving form state.
In other words:
-
AppSheet does not trust local storage for captured images tied to unsaved records.
-
The gallery toggle is cosmetic from a sync perspective.
-
The platform chooses immediate persistence over transactional UX.
The key determinant is row existence, not gallery behavior:
-
Existing row → photo can be attached with less disruption
-
Unsaved / nested row → sync is forced to anchor the file
So yes, the behavior does make sense—but for a more structural reason than the gallery setting. It’s AppSheet choosing data integrity over form continuity, and on Android that choice is especially brutal.
It’s just as you say Ruhan. As of now, the problem remains, so hopefully they take a look at this. Thank you very much for explaining the issue at hand.
You’re welcome, Thomas. I’m glad the explanation helped clarify what’s happening under the hood.
I agree with you. At this point it’s less about understanding the behavior and more about whether AppSheet should improve it. A mitigation like preserving form state across forced syncs, or deferring camera uploads until the parent row is committed, would remove a lot of friction without sacrificing data integrity.
For now, the only reliable option is architectural workarounds, but it’s completely reasonable to hope the AppSheet team revisits this, especially given how common nested forms and photo capture are in real apps.
Thanks for closing the loop and for helping bring visibility to the issue. That’s usually how these UX limitations eventually get addressed.
1 Like