Instinct 3 Solar has System.DeviceSettings.isTouchScreen in Simulator and on Device

Brilliant! Thank you! No way that I would have figured this out myself.

For example, if I build an app for fr955, the following file is created as part of the build output:

bin\gen\006-B4024-00\source\rez.mcgen

Here we can see that hasTouchScreen can be accessed as follows:

const hasTouchScreen = Rez.Styles.device_info.hasTouchScreen;

[3/3]

- you can easily open ...\ConnectIQ\ on your computer by opening the command palette in VS Code, selecting "Monkey C: Open Samples Folder", and navigating up 3 levels

- on windows, the location is %appdata%\garmin\connectiq

- on macos, the location is $HOME/"Library/Application Support/Garmin/ConnectIQ"

- each device has its own folder under the device library

- each device folder contains important device config files such compiler.json and simulator.json

- for devices which support the personality library, the corresponding device folder contains personality.mss

- personality.mss contains the property device_info.hasTouchScreen (true or false)

But how can I access this information at runtime, you might ask?

It would be great if this was documented, but it isn't. You have to successfully build an app for your CIQ 3.4 (or higher) device, and you'll see some auto-generated resource code which corresponds to personality style information.

[2/3]

What is the best practice to find out of a device has a touch-screen built in? (please don't say junglefiles)

If you can limit yourself to devices with CIQ 3.4 or higher, you can use the personality UI system, which provides a bunch of UI-related constants based on CSS-like style definitions for each device. See below for more details.

If you need to support older devices, then I guess you're stuck with using jungle files (or resources) with hardcoded values :/

--

Some background:

- the device library is installed alongside the SDKs under the ConnectIQ folder. The folder structure looks a little something like this:

...\ConnectIQ\
|
----- Devices\
|         |
|         ---- fr955\
|         |
|        ---- instinct3solar45mm\
|        |
|        ...
|
----- SDKs\
         |
         ----- connectiq-sdk-win-8.2.1-2025-06-19-f69b94140\
         |                                          |
         |                                          ---- samples\
         |                                          |
         |                                          ...
         |
         ----- connectiq-sdk-win-8.1.1-2025-03-27-66dae750f
         |
         ...

- note that the SDKs are versioned (and multiple versions can coexist), while the device library is unversioned (you're stuck with the latest version of the device files)

[1/3]

 I have I misunderstood how isTouchScreen is working. I've got the info from this post: https://forums.garmin.com/developer/connect-iq/f/discussion/229697/how-can-my-app-detect-if-the-watch-it-is-run-on-has-a-touchscreen and thought that's how to do it.

Yeah, that's because somebody keeps suggesting (or outright saying) that isTouchScreen determines whether a device has a touchscreen or not (both in the post from 5 years ago that you linked) and in this thread, even though they absolutely know better.

Today: "isTouchScreen by itself just means you can check if a device has a touch screen or not"

No, clearly that is not true.

5 years ago: "How can my app decide if the device it is run on has a touchscreen?" "System.getDeviceSettings().isTouchScreen"

Again, not true.

Like, technically these statements are "kinda true (but not really)" in the sense that if isTouchScreen is true, you know the device has a touchscreen. But these statements completely omit the nuance that a false value of isTouchScreen tells you nothing about whether the device has a touchscreen or not.

It would have been so easy to simply quote the docs here: isTouchScreen is "true if the device has a touch screen and it is enabled in settings, otherwise false"

Clearly Garmin's intent is that apps shouldn't have to care whether the device has a touchscreen or not, but simply whether the device has a (currently) enabled touchscreen. That doesn't mean it's ok to pretend that isTouchScreen is the answer to the question of "does my device have a touchscreen?" as opposed to the different question of "does my device have a touchscreen which is currently enabled?"

The problem is that some people like to oversimplify things to the point of making misleading or partially incorrect statements (which happen to be "kind of correct" for certain purposes, as long as you ignore the cases where the given statements are false or do not apply at all).

This isn't the first time it's happened, and I'm sure it will continue to happen over and over again. Sorry to say, but every time this kind of thing happens, I predict that someone will take an oversimplified, subtly incorrect statement at face value because it "sounds right", and as a result, they will waste time (or write bad code) because they got the wrong impression. I think this is a good example of exactly that.