App updates

For apps added to the homescreen on iOS, what is the timeline for users receiving app changes?

Also, communicating to kill the app or re-add to homescreen seems fine, but is there a better way to force updates?

1 Like

See here: Updating your app & data

Summary of time it takes for changes to be seen in production (ie. in the live app):

  • Changes within app: seconds
  • Manual changes to data in sheet: up to 3 minutes
  • Automatic changes to data (some formulas in Google Sheets, 3rd party integrations):
    • Free apps: not until manual update
    • Pro apps: periodically in the background
  • Layout: up to 10 minutes (often quicker)
  • Published Google Sheets charts: up to 1h
  • App icon & splash screen: reinstall needed
4 Likes

this information is very disheartening
:stuck_out_tongue:

thanks for this detailed breakdown. layout in 10 minutes is not too bad.

Up to 10 minutes. Others might be able to confirm, in my experience it is most of the time much quicker than that.

So, I have done some testing and there is one big issue - I want users to install my app! And I think most of us want that! However, layout changes do NOT update on ANY installed apps until they force close and sign into the app again. This is inconsistent with the fact that they DO update within a couple of minutes when viewing on any device in a browser - and yes, I understand why but it’s a huge inconsistency that should be addressed, especially as getting app adoption is much easier with an installed app but right now I to tell my users to NOT install on desktop because I don’t want them to have delays on updates…lesser of the two problems sort of thing. @Jason or @Mark can you fix this - or at least when publishing control is released, please let it be that the “push/publish” is getting out to the installed apps at the same time as viewing in a browser?

The layout updates right away if you relaunch the app. We wait 10 minutes so that editing your app does not cause it to restart in your users’ hands.

1 Like

Right, totally understand that but it’s still a big problem because a LOT of people don’t relaunch their apps…like for days. :roll_eyes: That’s why we can’t rely on user behavior to deliver the updates. Does the sign-in session expire and if so at what duration into the session? Can you force a sign-out when we make a change once publishing control is introduced? Then, like most other apps, it’s on us not to publish at peak times.

1 Like

Why do you want to force a sign-out? Don’t you just want to force an update?

1 Like

I let you devs solve the problem in the best way possible - you have to forgive me if I use the wrong terms.

I want the updates to appear magically without disrupting the user - same as they do when viewing in the browser. I assume you can’t deliver the updates in the installed app without a relaunch/sign in. My understanding is that developers release updates during off hours and after they do, the user gets up and has to sign in even if they had the app running. I wouldn’t want to “force an update” while the user is using the app and then getting kicked off - That happens to me sometimes by the way. If you have a more magical solution, that would be even better! :grin:

Instant layout updates would be ideal, but what if you consider Instagram for example or any native app store app, there could be users several months and several versions behind on updates and there is nothing those large companies can do other than pre-bake in code to disable the app until the user updates and the versions match.

I don’t know, maybe it’s just me, but app updates within minutes to a few days is pretty good to me. I realize websites show updates instantly, but I assume when you install a PWA, there is some level of UI caching on the device itself. This is only my personal opinion, so I won’t be offended if anybody disagrees. I just feel that we are treating glide largely like a native app, so the bar for me is set for layout changes to migrate ‘at the same rate or better’ than a native app would.

Maybe if there would be a value we could set somewhere in the development environment (like a version number or something) that would pass to the app along the data stream, then if the version numbers didn’t match, it would force a restart of the app. I suppose too, if there some major data change, like a column removed, that would force the app to restart as well.

1 Like

I feel very strongly that since we are developing our apps, the same way Glide is developing their platform, we are making constant and important changes, developing features, etc. We want our updates delivered + the inconsistency between layout changes in browser vs. installed app is not okay. If we fix something, we need to deliver that change to all users at relatively the same time. It’s not just about the layouts in my case, was just using that as an example. Glide wants us to build businesses in our apps and Glide has enterprise customers - so I am hoping this resonates as use case for the Glide enterprise business too. If NASA is using Glide apps with their employees, I’m pretty sure they don’t want to wait for the employees to relaunch their apps to get updates. I am selling my app to companies/enterprise. We cannot rely on user behavior to deliver our changes.

I’m with you @Jeff_Hager, it’s just one opinion but for me this is critical! :grin:

1 Like

Hi @deena :wave:t2:

Are you sure that your app updates are not consistent with the update delays explained in this post?

In my experience, updates deploy immediately or within few minutes, and forced stops or reinstalls are not required (other than for the app icon and splash screen).

What do you mean by a difference in update delays between an “in-browser app” and an “installed app”?

1 Like

Hi @nathanaelb! Yes, I’m sure. That’s why I added to this thread. :blush: David has already confirmed that if you are in an app that you’ve “added to home screen” in your phone/tablet/desktop (installed app) vs. viewing in mobile browser, the app won’t update until you force close and relaunch. So if your users are leaving their apps running in the background…and a lot of people do this, it could be days before they get the changes… :upside_down_face: