Thank you for your response..
I also wanted to thank you for the many other responses, The uptick in correspondence from staff members has been refreshing and creating a hopeful outlook on the platform again….
4 Likes
I just wanna report that something has changed in the app behavior. I no longer see that error but now instead of this, there is a black screen that I cannot get out of. App crashes completely. Hope it helps somehow.
Glad to hear it! Regarding these Input form issues, the form height appears correct now in our apps. Can you confirm if you’re still seeing the input cut off due to inadequate height? If so we may need more information to reproduce the problem.
We were able to reproduce the ref search issue and are investigating now.
3 Likes
Crashing with a black screen isn’t a failure mode I’m familiar with, we would need more specific information to diagnose it. I would suggest to file a support request with relevant details.
Some questions that come to mind:
Do you see it crash in all contexts, or only with the new mobile framework enabled?
Does it happen immediately, intermittently, only after a certain interaction?
Does it still happen if you remove the markdown/html formatting?
3 Likes
@Adam-google Thank you for responding and looking into these small but important bugs.
It happens on mobile with a Pop Up Input form using [Input] that only has one field on it, on the editor and browser it is displaying fine.
There seems to be excessive padding above the Cancel Save buttons.
The mobile I had complaints on is 6.1 inch Huawei P30. So I’m not sure if perhaps it’s only affected on certain screen sizes, I hope this helps.
3 Likes
Thanks for the reply! Let me answer your questions:
Do you see it crash in all contexts, or only with the new mobile framework enabled?
Only with the new mobile framework enabled BUT only on android (I am using pixel 8a with android 14)
Does it happen immediately, intermittently, only after a certain interaction?
It happens whenever I try to open detail view where I used specific markdown formatting: ! [ ] ( )
Does it still happen if you remove the markdown/html formatting?
After removing this element: → ! [ ] ( ), it starts working fine
I recorded my screen, hope it helps!
Do you mean you have images embedded in the markdown and you’re just removing the details here, or that your markdown has this exact set of characters (empty brackets, empty parentheses)?
I’m not seeing this problem with either embedded images or empty brackets in my own app on Android with mobile framework enabled, so I’m not sure what to make of it.
3 Likes
Yes I embed images using standard markdown syntax:
Whenever I use above syntax and try to open detail view with markdown enabled in longtext field, the app crashes as showed on my previous gifs. I should be more precise and forgot I can type this in a code block here on the community. Sorry for the confusion.
Let me know what else I should prepare to help you reproduce this issue, please.
The group headers/title do not show when a group is clicked and expanded. It shows in other modes (the default and PC modes). Kindly fix. I really appreciate the efforts of the team. Thank you.
1 Like
This one has been fixed, it should be working now.
3 Likes
Thanks for the kind words. There is unfortunately a lot of variation now in what headers are shown or not shown with grouped/drilldown views in various contexts (top-level vs inline/in dashboard, new mobile vs old mobile vs desktop). Just to be sure I understand the request, can you include screenshots illustrating the problem (without personal info) and your grouping configuration?
2 Likes
Are these public urls? If it’s not sensitive info would you be able to share an example of a specific url that crashes? If you swap in some other public url, like some image from wikimedia commons, does that still crash as well? I’m not seeing any problem on my Android phone when using that kind of public image with this pattern.
I would suggest to create a support ticket where you can include private details like the account ID and name of the app and then let me know the case number, that would enable me to search our error logs for the specific app involved.
2 Likes
Yes those urls are public. When they are constructed like this, they work on both desktop and mobile:
https://media1.giphy.com/media/v1.Y2lkPTc5MGI3NjExdW5wcmlidmRkOTZyZDU2bWthcWZoM3lpZ2F5MG10ODExOTBxcTBtZyZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/dYTfJZ2dCQBhK/giphy.gif
When they are constructed like this, they do not work (at least on my device):
https://media3.giphy.com/media/Hc8PMCBjo9BXa/giphy.gif?cid=5a38a5a206606dkth1pi9rqfgk5n00b9223kw25ym171jwjr&ep=v1_gifs_search&rid=giphy.gif&ct=g
Both versions of the urls are taken from giphy website.
Hope it helps, and thanks for all your replies 
Thanks for those examples, I can see the issue now on my device as well. It’s something related to content security policy. It seems like it’s specifically the use of semicolons in the second url that’s triggering the error, if I remove the portion of the url after & I see the image starts showing up. I’m not sure whether those are embedding specific options that affect the image or just some kind of tracking info, but I would suggest to either trim that part off the urls if not needed, or use the other format.
2 Likes
Thanks for the reply. This is what I figured out as well yesterday. It works on iOS though. Still seems a bug to me but it is nothing urgent I guess. I really appreciate all your replies 
1 Like
Buenas,
Es un detail View, lo de arriba es un header en imagen que tiene armado esos cuadrantes mediante svgs. Si te sirve te pego como lo tengo configurado yo para que lo copies
I have a significant concern regarding the proposed removal of the sync with a blocking screen or “splash screen” in the new mobile framework preview.
We recently had to restrict a key application to mobile-only mode specifically to utilize this sync screen as a safeguard against data “roll back” issues we were experiencing in desktop/browser mode.
The Roll Back Issue in Desktop Mode
In our Purchase Order (PO) approval application, which uses a dynamic workflow for multi-level approvals, we observed the following behavior:
-
The Problem: Users in desktop/browser mode were not waiting for the application sync to complete before closing their browser.
-
The Effect: While the initial sync did process the approval and pushed the PO forward through subsequent levels (e.g., Levels 2, 3, 4, 5 to Completed), a later re-sync, upon the impatient user’s return to the application, would revert the record’s status back to an earlier stage (e.g., from Completed back to Level 2 approval) without warning.
Example: A Level 1 user approves a PO and quickly closes their browser. The AppSheet server processes the sync, and the PO completes the entire approval chain. A week later, when the Level 1 user returns, their re-sync causes the PO to mysteriously revert from ‘Completed’ back to ‘Level 2’ approval status.
Current Mitigation
We attempted various workarounds, including community-suggested force sync scripting, but none resolved the issue reliably.
The only effective solution was to:
-
Disable desktop access (mobile-only deployment).
-
Disable Delayed Sync.
-
Rely entirely on the mandatory sync splash screen to ensure users’ browsers/devices complete the upload and receive the server’s final confirmation before they can navigate away or close the app.
The removal of this mandatory sync screen could reintroduce a critical data integrity failure for us. Given that this sync “splash screen” is the only thing preventing significant data rollbacks in our workflow, I urge the AppSheet team to provide an alternative, reliable mechanism to ensure the entire sync process is complete and acknowledged by the user/device before data is considered finalized.