I have major updates to Pedometer++, Sleep++ and Activity++ ready to take advantage of the new features and capabilities of iOS 10 and watchOS 3.

Pedometer++

• I’ve added support for the new wheelchair mode to Pedometer++. When enabled the app will change to using the new Wheelchair Pushes metric rather than steps. I’m simply delighted to open up the app to a new wider audience of users.

• I’ve added the ability to share your daily step count and goal progress right from iMessage. Perfect for bragging about that amazing hike you just went on or commiserating about being stuck inside a beautiful day.

• I’ve also overhauled the refresh system for the Apple Watch, both on the watch face itself (when added as a complication) and while doing a walking workout. Both should now be massively more response and timely.

Sleep++

• Sleep++ has been updated to take advantage of the new Background Refresh mechanism in watchOS 3. Now rather than performing all of the sleep analysis in the morning when you wake up, instead it is able to analyze your night while you are sleeping. So when you wake up only the last few minutes of the night need to be processed. The end result of this is that you should barely see the Analyzing Night progress dialog any more.

• Sleep++ has also been updated to integrate with iMessage. You can now send a snapshot of your last night right from within the Messages app. This lets you quickly and easily share just how good (or bad 😳) your night was.

Activity++

• Activity++ has been improved to make the complications shown the watch update in near real-time now. Previously there could be considerable delays in how often they would update. In this version they should typically be within a few minutes of current.

• Additionally, I’ve also added the ability to export your activity data as a CSV file. Just in case you (like me) enjoy making charts and graphs.

Starting tomorrow Apple will start enforcing a new rule limiting the length of an app’s name to 50 characters. Additionally, they will start disallowing apps from including “terms or descriptions that are not the name of the app”.

The latter of these rules is probably the most actually impactful and important in terms of cleaning up the App Store. As the length of the names hasn’t really been the problem, it is keyword spamming at the end of the name.

But the 50 character limit is still interesting to consider, so I dug through my App Store metadata cache to see just how many apps would be affected. It looks like only around 9% of apps currently have names that are longer than 50 characters (around 200k). The distribution of all app name lengths looks like this:

You can clearly see that the vast majority of app names are clustered around 10-15 characters long, with a steep drop off to the absurdly long ones.

The average length of an app name is 22 characters. The mode is 11. The median is 17. Which tells me that the 50 character limit was added largely to constrain the problem rather than address it directly.. The vast majority of apps are short enough to be unaffected by the limit.

In case you are wondering, the longest an app name can currently be is 255 characters. There are around 44 apps with that length including “Super Flappy-blade-lord-new-baby-cheats-fall-plus-jump-cooking-fly-bird-shooter-mania-all-tap-top-cool-new-shooter-riff-all-in-space-cycle-pal-all-in-one-fm-messenger-epic-head-you-epic-guess-hero-run-hero-top-fun-girl-me-crazy-my-in-uber-flinch-net-fix-4” which is quite a feat in-and-of itself. I pulled all 44 of the 255 length names into a text file if you want to browse them.

I will be very curious to see how strictly the policy against adding additional terms to the name will be enforced. Will creatively descriptive names be allowed? Would something like “The Ultimate Platform Running and Jumping Adventure” be permitted? Is just moving the keyword adjectives forward to be part of the name rather than as a suffix going to be acceptable?

At the very least I suspect the trend of adding a dash/colon to the end of your app’s name and then appending a subtitle will be strictly forbidden. Roughly 500k apps (23%) include a dash or colon in their name so that will catch out a more sizable number than the 50 character limit.

I also got started wondering if the new limit would have a negative affect on any ‘legitimate’ names. So I lost more time than I’d like to admit on this Wikipedia page about the longest English words. The longest word in a major dictionary “Pneumonoultramicroscopicsilicovolcanoconiosis” is only 45 characters long so if someone were to make an app specific to this lung disease they’d be fine. If Disney wanted to make a ‘Supercalifragilisticexpialidocious’ (34 characters) app they too would be fine.

Things would only start to get tricky for long place names. If the local hiking club of “Tau­mata­whaka­tangi­hanga­koau­auota­matea­pokai­when­uaki­tana­tahu” (a hill in New Zealand) wanted to make an app they’d be out of luck with a name 35 characters over the limit. But in practice I don’t expect the 50 character limit to be a problem outside of these more novelty cases.

I’ve been thinking this past week (as I often do) about the ever-changing landscape of the App Store. This year has seen some of the biggest changes in policy and structure that I can remember. We have new subscription pricing models, search ads, a substantial purge of older apps, new requirements for app names and a variety of little changes to the App Store app itself in iOS 10.

I won’t know how the sum of these changes will impact my business until probably later this fall, but it seemed like a good time to look back at the last several years and examine the path that brought me here.

On November 8th it will have been eight years since my first app went live in the App Store. Back when I started I would have been gobsmacked to hear that eight years later I’d still be making my living solely from apps.

The App Store ecosystem today is wildly different from what it was back then. I launched my first app into a store of around 90k apps; today we have well over 2 million. Back then we didn’t have advertising networks, in-app purchases or subscriptions. You were free or paid, and if you wanted to make a living you pretty much had to be paid.

Today things are quite different. Paid apps now make up a vanishingly small proportion of my income, and nearly all of my recent successes have come on the back of free apps. The transition between the two ends has not always been straightforward but I’ve focused hard on being adaptable and open-minded during the transition.

