• Replies 11 replies
  • Subscribers 20 subscribers
  • Views 640 views
  • Users 0 members are here
Options
Related

Feature Request: Updated Simulator

andrewM

We are living in 2026 right now, where we can do a lot of things programmatically. Garmin Simulator is quite behind and actually my biggest pain in development cycle.
I have time measured my bug fixing today. Out of 4 hours spent on development, 3.5 hours was spent to connecting the real watch back and forth to make sure my app actually works properly. (in simulator it always works).

The simulator just need a few tweaks to be WAY better:

1. Service or MCP to interact with simulator programmatically.

I want to automate tests, that actually do taps or button interactions, to do a lot of UI work. It is repetitive and time consuming to do by hand, and not everything can be covered via standard test suite. I want to make screenshots programmatically so i can know which tests have failed and where.

2. I want more options to run simulator from command line: I have an app that works with accelerometer and gyro and it needs a playback FIT file. I have to manually select it every time i run simulator. It is time consuming and distracting. Let me just run a simulator with a playable FIT file attached. With pre-selected languages. With pre-selected other parameters.

3. i want to see in simulator real device limitations. I have faced multiple times the app runs smoothly on simulator but it runs out of memory on older real hardware.

4. That's a nice bonus, but i want to be able to connect to a real Garmin device from the debugger wirelessly. Taking watch on and off constantly connecting to a computer back and forth to test the motion-related stuff is exhausting. I know it's not for every developer, but we are not only producing millions of watch faces.

5. I won't even mention BLE .requestBond() that is absent from simulator for quite a while now. BLE development is more than a pain.

C'mon, Garmin, you can do better! Or, open source simulator so we can code extra plugins ourselves.

  • If I could upvote this a million times I would do, but to be honest, I don't expect anything here. If only ONE thing could be fixed, please fix the BLE requestBond(). With the requirement of using BLE Secure for almost anything, being able to run the end to end flows in the simulator would be amazing. I am developing the (AFAIK) only GoPro remote control datafield and not having this means flying blind, baking in static data in the code to simulate the flows, etc. Very painful.

    /rant on : It's feels so strange to me that Garmin is not investing more in the developer tooling : having the Connect IQ store means that it's the only viable ecosystem for tech enthusiast athletes because it's the only one where you can be sure to see support for the latest peripherals, but it feels like they are actively fighting against the people who bring that value. /rant off

  • in reply to Sam Dumont

    Just a guess, but it could be the nordic HW used by the sim doesn't have the ability to handle requestBond. (we are talking pre 2019)  That could also be related to older Garmin devices also lacking support.  For my BLE apps, I just allow an open connection and am asked when I've found a new sensor - not every time.

  • in reply to jim_m_58

    Ok, in the 9.2.0 SDK (just released tody)

    Simulator Changes

    New Features

    • Add bonded connection support in the simulator.

  • in reply to jim_m_58

    ok, that one crossed off the list. Would love to see everything else though.

  • in reply to andrewM

    Looks like you need new FW for the nordic HW.  In "core topics" for BLE, there is:

  • I was about to say #4 gets my up vote but isn't that the point of Beta versions on the store? Apologies if i'm missing something

  • in reply to Tim

    Tim:

    No, actually. When you test something complex, you want to develop/test/iterate as fast as possible. If you build-upload (manually btw, there is no automation there as well), then wait till it rolls out, get some 1-star ratings in between because something is broken and users are impatient, it doesn't work, no matter you out "beta" there or not. You don't have a lot of debug info from store builds as well, unless you code some built in complicated debug/log harness that actually eats tons of memory and battery on the watch, leading to a very poor performance of the app.

  • in reply to andrewM

    With beta versions, you, and only you can see and install the app from the store.  And unlike sideloads, you can test out app settings and fitcontrib/user data.  And depending on what you are looking at, you can use println calls to help with debugging.

    Core Topics

    Just one of the tricks you learn with experience.

  • in reply to jim_m_58

    Yeah, it still doesn't fix manual uploads and reinstalls huge time overhead, does it? Or is there a way to automate this process?