I'm currently developing a Connect IQ application that seems to push against nearly all of the platform’s limitations.
The app is a client for openHAB, a widely-used open-source home automation platform. Users configure what they want to see and control on the Garmin device via the openHAB server—ranging from a few devices to fully integrated smart homes.
Through this work, I've encountered several areas where the Connect IQ platform presents challenges for more complex applications.
1. Network Request Limits (-402 Error)
My app can hit the -402 request limit. While this is handled fairly well by the API, the behavior is not well documented and differs between the simulator and real devices.
2. Storage Limits
The documented storage limits appear inconsistent and do not reflect actual behavior. Storage.setValue() can store more data than expected, but this consumes significant memory—and if the memory limit is hit, the app crashes without warning. It’s difficult to guard against this.
3. Stack Size and Recursive Structures
When parsing complex or recursive JSON structures, I encounter stack overflows. While I’ve restructured parts of the code to use iterative processing, it comes with overhead. A modest increase in stack size—at least as an option—could be helpful for apps like mine.
4. Watchdog Limit Handling
The Watchdog limit is another frequent bottleneck. While I work around it using an asynchronous task queue, there's no visibility into the remaining execution budget. A system stat indicating remaining Watchdog time, along with a native task queue implementation in the SDK, would be extremely valuable.
5. Profiler Reliability
Accurate profiling is critical for performance tuning in larger apps, but the current profiler can mislabel or misreport entries—making it difficult to trust the results. I’ve encountered this personally, and others have reported similar issues.
Example issue: https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-profiler-inconsistency
6. Conclusion
As you can see, I’ve submitted several targeted suggestions and bug reports. The purpose of this post is to suggest looking at these issues more holistically.
It's completely understandable that wearables have limited resources compared to phones or tablets. But if CIQ is to support more capable and dynamic apps, then:
-
Limits should be clearly documented.
-
The SDK should provide tools and APIs that help developers handle these limits gracefully.
I'm not sure if supporting larger apps like mine aligns with Garmin’s vision for CIQ. But if it does, I believe there’s important work to be done to make that experience more robust and developer-friendly.