The Data

I can perhaps most simply show the evolution of my indie software business with this chart:

I don’t have solid data going all the way back to 2008 when I launched my first app, but I do from 2012. In the last 4.5 years the split of where my revenue comes from has followed a clear, inexorable march from being paid-based to advertising-based. Starting in 2012 advertising in my apps made up around 10% of sales whereas now it is nearly 80%. That increase has come almost entirely from a near collapse of my paid upfront sales (with my in-app purchase income largely unchanged).

The steadiness of this progression, which traces a near perfectly linear curve over the last few years, initially made me worried I’d goofed in the data analysis. But I’ve double checked my data and this is what my history looks like.

Now before all you data scientists out there start shouting about how awful a 100% stacked chart is since it is so easily tricked by changes in the overall totals, here is a bezos chart of overall revenue over that period:

The same trends are quite visible here too. Other than the spikes caused by the launch of new paid apps (for example, Emoji++ in Oct, 2014 and Activity++ in May, 2016) paid sales have been on a steady decline since roughly 2013. The absolute value of in-app purchase revenue has diminished somewhat but held steady since around 2014. While advertising revenue has been on a gradual but definite rise.

(The sizable jump in advertising revenue this year was caused by switching away from iAd to AdMob when Apple announced they were discontinuing that advertising platform. The dip in revenue from January to May of this year was caused by staying on iAd even when their rates started to slide, likely an early indication of the end of the service)

You can see the transition between paid and advertising even more easily when I stack the two together:

Conclusions

Now this is all just the experience of one developer. It doesn’t really paint a full and complete picture of the App Store. But nevertheless I think that my experiences are consistent with what I have heard from countless other developers of the last few years. I am living proof that it is still quite possible to make a solid and reliable income from the App Store. The way in which I have been able to do that, however, has been to change with the times and constantly adapt to the changes in the market.

When I was discussing this data with a few friends I was asked a rather incisive question “Is this a change in your attitude, or a change in how the market is pushing?” Whenever we look at history it is easy to see what you want to see. To cherry pick your interpretation or ascribe causation to simple chance.

As I have looked back on these last few years I’ve come to the conclusion that the change is mostly been in the App Store market, rather than in my own attitudes. In many cases adding advertising to my apps has been something I’ve fought and resisted as long as possible. But in the end the pragmatic answer has been to not swim upstream and instead follow where my customers have led.

The market has been pulling me along towards advertising based apps, and I’ve found that the less I fight back with anachronistic ideas about how software “should” be sold, the more sustainable a business I have.

Last week we got news that Apple will be starting to clean out apps “that no longer function as intended, don’t follow current review guidelines, or are outdated.” This is fantastic news. Back in 2014 a program like this was my #1 hope in my Towards a Better App Store series. Wherein I argued that all apps on the Store should be required to keep up to date with the modern review requirements.

There are all kinds of challenges with cleaning out old apps. It is quite reasonable to argue that just because it hasn’t been updated in a while doesn’t make an app ‘bad’, however, that argument only holds water so far. After a certain point if an app is just left on the Store it will start to hurt the user experience. Determining that line is extremely tricky but there are certain aspects that are very straightforward.

The simplest are those that are objective rather than subjective. While Apple hasn’t said exactly the criteria they are going to apply, a few reasonable guesses are likely. If an app wouldn’t pass modern app review criteria and if it doesn’t function at all on modern devices. Beyond those it will get into the grey area where I expect them to (through trial-and-error) find the right balance between longevity and freshness.

As with all things I wanted to quantify the scale of this cleanup. I have no way of really knowing the scale of things with regards to functionality based criteria. But I can make some good guesses as to the more straightforward reasons to remove an app.

The simplest of which would be to see how many apps could not possibly support 64-bit. Since June, 2015 it has been a requirement that all new app updates include a 64 bit binary. It was only possible to include such a binary starting on September 9, 2014. So any app that wasn’t updated since then necessarily couldn’t pass modern review. Of the App Store’s roughly 2M apps my initial analysis showed that roughly 585,000 apps would fall short of this (or roughly 27% of apps).

Beyond that straight forward requirement things get a bit more vague. How old is tooo old? How broken is tooo broken? How long can an app go without updates before it is abandoned? These are much harder for me to guess for Apple’s policies. If they set the requirement at one year since last update nearly half of the apps in the Store would go. But that might be a bit too broad of a brush. I’d guess something more case-by-case rather than a strict age rule (except for when a new submission requirement like 64-bit is added).

Wherever the scope of the cleanup falls the results should be substantial. Both to customers who should have far fewer bad app download experiences and for developers who will be able to sell their apps in a cleaner storefront.

Of the twelve items I had initially hoped for back in 2014 around 5 of them are now in the App Store. While I could grump about the remaining 7, instead I’m simply delighted that for the first time in what feels like forever I’m seeing significant and profound progress on the platform on which I make my living. Which I must say is a fantastic feeling.

I’m delighted to have been asked to be one of the speakers at the next CocoaConf Yosemite. A technical conference hosted within Yosemite National Park (one of my very favorite places on earth). The conference runs from March 20 - March 23, 2017.

In case you missed it in today’s Under the Radar you can use the code UnderTheRadar to save 20% off your ticket.

Hope to see you there.