Earlier this year our customer tasked us with an exciting project: Let’s create a Home Connect app for Fitbit smartwatches. The goal: Home Connect users can monitor and control their home appliances like coffeemachines, washers or ovens from their wrists. Six weeks later we were proud to see it launch.
This was the first project on the Fitbit platform for us, so we learned quite a bit in the process. In this post I’ll try to convey five takeaways that might help anyone creating a Fitbit app. But first off some technical background for our application: To allow customers to interact with their home appliances we use the official Home Connect API. So we rely on an active internet connection on the users mobile phone, from which we forward the data to the watch. Any actions of the user would take the other way around.
To get started with the Fitbit SDK in general, the guide on dev.fitbit.com will set you up with the necessary background. If you’re interested in what code for the Fitbit SDK looks like, the collection of open source applications on Github is a good place to see what others built and how they did it.
1. Development Infrastructure is Key
While the Web IDE, Fitbit Studio, is nice to get things off the ground, it’s not really suited to work on the code as a team. With three developers on the project having all code tracked in a git repository is a must.
The Fitbit CLI can create a nice skeleton app locally and also supports building the app locally and run it directly on the device or in the simulator. So we were decoupled from the Web IDE and ready to go with our individual setups.
2. The Simulator
There is a simulator available from Fitbit to run the apps locally without the need for a device. It is a nice helper, especially because the cycles for building and deploying an application to the watch takes some time.
Having said that, the simulator is no replacement for testing on the actual device. As I mentioned, we rely on the interaction between the App and the Companion. While the lifecycle in the simulator for those two is always nice and in-sync, it is a different story on the actual device. Bluetooth connections might get interrupted, the Fitbit Smartphone App might be killed by the operating system (and thereby also the Companion) or the internet connection could drop.
So after the initial functionality for the application was done, we invested more time into such scenarios than we initially anticipated.
3. Keep an Eye on the Memory
It’s worth to early check for the memory pressure and to keep an eye on it. For example we started out with a strong focus on object orientation, modelling ovens and coffeemachines in the app. Additionally we evaluated the data coming from the API mostly on the watch. This caused the App to crash repeatedly because it ran out of memory.
On the one hand we tackled this problem by moving much of the heavy lifting to the Companion app on the smartphone and only sending the minimal necessary data to the watch App. On the other hand we also reduced the code size on the watch by simplifying our OOP code.
4. A Powerful UI
Initially we were a bit afraid that having a UI with over a hundred individual elements would cause performance issues. But in contrast to the memory limitations, we didn’t encounter such problems. Updating the contents of the SVG elements every few seconds, while a user navigates through the app, didn’t negatively impact the user experience in any noticeable way.
The UI library comes with a lot of helpful pre-defined widgets and also includes animation support. Nonetheless we had to manually animate elements as well. For example we manually draw a rectangle as the progressbar every second because the interpolation of the animations might cause some jitter otherwise. Also in this case we didn’t notice any performance hits.
5. Get Creative
Developing a Fitbit app brought some fresh challenges to our team. Every project needs us to find the right balance between the technical capabilities of the platform and the requirements from our customer. But this time the technical setup was quite different to building microservices or frontends. So this project allowed us to learn quite a bit about writing apps for such scenarios.
In the end you might have to get a little creative to accomplish your goals, like we did when building a Coffee Program Configurator by using settings to temporarily exchange data between the Settings screen and the Companion.
I hope this post gave you a better understanding for the current state of the Fitbit platform and its challenges to development teams. While the platform itself already provides plenty of possibilities, we are looking forward to seeing it mature.