Inevitable Sherlocking

This week I’ve been working on a big update to my Apple Watch sleep tracker, Sleep++. While I love the app, it is a bit funny to work on. I am pretty confident that somewhere deep within the Cupertino mothership, Apple is working on their own sleep tracking app for the Apple Watch.

That isn’t based on anything specific, other than common sense. If they weren’t, they’d be leaving a massive gap in their fitness/wellness offering. I suspect their ultimate offering will have more capabilities and operate better than anything I can do, just given how much more integrated into watchOS it could be. Which makes putting lots of effort into an app that any day could be competing against something better and permanently installed feel a bit hopeless.

I’ve had the feeling that one day Apple would introduce a sleep tracker ever since I began working on Sleep++ back in 2015. The question was always when, not if. Each successive update to watchOS I dive into the changelog to look for clues as to when this fateful day will finally arrive. I got especially worried in watchOS 3 when Apple introduced their “Bedtime” alarm feature to iOS 10’s alarm clock, but September came and went without anything more.

In a weird way I’ve just come to peace with this reality and grown to understand that this isn’t something that I should really fear. While the indefinite nature of its arrival certainly gives me a bit of unease, once I accepted that it was inevitable things got much simpler.

I approach development now with a slightly different perspective. My goal is to

  • (a) in the meantime be the best Apple Watch sleep tracker on the market and take advantage of this opportunity as best I can, and
  • (b) prepare for when they eventually arrive by making the real value of the app not tied solely to data collection.

The first part seems to be working so far. The app has nearly 650k downloads and I’d put it up against any other sleep tracker on the market. I suppose I’m just not letting the fact that someday I might get smooshed, detract from the potential that the time between today and someday contains.

The second part is far more interesting. Nearly all of the features I have in mind for the app have nothing to do with the data collection side of things. When Apple inevitably launches their offering it will certainly do a better job of tracking a user’s sleep and do it in a less invasive way than I ever could. The nature of watchOS is such that doing long running, background monitoring of a user’s motion is difficult as a third party, but I suspect straight forward for a first party app.

Given Apple’s track record with health and fitness data I can reasonably expect that whatever data they collect will be made available in the Health database, which Sleep++ could then switch over to using.

My goals now are to give Sleep++ tools for helping my users understand their sleep patterns and insights into how to potentially improve them—using my own data for now, but with future sources in mind.

I suppose the reason I thought writing this post would be helpful was to try and give a sense of how letting go of the fear of a big competitor can help you focus in on what you can uniquely do…and if I’m honest I wanted to put my expectations in writing now so that when that day eventually comes I can compare my expectations with the reality.

David Smith

Basic watchOS Analytics

It is no secret that I love analyzing statistics. Since 2013, I’ve maintained a statistics page for my Audiobooks app. This has provided me with countless insights into my customers and how I can best design my apps for their use. It also just makes some really pretty pictures:

Today I wanted to understand my Apple Watch users a bit better so I dug into the usage of my app Pedometer++.

It currently has around a 13% Apple Watch attachment rate amongst my users. I suspect this skews higher than the overall rate since Pedometer++ is a fitness app and the Apple Watch is a fitness tracker, but it provides a large enough sample size to give me useful insights.

These stats are based on active users of Pedometer++ and based on usage in early January, 2017.

watchOS Adoption

First off, I was curious to see what the adoption rate was of watchOS itself. The upgrade process for the Apple Watch is exceedingly cumbersome and long, so I was worried that lots of users would lag behind and not be running the latest versions.

It turns out quite the opposite. For my users essentially all of them are running watchOS 3.1.x (96%), which is fantastic for me as an Apple Watch developer.

Apple Watch Size

Next, I wanted to understand the distribution of sizes worn by my users. While supporting both sizes is an essential part of developing a watchOS app, it is still useful to have a sense for which size is more commonly used.

For my user base, the split somewhat favors the larger 42mm model (66%).

Apple Watch CPU

Lastly I wanted to get a sense of the split between the two possible CPU configurations. The first-gen Apple Watch featured a (rather slow) single core CPU, while the Series 1 and Series 2 have a (much faster) dual core CPU.

I was delighted when Apple elected to not keep selling the first-gen model when the newer ones were released, which I hoped would hasten the adoption of the speedier one.

That hope appears to have been largely realized. 43% of my users are running a dual CPU model. Since the first-gen was on sale for so much longer than the newer ones have been so far, I find this split quite promising. While I wish the dual cores were in the lead, I suspect they will soon overtake the single cores at this rate.

Apple Watch Models

While not particularly useful from a development perspective, I didn’t think I could finish this post without a chart showing the breakdown by types…just for interest sake.

If you find this post useful and haven’t already, please consider taking a look at my wide array of Apple Watch apps and seeing if one or more of them might be of use to you.

David Smith

Podcast Search - A Random Side Project

I have a knack for remembering audio. I’m awful at remembering names and faces, but if I hear something I can often recall it later. This has manifested itself as a bit of a party trick for the podcasts I listen to, where I can quickly find the section of a show where a topic was discussed even years after I heard it. Fun, but not particularly useful.

This situation gave me the idea for a little side project, Podcast Search, empowering the same quick podcast recall for anyone. The concept was simple. Take a few of my favorite podcasts and run them through automated speech-to-text and make the result searchable.

At first I wasn’t sure what to expect from fully automated speech recognition. The results are pretty comical:

(Original Audio)

