AppSheet's Achilles Heel

[Jordan_Davis1]

I've used AppSheet for about two years and have a few different private apps used by 30 users or less. 

Almost every time I upgrade an app I'll get a message from a user a few days later complaining about an error.  I've tried both types of upgrades i.e. Standard and New Major Version, however, they both lead to errors. 

Let's say I move the source of a table but the table and the structure don't change. If a user has unsynced changes and a standard upgrade is performed, this will lead to errors that they won't be aware of until they try to resync the app.  Many users leave their apps open to avoid having to wait for the app to load.  This means that all of their changes will end up leading to an error and the options for recovering the changes are pretty time-consuming. Alternatively, if I do a major upgrade and they have unsynced changes, all of those changes will be lost and they won't know it.   

Does anyone else have these issues?  Has anyone else found a good workaround?

[SkrOYC]

I have no help for you, just tell you that you are not alone.

I even had a case where I moved the database (worksheet in my case) to a different place and 1 of the users was on a two-month old version of my app. I couldn't get the recovery files either. Worst yet, each record requires an image and the user was on iOS, so the images are not on their gallery.

I had to take an exact copy of the worksheet that my user's app version expected and placed it on the location where the app expected the database and started syncing, so I got the fields and images.

So all of this is for you to know that you are not alone on this, that the way these maybe niche problems are handled is really bad.

For sure real no-coders won't have any idea how to recover those new records.

Fortunately, this is something that doesn't happend so often, but I can see this being even more harder for appsheet creators with lots of users.

Maybe this people can give you more comments.

@MultiTech @Aurelien @1minManager @Marc_Dillon 

[1minManager]

So a couple of things that I do to help with app updates and users on older versions of an App:

1 = If I'm sure I'm going to need more columns in a table later on, I'll create [Temp1], [Temp2]...[Temp5] in the spreadsheet.  So that later when I need them I just have to rename them, which doesn't affect the user.

2 = A way that I've used to detect when someone is on an older version of the App is to use an AppUpdates table.  This is a simple table of just [Date] and [Description] for the work I've done.  It started off really as a way to respond to clients who seem to not care what you've done in the App.  Until that is they receive the invoice...

Anyway.  What you can do is everytime the user creates a record in a table do something like MAX(Select(AppUpdates[Date],TRUE)) to get the latest update date that this user can see.  Then setup a Bot that compares this column in each newly added row with what it can see with the same MAX(Select(AppUpdates[Date],TRUE)) expression.  So if the later date is > than the earlier date, send that user a notification/email/SMS.

It not perfect, but it at least bugs the user to do something.  Where it falls down a bit it Appsheet will do a background sync of the data every 30mins.  So if they have the app open when this happens their version will have the latest data but not the latest version 😕

Some other quick points and requests to Appsheet:

• I've tried using CONCATENATE("AppName: ",CONTEXT("AppName")," Device:",CONTEXT("Device")," Host:",CONTEXT("Host"))  to get some useful data.  But all you can get is the device MAC address and whether its a device or a browser.  What we REALLY need is CONTEXT("Version").  Cannot understand why we don't have this.  Surely shoudl be an easy thing to add?
• I've had a couple of instances where someone doing daily timesheets managed to be constantly uploading data that was over a week old.  After investigation it turns out his phone was set to not allow Appsheet interenet access except when actually using the app.  So he was managing to go into the app, create a timeentry and then minimise the App before the App had chance to upload anything.  On the odd few occasions he spent more than 5secs creating a timesheet the app was able to upload at least some of the data.  So to fix this we really need a notification from the Appsheet App to the user if there are items waiting to be uploaded.
• Finally, the thing you've all been waiting for, we need a specific way of triggering a sync.  Such as, based on some formula.  Linked to the above something like CONTEXT("VersionDateTime") CONTEXT("LastSync") or would be really useful so that we could force the app to sync based on the version they had or the last time a full sync was done.

Simon@1minManager.com

[SkrOYC]

---

@1minManager wrote:

So if they have the app open when this happens their version will have the latest data but not the latest version 😕

---

EXACTLY!

Awesome feedback, thanks @1minManager 

One way I force sync is by sending a notification with a formula that forces sync, so the user taps the notification and the apps sync at start. This is because I also deactivated the "sync at start" option since my users complained about the time it take to just open the app. It was a life changer from UX pov, but you need to take care of the sync on more out-of-the-box ways

[Jordan_Davis1]

That's a really interesting idea. My users only access the apps via the browser so they wouldn't get the notifications but I like the idea. 

[Jordan_Davis1]

Thanks for sharing all of this.  My fear with implementing measures that require additional tables or virtual columns is that they add to the list of things to check when an error happens and they end up slowing the app down.  I'll never understand why this type of data can't be included in the analyzer records or the automation manager, both of which provide very little in the way of helpful information.  It seems that everything about appsheet is 'no-code' to the point that even True and False get's turned into Y and N to allow no-code users to understand everything.  However, everything related to monitoring is raw unintended json hahaha.  Why?

[Ryan_Mortimer]

What use case is there where changes remain un-scynced for more than an hour at a time?

From what I can tell, this would apply for any solution, not just specifically appsheet.

[Jordan_Davis1]

If a user makes a number of changes and then closes the browser window before the changes have synced.

[Joseph_Seddik]

Thank you all for your ideas.  

Personally though, I'm horrified by the idea that an app creator could make changes to the app outside a well-communicated managed released process agreed upon with the customer. There are established industry-standard change management guidelines that we, as IT professionals, should all follow. 

• Changes should be done at regular intervals.
• Implementation should be done at low-usage period, typically between 2AM to 4AM, preferably during the night of Saturday to Sunday.
• Several days before the implementation, notifications should be sent each day to app users by email, sms and app broadcast, reminding them about the coming change and what they need to do, for example: a deadline to sync their data. 
• Notification at the start of the change, announcing a freeze period, during which they should not enter new data in the app. 
• Notification at the end of the change, reminding users that they should perform a sync before entering new data. 

I strictly follow this process, to perform app changes. Additionally, if there's a major change that I could not finish implementing during the few-hours change window, and could not do incrementally, then I work on a separate copy of the app, making it ready, and then simply move the users to the new copy. This process also is made well known to the customer beforehand. 

Perhaps it just me, my strong humble belief is such problems are our fault as app creators not the tool's. 

[Jordan_Davis1]

Mmm... I don't believe that these measures are feasible or even possible in many scenarios.  There's a latency issue with the AppSheet pipeline that doesn't exist in any other scenario I can think of (Django CRM).  Although I appreciate that this is a compromise made in order to simplify the process of making an app, my issue is that there isn't an easy way for the user or the app creator to anticipate, identify, or resolve issues when they arise.  

I'd say more but I just got a notice from Instagram that I need to close the app for the evening while they perform updates.

[Joseph_Seddik]

I'm sorry I don't see the analogy between Django and AppSheet. In my view, that "latency" is not related to the AppSheet as a development environment, vs another development environment, rather it is related to a specific feature: the ability to run and work on the app offline. The compromise is not about simplifying app development, it is about being able to work offline. 

As for Instagram, I'd just forget about having read this line 😀

[MultiTech · Accepted solution]

This is a good topic for discussion: here's some of my thoughts.

[Joseph_Seddik]

Great video Matt! as always informative and very enjoyable to watch! thank you..

[Jordan_Davis1]

This is great.  Thank you for posting this, I really appreciate it!