I love Glide a lot as you know, but it’s the only platform I work in where everything I do in the backend is immediately reflected in the front end. Where wathever I do is live. To me the concept of draft / publish in as well structure as content would make Glide even better than it is now.
Out of genuine curiosity, do some of those other platforms have as much access to the database compared to Glide, or do they have databases that are much more robust and flexible and automatically adapt to DB changes? Or do they have multiple DB environments? I’m only speaking from my own personal experience at my job, where almost everything we do is homegrown. We rely very little on third party platforms or services.
I also think about google sheet based apps. If you start to add/edit/delete columns in a google sheet, that data is synced to glide and if the published app is using some of those columns, then it will break. I don’t know how you could sandbox changes like that. Especially with interactive apps where users are changing data all of the time.
Do you find it a strange wish? I think it is a logical one, no matter how complex the backend of the platform is. I dont have a clue how complex my iPhone is either.
But I dont want Gliders to have a negative impression, i started with saying ‘it would be nice to have’ 
A nice extra to a platform I love!
1 Like
Not at all, but you’re also not developing iOS or modifying the database that it uses to run the os 
. I’m just trying to point out the current limitations and the reasons why I think it’s complicated. I completely understand the wish to have the option and hope it happens some day as well. But, at the same time I also understand the complexities of working with different program versions and different database versions and trying to get everything to talk to each other nicely…along with the issues of updating database layouts while still maintaining the integrity of the existing data so it works with multiple program versions that may or may not be expecting different types of data. Backwards compatibility between code and data is a delicate process that takes planning. I think it gets complicated either way for those who are not familiar with database design and have direct access to modify a database like we do in glide
Mind you, I am looking at this from a developers point of view. If the program expects one thing, and the database has something else then there are problems. I’m used to code flat out not compiling if the database does not match, or pointing the compiled code to a different database that has a different layout, which causes run time errors. Maybe it’s in the works for some day, but I think it would require database versioning with multiple versions and backups of one database into multiple versions. Basically a complete restructureing of how Glide currently handles data.
It’s at least a step in the right direction and hopefully there are at least some checks to prevent people from making some database changes that affect published production apps.
2 Likes
And I am looking at this from a (no-code) users view 
2 Likes
I feel like I could find a bunch of user vs developer memes, but I’ll keep it to myself.
Yeah don’t start insulting me
1 Like
Hehe, I would never do that.
1 Like
Is there a minimum gap that should be there between 2 publishes? Meaning, I publish the App now and immediately after 2 mins I republish it, it is not getting republished. It is loading for a while. It is not saving it sometimes.
But, if I do after a long gap, it is working fine.
Are you sure it’s not being republished the second time? Sometimes the changes take a few minutes to push out to all devices. Whenever I make app changes, I usually force close the app once or twice and reopen it on my phone to force it to get the latest changes. If you don’t force close it, they will still get there eventually, but may take a few minutes.
1 Like
Thanks for the response. It is not about checking if it is pushed. It is not even getting published. It is loading continuously. The round loader inside PUBLISH keeps loading. It is not a big issue. I reload the page and I get it after few minutes. But it was just an observation.
1 Like
Ah, ok. Now I understand.
I am having same issue. I want to ask, this auto publishing is only for changes in the design correct? what about the app is already set to run certain functions based on timer. for example a certain button had been programmed to turn on at certain time (but this function had been publsihed)…will the action still be activated without auto publishing on?
1 Like
Just want to confirm that whatever has been programmed, like turning on button at certain time is fully functional with auto-publisher turned-off.
I think that if that button has been synced to the real app in the last time you published it then it will be visible.
Glide does not have the ability to run functions based on timers, so I’m not sure what you are referring to. The publishing control is only for the design of the app, and not the data. The data is always live — for example if you update data in your Google Sheet, it goes live right away.
4 Likes
On the same topic, please can someone elaborate on how the user is affected when a new version of the app is published - i will be deploying my first app to production next week and trying to understand the process, ie:
- 20 users install and us V1
- 2 weeks later we publish v2
- will the initial 20 users have to re-login? Or will their sessions stay active but will see the new features
Im also keen to understand things i shouldnt be doing, ie constraints i need to watch out for during versioning deployment and user rollout
Thanks alot
Ilse
They will see the new features when they next open the app. They do not need to log in again.
2 Likes