The thing I was most excited about during yesterday’s Apple Event was the addition of LTE to the Apple Watch. While the new iPhones are great, and a 4K Apple TV is useful, I see this new capability on the Apple Watch as being potentially transformative to how I use technology on a daily basis.

While I’ll have to live with it for a few weeks to see if it really pans out, imagining a future where my iPhone is no longer a ‘must carry’ device is remarkable.

The more, however, I think about this prospective future the more I think I’ll have to fundamentally change the way I consider and approach the development of my own Apple Watch apps.

Even though watchOS is only three years old we’ve already seen it grow from a hyper dependent toddler (WatchKit 1), to a slightly more independent adolescent (watchOS 2/3/4), to now suddenly a college student heading out of the home for the first time on its own. Asserting its independence while still holding on to a bit of a parental safety net.

Each evolution of the Apple Watch platform has made it less and less dependent on its parent iPhone. The addition of LTE takes all of this quite abruptly to another level.

I am now thinking about my watchOS apps as though they must be able to fully function out on their own with only minimal help and supervision from their iPhone. If they don’t, I suspect I’ll find them to be quite frustrating.

While previously there have been technical capabilities where watchOS apps could connect to external services without their iPhone present, the expectation I think has always been that this would be rare and unusual. Now it may very well be common and expected.

Practically I see this impacting my own apps in a few ways. These are mostly speculative at this point, so after living with an LTE watch for a few weeks they may change but I think these are going to be important considerations for watchOS developers moving forward.

Sync

Firstly, I’m going to need to do some management of application state and data via a web service rather than relying solely on the direct connection between the Apple Watch and iPhone.

I can imagine a situation where I configure a workout in Workouts++ and then immediately head out for a run. In this case if for some reason the new workout configuration hadn’t yet synced to the Apple Watch (via WatchConnectivity), right now the user would just be stuck. However, with LTE they would have a reasonable expectation that this new data would just be loaded over their cellular connection.

So I’m going to have to work through how to create a seamless experience for syncing application state between the Apple Watch and iPhone, where they are treated more like peers.

Application Dead-ends

Secondarily, while Apple Watch apps will still need to be simple and concise, I think I will need to make sure that there are very few ‘dead-ends’ where I’d currently punt the user to their iPhone to complete an action or do some setup.

These escape hatches were a great way to keep watchOS apps dead simple, but never really were particularly elegant. But in a world where the Apple Watch may be used for extended periods without being next to its iPhone they could become infuriating.

As an example, I’m thinking that for Workouts++ I may want to add the ability to do some very basic workout configuration on the Apple Watch, so that you aren’t stuck if you decide to do an activity you haven’t previously setup on your iPhone while you are out.

I’ll have to be extremely careful to not make the app overly complex as a result, but I’ll be on the lookout for these ‘dead-end’ spots.

New Opportunities

Lastly, I’m going to look for opportunities for what type of watchOS apps might now be possible with a persistent connection. In much the way that having an always internet connected iPhone opened a wide range of completely new use cases, I suspect a similar thing will be made possible on the Apple Watch. Some uses may be limited by the form factor of the Apple Watch but I suspect that a bit of creativity should allow many to become possible.

As someone who has been making apps for the Apple Watch from the beginning this new hardware addition has be more excited than ever for the platform.

Today I’m delighted to announce Pedometer++ 3.0. I’ve been steadily working on Pedometer++ now for nearly four years. Over that time the core conceit of the app has remained the same, to motivate you to be more active. It has done this with colors, confetti, complications and streaks. Now I’ve added another tool to hopefully motivate, achievements!

Achievements

You can now earn badges within the app for the reaching certain milestones. These include:

• The biggest number of steps you have taken in a day
• The longest streaks you have been able to reach
• Your lifetime steps taken
• Your lifetime floors climbed
• Special badges for meeting certain criteria

I hope to add several more of these categories over time based on the feedback this initial set receives.

The sweet artwork for the badges was done by excellent Louie and Alexa over at Parakeet.

Widget

With iOS 11 just around the corner there is increasingly an emphasis on the use of widgets in iOS. So this update also updates the widget Pedometer++ provides to be more capable by adding a daily detail view of your steps each day.

Enjoy!

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.