The change Amy mentioned would apply to initial app load such as from a link, as in Rifad's case. It's about trying to show the correct platform sooner to avoid seeing two different startup UIs, I'm not sure if it will affect the app switch from one platform to another though. At best it would only affect what you see after the refresh is triggered.
@QREW_Cam wrote:
The reason why we switched appB from desktop mode to a legacy mode is because when you use LINKTO_____ to a desktop mode app it loads the users last cached app version, causing an issue where users were opening old versions of the app.
The solution to our primary issue is:
when AppSheet loads the destination appB (in desktop mode) it auto initiates an update to the current version.
I see, yes this is intended to "just work" if you have Automatic Updates enabled (syncs in the background) and it shouldn't be necessary to include the "at" parameter to force a sync unless you specifically want to force the full screen sync UI (although this might be a good case for that if the sync is supposed to populate the form view).
But when a form view is open (or other sorts of data changes in progress) the sync is somewhat defensive about trying to avoid wiping out local changes in progress. Basically once a user starts filling out the form, the sync becomes deferred until the form is saved or canceled. In this case it looks like there is a "false positive" happening in Desktop where the data changes initiated by the form opening are incorrectly blocking the sync (incorrectly because the user hasn't actually interacted with the form yet). This is something we'll need to fix on our end, but I think we can do that easily enough.
BTW appending "&platform=legacy" to the deep link isn't doing what you want, it's treated as part of the "at" value and causing it not to be interpreted correctly - I would just take that out.
LinkedIn
Twitter
