What are the proper steps to properly offboard an app from mobile device and custom app url? The app is still populating on devices and on the web.
Here is the scenario:
We deployed a temporary app with a custom URL that is no longer needed. We removed the app TXT and CNAME records from the domain provider and removed the custom app domain from the app in Glide. But the custom URL is still populating the app. Also, the app still loads on the mobile devices (with the custom url bookmarked).
Without deliberately telling users to remove the app, how do we get the app to stop functioning?
How long is it since you removed the DNS records, and do you recall what the TTL values were set at?
It sounds like it might be just DNS caching of the old records, which should stop once they expire.
eww… ok
hmm, in that case I’m not sure.
Does the app still have the (original) random hostname that was assigned by Glide?
If you change that, then in theory any bookmarks of the previous URL should start returning a 404.
The app when shared with users was set to the custom url. So when the users added their app to the mobile device it was from the custom url. Also, to access the app it was from the custom url.
With both the TXT and CNAME records being removed, the app still loads on the users mobile phones and also the url as well.
However, I do think it is a cache scenario because when I open the URL from a private browser, the site does not populate. But in this scenario, how do we get both the URL and app to un cache from the users devices and web?
Sorry, I’m stumped. Once you’ve removed the DNS records and any caching has expired (which it clearly has, if it’s been a week), then it should stop working. So I have no idea.
Hopefully someone else will be able to provide a clue.
Are you able to share the custom URL with us, I can dig around for you and locate the issue ? A few things :
Did you change the TTL to 1 hour if so what was it before then.
Highly unlikely that a DNS record is still cached after a week
Assuming this was being tested/used by users on different networks (locations on the internet) then they would be using different DNS cache servers. If the group of users are inside the same network then it could be the DNS server in that network.
If the problem is happening from a desktop, then go to command prompt ( CMD) and type in nslookup it will respond with a server IP of the DNS server that machine is looking at. Type in the custom domain URL and see if you get an IP address
Then type in “server 8.8.8.8” this will switch the DNS server for that command prompt session (temp) to point at 8.8.8.8 which is googles public DNS and then type in the URL again and see what you get
Thank you for your help. I cannot share the url unfortunately due to privacy. It appears that this issue is only impacting users who have had the app installed on their phone and or computer. New users and traffic are not led to the app page.
It was originally an hour by default
On both desktop installed app and mobile app the app still loads for users who originally installed the app.
This I’m not sure about.
It says “dns.google can’t find https://app.appurl.com/ (not actual url): non existent domain”
For example, the app still populates on the mobile device. The app also still populates when it was installed through google chrome onto a desktop. It does not populate when going to the url from a private browser or new traffic (someone who hasnt been to the url originally). But it still populates for those original users.
Without directly telling users to uninstall the app (which they may or may not do), how do I get the app shut down off of their devices (both phone and PC)?
Is data still synchronizing between the app and the server? Have you tried changing tab visibility or manipulating the data so nothing shows for the user? Is it a private/whitelisted app? Have you tried to change the underlying glide url for the app?
I’m sure it heavily cached, but I’m curious if it’s still fully functioning. There’s several ways to hide, change, or remove functionality from the app, but that’s only as long as synchronization is still happening.
As a last ditch effort, you could duplicate the app and delete the original.
I have changed the privacy of the app to allow only a single user sign in. It is a public pro app. I did try to change the underlying glide url for the app.
It doesn’t appear that it is functioning entirely, it basically goes to the login screen but when you go to login, it leads you to a blank screen. However, the splash screen still populates. If I remove the pro license, the landing screen then shows the a generic color (versus my background) and says made with Glide. So to some extent it’s still functioning.
I have not tried deleting the app. I could try that as well. I was hoping to find an alternative first but that is not off the table at this point. I love Glide apps and we are all making great apps for ourselves and clients but what are the proper steps to offload these apps when they are no longer needed? I feel a little uneasy just having these semi functioning apps just lingering out there in this weird state.
Ok… just tested something that is very interesting. Definitely a bug somewhere and unexpected behavior.
I created a NEW app and used the ORIGINAL URL from my old app but never removed the original app from mobile and PC. Here is what happened:
Online - On Chrome, the app switched over to the new app when loading a URL (that worked as I would expect it to work)
Desktop App - The original installed app on PC has the old app logo and name but switched over to the new app screen and build.
Mobile App - The original app on the phone still displays the original app icon and name. When loading, it glitched out for 5 seconds (switching between the original app spin wheel logo and the new app spin wheel logo) and then loaded the NEW app. When reopening the app after closing it, the landing screen shows the ORIGINAL app load picture but the NEW app login. Definitely a bug here.
So back to my original question, if an app is deleted or the custom url is removed, why does it still populate the app load screen? How do we remove an app to just stop working entirely when the app is no longer needed?
Here is what I would expect to happen when deleting or removing, cname/txt records for custom url. The app should ultimately not load on the mobile device and pc. However, it still does. Is this the intended behavior?
This seems like a local cache on the device and not a DNS issue. I think it is like an offline mode type of thing but I know Glide have not yet implemented offline. So when it can’t connect to the server (either because the DNS doesn’t resolve or if the other end doesn’t respond, then it uses its local cache/copy). Although you should not be able to use the functionality on it
I just tested in on my phone by switching of data and I can see the data, but I have a message saying “You are offline” “you can view this app, but not make changes”
Try something, on a mobile device switch off your data so it can’t connect and then fire up the app, is it behaving similar ?
If I were to guess, there is a basic shell of the app that’s cached or saved on the device, so that’s probably what’s opening and what stores basic items like the logo. The rest of the app is probably operating through underlying api calls between the app and and glide servers. So as I picture it, your custom url loads the shell of the app and then the app directly communicates with glide servers without using your custom url.
When you killed off that custom url, the shell is still cached or saved to the OS/Browser. The shell still has direct communication to glide, so if the app still exists in your account, then the cached/installed app can still communicate with glide. I would guess that glide updates the shell with the underlying glide url that’s needed to communicate with the server…so switching the original glide url to a new app would still allow the cached/installed app to communicate with something. The shell may be installed using old logos, but the rest of the internals download from the new app when you open it.
Still not an answer, but that’s how I view it. I don’t really know how the underlying structure to handle that communication and data transfer works. I would guess that changing the glide url would be enough once you’ve removed the custom domain, but I’m not sure. Definitely a unique situation that most people probably don’t run into.
That is a great explaination Jeff. I would agree with what you said.
Yes, definitely an odd case. But there will be others who will want to recycle the same url for multiple apps in the future and we should have some resolution to the weird app states throughout the course of applying the custom url to different apps.
Hi, Steven, I’m no expert, just former client-server admin. It must be a stupid question & hypothesis, but when you delete an app, are you 100% sure the Google Sheet attached is deleted as well? Or for some reason it’s still wandering as a ghost somewhere, and that’s why Glide still “refers” to it and can load it, the condition to load the app in the first place? Could it be possible the pb lays in the Google Sheet housekeeping best practice and not in Glide?
Okay… did some more testing on this. Here is what I learned…
User installs App A (public PRO) with custom URL
Custom URL is then removed from App A and applied to App B (Public Pro)
User with original App A installed on mobile phone, experiences a constant flickering. The new app fails to load (to App B). And the app name and logo from App A is kept on the home screen (not the new app name and logo from App B).
I will report back in the next day or so if this changes at all. But that is the behavior when you do this.
Even if your client deleted all stocked data (not the cache, it’s not enough, the stocked data), from its Android app options or iOS, Steven? That’s the usual way to refresh the icon (on Android at least). Or every Profile update like the Name, the picture. For me. It does not always even disconnect the user.
I don’t know if there’s a cool way to do this for the client, or remotely.
In other systems, what consumes a lot of UI to “display” often requires more than “refresh”. Hence my guess. Which is the case, the same pattern in low and no code, where we don’t “write” direct code.
I was reported a flickering (or latency) too on iOS but for contextual components (even text with simple Template column and if then else)