Connect IQ watch face: Applying settings resets all user overrides to XML defaults on fēnix 8

Environment

• Device: Garmin fēnix 8, 47 mm

• Device firmware: 23.40

• Connect IQ target: fenix847mm

• Connect IQ SDK used to build the application: 9.2.0

• Mobile platform: iOS

• Connect IQ Store app for iOS: 2.50.1

• Garmin Connect Mobile version: Not recorded

• Application: Hybrid Grid WatchFace, development version 0.4.37

• Application UUID: 070ab1d7-c0a0-4d14-ae14-45e5fa3f552e

• Store listing identifier: cbf81a49-526d-48c1-8445-95f6a27b8033

• Diagnostic build: HG0437-C

Problem description

Applying a single setting to an active Connect IQ watch face sometimes causes its entire previously saved user configuration to be replaced by XML default values.

This is not merely a display or settings-reload issue. We have captured a verified, correct binary SET file immediately before a failed settings operation, a corresponding device diagnostic log, and the resulting SET file containing default values.

The failure is intermittent. The same diagnostic build has successfully applied a settings change on the same physical device, but a subsequent change failed.

Importantly, the failing SET file was valid, contained all 63 expected application properties, and had already been successfully read by the running watch face.

Steps to reproduce

1. Install and activate the attached diagnostic build HG0437-C on the fēnix 8.

2. Configure the watch face with:

   • O1: Current temperature (O11Output=18)

   • Left central slots: Moon in both slots (ZL1Output=3, ZL2Output=3)

   • Analog hands: Classic (HandStyle=0)

   • O2-1: Altimeter (O21Output=11)

3. Confirm that the watch face displays the configured values correctly.

4. Save a copy of GARMIN/Apps/SETTINGS/GAKH0018.SET for comparison.

5. While the watch face is active, open its settings using the Connect IQ mobile app.

6. Change only O2-1 from Altimeter (11) to Steps (12) and save the configuration.

7. Observe that the watch face unexpectedly reverts to default settings.

8. Collect GAKH0018.TXT and the resulting GAKH0018.SET.

The failure is intermittent, so these steps are not guaranteed to fail on every attempt. Both a successful and a failed transition have been captured with the same diagnostic build.

Expected behavior

Only O21Output changes from 11 to 12.

All other 62 properties retain their existing values, including the classic hands, the double-moon configuration and the temperature field. The new values remain persistent after a subsequent app restart.

If a native settings import fails, the previously valid user configuration should ideally remain intact, or the failure should be reported rather than silently replacing user settings with defaults.

Actual behavior

For the captured failure on October 29, 2026, at 04:26:29 UTC, the watch face received its onSettingsChanged() callback, but Application.Properties.getValue() already returned XML defaults for multiple unrelated properties.

The complete resulting configuration matches all 63 XML defaults, except for O32Output=5, an existing application bootstrap value for the steps chart.

The before and after SET files are each 1,765 bytes long. Both are valid, contain the same 63 root properties with correct types, and differ at exactly four bytes representing the four changed numeric values.

There are no missing properties, duplicate root keys or malformed data blocks.

The failed after-file is byte-for-byte identical to the after-file from an earlier, independently captured failure.

Relevant diagnostic log

The device log documents the sequence:

HG0437-C|START|t=1793247938|used=72376|free=54504|total=126880

[App initialization, layout, show and correct property reads]

HG0437-C|READ|O21Output|Number|11
HG0437-C|READ|HandStyle|Number|0

[Correct frame completed]

HG0437-C|SETTINGS.enter#1|t=1793247989|used=116256|free=10624|total=126880
HG0437-C|READ|HandStyle|Number|1
HG0437-C|EXISTING_WRITE|O32Output=5
HG0437-C|READ|ZL1Output|Number|0
HG0437-C|READ|O11Output|Number|1
HG0437-C|READ|O21Output|Number|9
HG0437-C|SETTINGS.return|t=1793247989|used=115224|free=11656|total=126880

The excerpt is abbreviated; the complete original log is available.

The first instrumented incorrect property read occurs before the existing O3 chart bootstrap write attempt. The callback subsequently completes, and the watch face renders using the unexpected values.

There is no recorded new application start between the last correct frame and the failing settings callback. Native settings import and persistence operations are not directly instrumented by this Monkey C diagnostic build.

Investigation already performed

• Verified the SET files using two independent decoders, including Garmin SDK 9.2.0's Serializer.deserialize(byte[]).

• Verified all 63 property definitions, values and types.

• Validated the settings XML against the SDK XSD.

• Checked the generated settings metadata for duplicate IDs, incorrect bindings, invalid option values and missing resource references.

• Compared the settings definitions across versions 0.4.36, 0.4.37 and diagnostic builds A/B/C.

• Verified that the 63 property definitions and defaults are unchanged between 0.4.36 and 0.4.37.

• Reviewed all production calls to Application.Properties.setValue(). None directly writes O21Output, HandStyle, ZL1Output or O11Output.

• Confirmed that the failed transition starts from a correct, flat SET structure without extra settings-group dictionaries.

• Confirmed that a previous settings change succeeded with the same diagnostic build and that its values survived a later application start.

The last hardware-proven stable application version was 0.4.36. Version 0.4.37 introduced additional weather outputs and runtime caching, increasing runtime resource use.

A diagnostic variant with weather processing disabled passed a limited settings test. Variants with active weather processing exhibited failures, although one settings update also succeeded with weather enabled. This is a correlation, not proof that the Weather API is defective.

Memory observations

The failing settings callback began with 10,624 bytes of application heap reported as free, out of 126,880 bytes.

A previously successful callback began with 10,976 bytes free.

These readings occur after the native settings import boundary. They do not measure temporary native memory requirements while receiving, allocating or replacing the settings data.

Increasing measured application heap headroom in an earlier diagnostic variant did not eliminate the failure.

Potentially related historical Garmin issue

An earlier Garmin developer discussion described a similar behavior where an application could fall back to default settings when loading its settings failed under memory pressure.

A Garmin Connect IQ developer confirmed that, in that historical implementation, the runtime could ignore the settings file and use defaults rather than terminate the application.

Reference:

https://forums.garmin.com/developer/connect-iq/f/discussion/7730/simulator-can-t-push-settings-to-data-field

We are not claiming that the same implementation or failure mechanism is present in fēnix 8 firmware 23.40. However, the observed default-value pattern makes this relevant to investigate.

Questions for the Connect IQ team

1. Can the native settings-import mechanism on firmware 23.40 fail to load or replace an active application's settings and fall back to XML defaults without a visible error?

2. Is temporary additional memory required while replacing a running application's existing settings table? Is there a documented safe memory margin for this operation?

3. Can Garmin determine whether the incoming mobile settings payload contained the requested O21Output=12 and preserved the other user overrides?

4. Does an internal allocation, deserialization or merge failure explain the observed defaults?

5. Under what circumstances could this fallback become persisted to the application's SET file?

6. Is there a diagnostic procedure or internal trace Garmin can use to distinguish a mobile payload issue from a native settings-import failure?

Reproduction evidence

A diagnostic package can be provided containing:

• The binary before and after SET files

• Complete device TXT logs

• SHA-256 manifest

• Full 63-property comparison

• Relevant settings XML and metadata

• The diagnostic build fingerprint

• Source code or a minimal reproducible sample as requested

We would appreciate guidance on the appropriate way to provide these artifacts, particularly if internal diagnostics are needed.

The primary issue is the unexpected replacement and persistence of a previously valid user configuration, not a failure to redraw the watch face.Garmin-CIQ-Settings-Reset-0437.zip