That’s indeed what I’ve guessed. To let us keep the GS and just unlink it from Glide app. Like backups and copies of the GS, it’s really sth newbie’s should be aware of: so dangerous first time Glide erases all my 1st columns data to replace it with Row ID! 
. But you know how in IT files there is always a period when “something” like a root remains until several cycles in short time to replicate thoroughly (whatever your time zone) its deletion. To be sure its deletion is definitive and unrecoverable. To ensure its status as “deleted” is propagated everywhere, even if it’s supposed to be centralised on Glide’s “cloud”. 1 cloud, several servers?
And if it’s not, only 1 suffice to “regenerate” the missing file. Especially if the “survivor” has been abandoned somewhere after the period of declared deletion and suddenly sends its updates that are no longer accurate.
And as in the meantime, housekeeping has been done to remove also all roots, the file does not even know it’s deleted, so can reappear as… new.
Ohhhh!!! I think I remember. This stoped happening on its own after a while. Didn’t it?
No, I still get it from time to time. When I open the app, it gets into that flickering loop. Sometimes it will eventually open, but will take at least a minute. Other times I need to kill it and restart it.
But if you remember, it all started happening after we replaced the app with a backup copy, and re-used the same URL. I’ll be moving that app to a custom domain soon, it will be interesting to see what happens. 
Update: Original app is still flickering between app a and app b. I will keep you posted if this resolves itself in time.
But still looking for a solid resolution to shutting down an app. What I would like to happen is for the bookmarked app to simply not load. Not even a shell or load screen. Especially because the TXT and CNAME records have been removed. I need to figure out a solid offboarding process without having to tell users to uninstall manually.
I want to point out that I am currently testing a few different methods. I have installed a bunch of pro apps on my iphone and have since, deleted the app in glide (but left the apps installed on my phone) and used a different method for each app (from deleting the app, to changing the url, to connecting another app, to changing TXT and CNAME). Curious to see what happens in each case. I will report back once the dns changes have had time to settle a bit.
But I would like a response from Glide as to the suggested steps to offboard an app for users. Couldnt find it on their support page.
It did start after changing the url. It hasn’t happened to me after that at all. I guess it has to do with the cache.
So you think it would get stuck in the loop with a custom domain??
Yes, it does get stuck in the loop with a custom domain. I am experiencing it now. But only the original app that was installed has the loop. If a new user goes to the domain and installs the app after the app was applied to a new build, the loop doesnt happen. It only impacts the original app that is still installed on an original users device.
So, if the user deletes the app and install it again, this doesn’t happen??
It works fine. But the whole point is to not have the user have to do that.
I understand your point. So it seems it has something to do with the cache.
It’s definitely a cache scenario. But there is still some type of data fetching going on because if you actually remove the TXT and CNAME from a pro app and then downgrade the app a week later, you get the branding from Glide. So at somepoint in the load, it switched to show the Glide branding. So its not just a cache situation, Glide has a flow that is not fully shutting down the app.
It’s like there needs to be a way to uncache the app, especially if the app is deleted all together (cause as of now the app still loads in some weird state on devices that bookmarked the app, even if the app was deleted from the glide account). Im affraid to launch any more apps because I cant get them to go away when they need to go away 
Hi everyone,
Official response from Glide support relating the cache issues when deleting or reusing custom app url’s for different apps:
Hi,
Engineering has looked into the issue and believes they have found and fixed the problem you have reported. However, it still needs to go through further testing and may take a week or so for the fix to be deployed into production, where you will see the result. Thanks for your patience while this process is completed.
What’s your best practice, Darren, for replacing an app by a backup/new release?
-
you backup the existing one (just in case)
-
you publish the existing one with a new url Like “old*”
-
you publish the backup/new release reprising the exact existing app name (with also keeps the QR code)
-
you chose to delete or not the old one
Or?
Thks 
yes, more or less as you’ve described.
Although it’s pretty rare that I’ll replace a whole app - I think I’ve only done it a couple of times.
These days I work with auto-publishing disabled, and when I’m working on an app I try to publish small incremental changes, rather than one really big one.
If I am making really big changes, then yes I’ll always make a backup before I start.
I do make lots of backups, but I also delete old backups aggressively. I try to never keep more than 2 or 3 backups of the same app. I see backups as more of a security blanket than anything else - I rarely use them.
Well, I’ll open a separate topic on deployment strategy and continuous app development & features/ releases shippings.
As long as we cannot copy tabs or components from the dev app to the production app, I take my precautions not to disturb my 1st test users.
If the manual publishing really works as you say, then it’s a good way to be sure I’m not showing unfinished work. But I was really not confident of this publishing option.
Thks, Darren.
I’ve just noticed that auto-publish is the only option for Free Plan.
So, I have to work on a separate app until it’s OK. And repeat the work on the production app. Or for isolated stuffs, in a hidden tab that I call “Test Lab”. But it’s not ideal: you never know whether this “hidden” tab could accidentally be shown one bad day.
Hey @Steven,
Was support able to help iron everything out for you? I’m going through the same process…
No, not really.