opening settings editor consumes app memory

"Regarding the slightly off topic.... imho they should give the developer the choice to not use resource strings for app settings and allow to just hardcode strings, that would solve so many issues..."

That would be another solution. I'm guessing the reason that app settings and fit contributor strings are resources as opposed to hardcoded strings is so they can be localized. I still don't see anything preventing Garmin from having a *separate* resource section that's only for (off-device) app settings strings and FIT contributor strings. The app literally does not need those strings on the device, especially for old watches which do not support on-device settings (which would also benefit the most from this change.)

Just have a new resource qualifier: e.g. "resource-offdevice" (but ofc with a much better name.) Only strings are allowed, and everything in this section gets sent to the store but not the device.

Afaict, this is one of the few architectural changes that Garmin could make which could potentially benefit all devices, no matter how old, since it doesn't seem to require any firmware updates.

I have a data field app which has a theme color setting - on devices with 64 KB and more, it's a dropdown, as you'd expect. But this consumes precious memory due to the string resources used for the enum values. So for devices with 32 KB and less, I ask the user to enter a CSS color code that they have to look up the docs. This is the kind of embarrassing workaround I would love to avoid.

"Regarding the slightly off topic.... imho they should give the developer the choice to not use resource strings for app settings and allow to just hardcode strings, that would solve so many issues..."

That would be another solution. I'm guessing the reason that app settings and fit contributor strings are resources as opposed to hardcoded strings is so they can be localized. I still don't see anything preventing Garmin from having a *separate* resource section that's only for (off-device) app settings strings and FIT contributor strings. The app literally does not need those strings on the device, especially for old watches which do not support on-device settings (which would also benefit the most from this change.)

Just have a new resource qualifier: e.g. "resource-offdevice" (but ofc with a much better name.) Only strings are allowed, and everything in this section gets sent to the store but not the device.

Afaict, this is one of the few architectural changes that Garmin could make which could potentially benefit all devices, no matter how old, since it doesn't seem to require any firmware updates.

I have a data field app which has a theme color setting - on devices with 64 KB and more, it's a dropdown, as you'd expect. But this consumes precious memory due to the string resources used for the enum values. So for devices with 32 KB and less, I ask the user to enter a CSS color code that they have to look up the docs. This is the kind of embarrassing workaround I would love to avoid.