Game changer!


YES! This is a great addition. Thank you, AppSheet devs!

Curious, cause I just don’t know:

  1. Where might this feature be useful?

  2. Will a device ALWAYS get the same unique ID?

1 Like

There are currently only four allowed options:

five* :stuck_out_tongue_closed_eyes:

I just tested and got a different ID for each tab I tried. This may not be as useful as I thought. :frowning:
Hopefully the ID is at least persistent on mobile.


What do these IDs look like? I don’t have a chance in the next couple hours to look at it.

Yeah - definitely could be a game changer, although without proper documentation it’s hard to know what exactly is possible.

1 Like

I’ve used this expression a couple of times where my apps are used both over desktop and mobile, i.e:

Used for the same function:

context(“Host”)=“Device”,“Tap Below To:”,
context(“Host”)=“Browser”,“Click Below To:”)

Just looks better and give a more professional feel in my opinion.

I’m sure there are more valuable ways of using this expression but for now:
Thumbs up from me!

1 Like

I’m told:

It’s stored in the browser’s local storage at the domain level. It should be the same across multiple tabs in the same browser but will be different across different browsers. If they’re seeing a new one in each tab it would suggest their local storage isn’t being persisted. I think that would also be the case for the editor preview iframe.


if you have the “run in a browser” link in an iframe on your website it should still maintain the same ID provided that the browser allows iframe access to localstorage (it seems Safari doesn’t). But the preview pane in the editor is not loading the app data from local storage because it always syncs the latest

What I take from this is that it isn’t a reliable “device” identifier for browsers (CONTEXT("Host") = "Browser"), but might still be good (enough?) for mobile devices (CONTEXT("Host") = "Device").

1 Like

Hi Steve, @Steve

Thank you for addition of Context() to your perfect docs, appreciate for your works as usual.

I should test this with my hands to consider the practical use cases, but can I borrow your thoughts what sort of use case this expression will be found useful?

I reckon if the app is requiring sign-in or not is nothing to do with the expression to return the value.
So it should return the unique value to identify the users specific device associated ID number.

In that sense, we are able to capture those ID to get the id from non-sign-in requiring app, i.e. public apps? If so, I assumed we captures the ID when the user access to public app and then do a quick stat to count number of unique access to App by each different unique users, most precisely count by each unique device.


I just did a few more tests. CONTEXT("Device") does return the same ID for multiple tabs of the same browser but not when the app is run in the editor/emulator, iFrame, or in a private tab.

Yesterday I checked the emulator against another tab, but skipped checking two different tabs in full screen view. So it’s somewhat consistent under certain conditions, but I still see 3 different IDs under Chrome just by using the emulator or a private tab.

I haven’t tested yet, but I’m guessing that a mobile device will always have the same value when accessing via the app. But the user could always connect via the mobile browser, in a private tab, or iFrame.


If devices always have the same ID, then could we not use this as a security filter on applications that don’t require logins?

Then we could have an application not requiring login but still have device/user-specific data.

1 Like

Jonathon, I thought the same thing as you and is the reason why I asked the question.

Unfortunately, from what I am gathering, from session to session, the device ID may be different. Which means it couldn’t be used in Security Filter criteria.

This brings me back to my other question.

Again because I just don’t know, where could such a feature of a Device ID be useful?

1 Like



So, what I’m reading is, basically:
If CONTEXT(“Host”)=“Device”
then CONTEXT(“Device”)=A UUID that should not change, unless the user changes devices, even if the cache is cleared or app is uninstalled and reinstalled, correct? Or would those also reset the UUID?

1 Like

After reading Steve’s updated doc page, that is what I am understanding too. That does make more sense to me and does make it useful for Security Filters and such.

Though I wonder WHERE that UUID gets stored?

And I’d still like know when such a feature might be useful. I’m probably not seeing it because I don’t have that need yet. But if we knew how this might be used, it may spark app feature ideas in the rest of us. Anyone?

1 Like

Let’s say you have one device in a factory, you could set your app in a way that you are able to use it ony from that one device even you could login with another device.

1 Like

I can’t say for sure. I suspect the UUID on devices might change if the app data (not the cache) is cleared or the app is reinstalled, and may be different for different device users on multi-user devices. Would be something to test.

1 Like

Excellent. Then I believe I came up with (in my mind anyway) to use CONTEXT(“Device”) for multiple iPads that are stationary and logged into the same email account. Using CONTEXT(“Device”), I should be able to allow each iPad to maintain its own personal temporary “carts” or “wishlists”. Since I really only needed it for the user experience, and really didn’t want to create three unique email address which will never be used again.


I can indeed use it as such. And so far in my testing, the emulator UUID will persist at least as long as I keep it open during the day - even through saves and refreshes. Either way this proves my concept overall works AND everything is equally fast or faster now.

1 Like