I just pushed out version 2.5.2 of Pedometer++. This includes a number of interesting updates that seemed worth expanding on.

Data Changing in the Past

One of the more insidiously difficult technical problems I’ve had to deal with for Pedometer++ is handing data from multiple sources. Pedometer++ has a mechanism for integrating your step data from an Apple Watch (explained in detail here). This feature generally works great but has exposed a number of difficult situations to navigate from the data processing side. The hardest deals with knowing when data reported from your iPhone to the app is actually new.

If you put your Apple Watch in airplane mode for a while then reconnect, Pedometer++ now has access to data that appears old in terms of date but is new in terms of Pedometer++’s data integration scheme.

So since the start of data merging I’ve had to look back at past history to detect when new data is available. The tricky part became knowing when that data is truly new.

My initial attempt at this worked correctly most of the time but would occasionally get fooled by either a bug in iOS (#27823135) or by a privacy feature in Core Motion. In either case users would see their old step counts slowly creeping up by a few steps a day.

In this update I’ve re-written the integration logic to now be robust against both of the previous areas for error. This involved keeping much closer record of exactly which steps have been counted and where they were counted from. The new method has so far been incredibly reliable in my testing regime. It will result in a one-time adjustment the first time the new algorithm is run, but after that should be much better.

New Icon

The original icon for Pedometer++ was something that I threw together myself in a hurry back when the app was first made. I felt it was high time for it to finally get a proper icon. The newly updated one was made by the incomparable @forgottentowel. He did a great job of keeping the original feel of the icon but making it much more clean and nice.

Alternate Icon

This update also makes use of the new in iOS 10.3 ability for apps to have alternative icons to provide a different icon for use when the app is in Wheelchair Mode. Since watchOS 3 introduced the ability of the Apple Watch to count a user’s wheelchair pushes Pedometer++ has had the ability to use these as an alternative to steps within the app.

When in this mode it seemed like having a more consistent icon made a lot more sense. I really like the resulting icon, I think it captures a great sense of movement.

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.

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.

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.”

became

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.

Enjoy!

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.