Data Field: AppBuilder

any hope for Edge 850 please?

+1

I ended up treating the lack of AppBuilder updates for the newer Garmins as an opportunity to teach myself how to write my own ConnectIQ apps.  No regrets.

Good afternoon.

I love using AppBuilder CIQ fields for functionality not provided by Garmin (how is it STILL not possible to view distance based on time...). Would there be a possibility of seeing AppBuilder5+ for the Fenix 7 series? The 2 CIQ fields limitation is really bizzare, but we have to work with what Garmin gives us, and the + version handily deals with this limitation.

Thank you for all your work!

J

PS: Please excuse my English, it isn'tmy 1st language.

Hi, flowstate.

First of all, thanks for AppBuilder 5+ — it's an incredibly useful tool.

I'd like to report a reproducible crash with the UserHRZone2Max variable (and possibly the whole UserHRZoneXMax family), and ask if you have any insight into what might be causing it.

· DEVICE: Garmin Fenix 6 Pro Sapphyre
· APP: AppBuilder 5+

· CONTEXT: My HR zones are calculated automatically by Garmin based on % of lactate threshold (not % of max HR). I confirmed this by inspecting the FIT file's zones_target message, which shows hr_calc_type: 3. All 5 zones display real, non-null numeric values on the watch itself (Settings > User Profile > Heart Rate > Zones).

· GOAL: I wanted to use UserHRZone2Max instead of a hardcoded BPM threshold so that my "time in effort zone" field would automatically stay accurate as my fitness improves and Garmin recalculates my zones over time — rather than having to manually update a fixed number every few weeks.

· WHAT I TRIED (in order):

1. This formula crashed the entire data screen (blank screen, small "IQ!" icon, no fields displayed at all):
   setv(6, if(hr gte UserHRZone2Max, 1, 0)); recordsummary(sum(getv(6))); record(getv(6))
2. I suspected the casing might matter (lowercase "userHRZone2Max" vs. the documented "UserHRZone2Max"), so I corrected the casing and also added a null-guard, in case the zone value was somehow returning null despite being visible on the watch:
   setv(6, if(UserHRZone2Max eq null, 0, if(hr gte UserHRZone2Max, 1, 0))); recordsummary(sum(getv(6))); record(getv(6))
   Still crashed with the same "IQ!" icon.
3. To isolate the problem, I tested with ONLY the bare variable reference, nothing else:
   UserHRZone2Max
   This alone also produced the "IQ!" crash.
4. I confirmed via FIT file analysis (checking field_description messages) that when this field crashes, it never even gets registered as a developer field in the FIT — not even with a null value. It's a total failure from the very first second of the activity, not a gradual memory issue.
5. As a workaround, I replaced the variable with a hardcoded BPM value (e.g., "hr gte 125") and it works perfectly — records correctly every second with no crash. This strongly suggests the issue is specific to reading the UserHRZone2Max variable itself under this zone configuration, not a general memory/complexity problem with the formula.

· QUESTION: Have you seen this before with HR zones calculated via % lactate threshold rather than % max HR? Is there a known incompatibility, or something specific about how AppBuilder reads zone boundaries from the Connect IQ SDK that might behave differently depending on hr_calc_type? I'm happy to run any additional test formulas if that would help you reproduce/debug it — I have FIT files from each test above and can share them if useful.

Thanks again for maintaining this app — happy to provide any more detail you might need.

Best,

joserogo

Hi,

I've been building a set of 4 AppBuilder 5+ clones (2 screens active per activity, 6 fields each = 12 fields simultaneously) on a Fenix 6 Pro Sapphire, and ran into a crash pattern I can't fully explain, so I wanted to ask if this rings a bell.

SUMMARY (without getting into formula specifics): One of my screens uses 6 fields, most of them built around comparing elapsed timer values with a "mod" operation to detect repeating time-based phases within a workout. With 5 of those 6 fields active (4 of them using "mod"), everything loads and records fine. As soon as I activate a 6th field that also uses "mod" (even a very simple one-line formula, functionally almost identical to ones already working), the whole screen fails to load (blank screen, small "IQ!" crash icon). If I simplify that same 6th field to avoid "mod" entirely (using a plain time-range comparison instead), everything loads fine with all 6 active.

My other 3 screens (also 6 fields each, using more standard aggregate functions like avg/max/sum, setv/getv, prevn, etc., but none or at most one "mod") have never had this problem.

QUESTION: Is there a known practical limit on how many "mod" (or similarly "heavier") operations can run simultaneously across the 6 fields of one screen, beyond the general memory guidance already in your docs? Or is this more likely to be a cumulative processing-time issue (too many fields each doing non-trivial per-second math) rather than something specific to "mod"? Any rule of thumb on what tends to push a screen over the edge on a Fenix 6 Pro Sapphire would be really helpful, so I stop guessing by trial and error.

Thanks again.

Best,

joserogo