The Incomparable, Number 324, January 2017. Welcome back everybody to The Incomparable, I’m your host Jason Snell. So Batman won a tournament that we ran here that was stupid, and we honor Batman by doing episodes about Batman.”


the incontrovertible numbers we January 2n474 welcome back everybody to be uncomfortable on your host Jason L we so bad man won the tournament that we ran here that was stupid and we wanted to have an amazing episode about that man

This is absolute gibberish.

But after playing with the output a bit I found that even though this is an awful transcription, it is actually pretty good for keyword searching. While the context is usually lost and words are sometimes wrong (“Batman” -> “that man”), it gets it correct enough to be useful.

I ran the resulting scripts through a handful of podcasts and have published the result on Podcast Search.

You can easily search for a term or keyword and then play the actual audio back to find if it was the section you were thinking about. I even tag the sections with timecoded Overcast links for easy sharing. It is very rough and a work in progress but surprisingly fun to play around with.


David Smith

Dev Notes for Workouts++ 1.0.1

I’ve decided to start writing up informal development notes for each of my significant app updates. My goal is to communicate with my customers about the thinking behind new features. I’ll also throw in a few little technical notes that are perhaps more interesting to the iOS developer community.

Workouts++ 1.0.1

So often when I ship a v1.0 of a new app I am doing it knowing full well that it isn’t perfect. I have found that it is usually more important to ship a solid, useful v1.0 and then start collecting feedback, than it is to agonize over perfection. It might be possible for a larger team to have enough internal discussion and critique to ship a ‘perfect’ v1.0 but for a solo developer that just hasn’t been my experience.

So when I shipped v1.0 on December 21 I knew I’d be turning around a quick update shortly thereafter. Both to add a feature as well as to fix all the little bugs that hadn’t shown up in testing.

The bugs fixed were:

  • It turned out that my method of detecting a user’s preferred units from the Health app didn’t work consistently on the Apple Watch, so I had to manually determine this on the iPhone and sync the setting over.
  • I had initially limited the range of heart rates configurable in the app to a max of 170bpm, but after hearing a lot of feedback from some distinctly impressive athletes this was bumped up to allow them to set their alerts and color thresholds how they needed them.
  • I added Strength, Yoga, Pilates and Functional training types to the available set of workout types. Apple allows for a rather extensive list of possible workout activity types, but to keep things manageable within the app I don’t want to include all of them. So I collected feedback from the initial wave of users to see where I was lacking.
  • The speed/pace calculation system was completely overhauled to avoid situations where the displayed speed would fluctuate wildly. These values aren’t provided directly by the Apple Watch. Instead, I have to derive them from the distance samples I get. The nuances about how often these samples are provided make getting a consistent speed output very tricky. The current mechanism is far more stable and tolerant of fluctuations in the old method. One of the big things I’m working on for v1.1 is location tracking, which will help me gain access to much more accurate avenues for collecting this data. So this is likely an interim fix for now.

The main feature of this update was the ability to Pause workouts. This was intended to be included in v1.0, but I had run into a last minute bug where it wouldn’t consistently update the display when paused so I had disabled the feature for launch.

Superficially pausing had seemed like a straightforward feature to add when I began working on it. But it turns out to be subtly tricky, and in the ways that tend to keep a programmer up at night. Clearly defining what it should do when paused was quite a conundrum for me. Should I keep updating the UI with your heart rate data as it comes in? If you move around while paused should I unpause, add the new distances, or ignore them? How should I handle active calories ‘earned’ while paused for the purposes of totals?

In the end I have initially chosen to take the conservative approach of displaying the data collected while paused, but not automatically resuming based on movement. In my own testing/usage I find that since you can resume with the physical motion of rotating the Crown backwards I have just added that into my muscle memory and rarely forget to resume.

Speaking of which, I reduced the sensitivity of the “rotate crown to end/pause” feature after getting reports that it was too sensitive and had accidentally triggered a few times. The absolute last thing I want to do is loose workout data, which unexpectedly ending a workout would be. Though on the positive side, this is probably the feature for which I have received the most positive feedback for. Turns out I wasn’t the only one annoyed with trying to use their Watch with sweaty fingers.

David Smith

Introducing Workouts++

A quick overview of Workouts++

Just in time for all your New Years Resolutions, I’m delighted to announce my newest app, Workouts++.

Workouts++ lets you completely customize your Apple Watch workouts to display whatever fitness data you’d like — from a 6 metric display packed with info to a focused single metric display. For each metric you can setup conditional coloring and haptic alerts to help keep you in the zone. You can even display graphs of your performance to help you understand how well your workout is going. My goal was to create the most customizable workout app possible for the Apple Watch.

The Apple Watch app then lets you use these custom workout screens during your workout, with your configured haptics keeping you on track.

I added a feature to the Apple Watch to help make ending your workout better when your fingers are wet or are wearing gloves. You can now do this solely using the Digital Crown.

Back on your iPhone once the workout is complete you can browse all the collected workouts in the Workouts area. This includes summary statistics as well as minute-by-minute graphs showing precisely your performance.

I started out making the perfect workout app for myself and I believe I ended up making the best workout app for the Apple Watch, period. I hope you’ll give it a try.

Workouts++ is typically going to be $4.99, but is on a 20% launch sale for $3.99 until January 2nd.

I made a walkthrough video below showing how the app works in practice to give you a better idea how best to use Workouts++.

A detailed walkthrough of Workouts++
David Smith