Maintenance Mode

Just a simple check-box or switch from within the Glide Dashboard-Editor that when selected turns all screens and tabs within the accessible version of the app invisible and a message that says something like “We are doing some work on the app and will return shortly”… ideally a custom message.

This wouldn’t affect the editor dashboard for the app, and would therefore allow you to do major upgrades to your own app without any of your users using the app while you’re doing that sensitive work.

As of right now, I’m not sure how to do larger upgrades to my app and be sure that users wouldn’t see the changes in real time and perhaps experience broken functionality during that time. The only thing I can think of is making a copy of the app and doing the upgrades there. Then when finished, downgrade from Pro on the former version and upgrade to Pro on the upgraded version. But that would require every user to delete their former version and go through the entire process of adding the new version, signing in again with pin, etc.


I have not done this (I should) but could part of this be what you want?

Make a copy - do the major upgrades - then switch the names?

I wonder what happens to the ‘number of users’ counter. Will it start over again. This would be to nice if you are going to show your customer the one statistic that glide comes with

1 Like

I’m not sure the user would have to reinstall the app, as long as you transfer the url from the old app to the new app. I’ve never tried it though and I don’t know if it would force them to log in again.

Pretty sure it would at least force a new log-in. But regardless, the complication of switching the url from one app to the other would be a pain. In my case, I’m using a custom url, which means logging into my domain dashboard to do that change. And still not convinced it would be a seamless process for the user.

@spencersRus yeah, I saw that post from @George_B, and I do practice that method. But that seems more like an emergency method until Glide has its own proper backup system. Maintenance Mode is really just about making the current app downloaded and being used on people’s phones inaccessible for a short time with a custom message to users about what’s going on and when they should expect things to return to normal. Could be erected for even the smallest tweaks to the app where you don’t want to risk a function breaking in front of your users, if even for 30 seconds.

1 Like

It would be a pain, but you could put a Single Value column in each sheet of the data tab that does a lookup to a maintenance sheet. The value could just be a True/False Maintenance Mode value. Then use that value to control visibility on each component. It’s not a great global solution…Now that I think about it more, then you wouldn’t be able to make updates because all of the components would be hidden in the builder as well.

1 Like

Yeah aside from the fact that, as you point out, everything would be invisible, even for the admin/dev needing to do the work, such a solution (even if there was a visibility option like IF SIGNED-IN USER IS {SPECIFIED EMAIL ADDRESS} to avoid it affecting that one user) would be a huge undertaking. My current app is so heavy with components, putting such a visibility condition on every one of them would be unthinkably tedious… especially considering that a true Maintenance Mode feature might one day come and all that work would have been for nothing.

1 Like

What we really need is a way for you to make a draft of your app, and then publish it when you’re ready. With this be just as useful?


Drafts would be amazing and very useful, @david. But I think it’s a different thing from a proper maintenance mode. In the time I’ve been using the app, you have released two features that my app needed. Both times I had to go through the app and find all the spots where I wanted to use that new feature. And in some cases, I had to remove some old clunky work around methods I was using before the features were added. My app is still technically in draft mode, so this isn’t a big deal. But I will be publishing it soon and after I do, I’m expecting the Glide team will introduce lots of new features over the coming months that will benefit my app. At that point, I can’t exactly revert my app to draft. I’ll want to add those new features and I’ll likely have to remove old methods I was using as work arounds. That could take many hours to do, during which time, my users will likely see all kinds of weirdness inside the app.

1 Like

With apps on apps stores like Google Play and iOS App Store, the dev submits new versions of the app and the user seamlessly upgrades when the new app version is avail. So the user never has a weird experience. I wonder if there is a Glide version of that same method for developers to revise their apps behind the scenes and only push them out to users when they are ready… something that doesn’t require much work for the user (with App Stores upgrading apps is seamless). I just suggest maintenance mode as one suggestion, but perhaps there is another solution more in line with your longer term vision for Glide.

I’m just dreading doing any revisions to my app in the coming months after I have officially released it… yet I’m sure there will be new features coming that I’ll want to add to it.


Sorry, I meant that you would create a draft of a new version of your app, while your users simultaneously use the previous version of your app, until you publish the draft, replacing the previous published version and updating your users’ app version. This is exactly how App Store apps behave, as you described.

One difficulty is what to do with your sheet.


Yep. If you are able to provide a solution like this, @david, you will solve it in perhaps the best possible way.

As for the sheet, it would need to be a duplicate of the original sheet and when you replace your original Glide app with the new Glide draft, it also rewrites every cell of data in the old sheet with the data in the new duplicated/revised sheet.

What if your users add or edit items in your app while you are working on a draft/copy of the sheet? What would you expect to happen when you publish the next version of your app?

Good point.

The way I’d do it is this:

  1. place a parameter on all form buttons in my app attached to a maintenance/upgrade column in each sheet associated with that form button… all of those columns would switch to TRUE/FALSE based on a master cell in an Admin sheet. It’d have that master cell set to FALSE and so all of those columns in the other sheets would be FALSE as well causing their form buttons in my app to be visible and usable,

  2. duplicate app and sheet and begin working on that new app while my users continue using the original app like normal.

  3. make an announcement to my users that content uploading will be disabled for an hour “while we upgrade your app to the new awesome version”

  4. click the master cell in the Admin sheet to TRUE, causing that maintenance/upgrade column in all sheets that take in data from forms to switch to TRUE. Then I’d wait about an hour to make sure everyone’s app has pulled that change to the sheet which would turn all their form buttons invisible.

  5. (manual part—tough but not super hard) I would manually migrate (copy/paste) all data from old sheet that was put in using forms into the new sheet. Voila! My new sheet is now up to date in terms of user content!

  6. I’d do the officially upgrade and replacement of old Glide app and sheet with new Glide app and sheet.

  7. I’d switch the master maintenance/upgrade cell back to FALSE. Let everyone know the upgrades are done and to refresh their apps by closing them out and opening them again if they don’t see the changes yet.

Several steps, but pretty straightforward.

1 Like

I think maintaining the integrity of the database is always going to be an issue with major code changes. Where I work, we have different environments for development, testing, and production, so code and database layout changes move together between environments. For production releases, we have the users stay off the system. If they stay on, it’s at their own risk of being booted or having data lost. Usually the database is pretty set in stone, so changes to the database are few and far between and most tables are unique to a single year. As for Glide, the Google sheet would always be considered as production data. I would probably consider duplicating any data columns that would have substantial changes, or duplicate individual sheets as needed. When working on a draft version of a glide app, components could be converted over to the new columns/sheets. When moving a draft app to production, there may be some minor data migration, or in the case on duplicated columns, they could both function in sync until you feel comfortable that all users have the updated version of the app. At that time you could start to delete the old columns. There’s a bit of pre-planning involved, but it would keep the process seamless to the user. I imagine Google and IOS apps are even worse to deal with, because there is no guarantee of when or if the user will update there version of the app. Of course, there’s probably a lot more API and JSON involved in installed apps, which makes it easier to maintain compatibility between different app versions.


Hi @John_Cabrera thanks for the solutions! Do you think you can share a video on how to do it?

1 Like