In my latest update to Pedometer++ I had to remove the feature where you could badge your app’s icon with your current step count. In doing so I also removed one of the all time favorite hacks I’ve ever written. I felt that this deserved a little send off before it departs off into my Git history.

First, the back story. During the introduction of iOS 7 one of the random side effects of the wide reaching changes to the iOS user interface was that app icon badges started to get truncated whenever they got above 4 digits long.

This usually isn’t a problem since if you have more than (say) 10,000 unread emails you are likely long past caring about the precise number anymore. But for my little hack of using the badge to show specific counts this caused a problem.

At first, I thought I’d have to remove the feature in iOS 7, until one fateful afternoon (while taking a shower, of course) I had the insight that I might be able to work around this. My realization was that the numbers were getting truncated based on their displayed width and not their digit count. Thus a number with a lot of 1s in it would not get truncated because the 1s are so thin, whereas a number with a lot of 4s in it would be truncated because they render much wider.

So I then set out to alter the numbers that were displayed so that if I thought it would get truncated I would replace the least significant digits with 1s until it would no longer be truncated. After a bit of experimentation I found that I needed for a 5 digit number to contain at least two 1s in it in order to be assured that the number wouldn’t truncate. Usually, but not always, the first of these would be the leading digit since getting above 20,000 steps is quite a full day of walking.

Kind of awkwardly though, I realized that in order to achieve this I’d have to calculate how many 1s there were in the number. I poked a round a bit on the mathematical side of this but couldn’t work out a way to count how many 1s there were in a given number via mathematical means. There might be a way to do this, but I couldn’t find it.

So instead I figured that I could just write a really crude method using strings. I just cast the number to a string, then compared its length to a string where I replace all the 1 characters with the empty string. From here I could work out if I should change the last digit to a 1 (in the case of it already having another 1), or if I should replace the last two digits (if no other 1s are found).

Here is the final result:

I’ll be sad to see this little hack go. While it might sound a bit funny to have a favorite line of code, I think this was mine. I just loved how silly of a hack it was, but yet how effective it proved to be.

Though one small consolation for it being gone now is that I can publish it here and the world can see it for all of its silly goodness.

P.S. And yes, if you are wondering if I really did just have that inscrutable block of code entirely undocumented in the app…I did. I suppose that’s the blessing and curse of being an independent developer. 😇

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!