The Growing iOS SDK

This morning I was remarking to myself about how it felt like the breadth of knowledge you need to be a good iOS developer has gotten pretty far reaching. This isn’t anything new, iOS development has never been particularly straightforward but as I thought of all the SDKs you need to master to make your app ‘good’ it became a pretty long list.

I hate to just have a notion without numbers to back it up so I got to thinking how I could evaluate how the complexity of the iOS SDK has changed and grown over the years. In the end I found that the Xcode docsets could serve as a useful proxy for how the SDK has changed. Each documentation element is tagged with the SDK version where was introduced. I quickly aggregated the SDK elements1 by their introduction version to see the changes.

When the iOS SDK was introduced back in 2008 there were around 2,500 SDK elements total across all APIs. Since then each year has brought with it an average of around 1,400 new elements. Bringing the total for iOS 92 up to just shy of 13,000.

While you certainly don’t need to know all 13,000 of those elements for any specific app they nevertheless represent a pretty monumental body of knowledge to wrap your head around.

There was a time when I felt like I knew my way around pretty much every non-game SDK available on iOS. Now I often find myself stumbling across frameworks that are completely foreign to me, which is both kind of exciting but also extremely daunting.

  1. An SDK element is any part of the SDK that is tagged within the documentation. This can be a class method, instance method, property or constant.

  2. It is possible that the iOS 9 numbers aren’t final since we don’t have the final GM yet.

David Smith




Impact of iOS 9’s Space Requirement

At WWDC when Apple unveiled iOS 9 one of the features they highlighted was a reduction in the upgrade free space requirement from 4.6GB to 1.3GB.

I love improvements like this. They help drive quick adoption of the new OS by my customers. Which in turn lets me more quickly drop support for older platforms and focus on the new stuff.

I was curious, though, as to how much of an impact this reduction would have in practice. So using the dataset I have from my Audiobooks app I took at look at how many of my customers have enough space for the upgrade.

The result was pretty promising.

66% of my customers on eligible devices have at least 1.3GB of free space. This compares to just 37% of users who would have immediately had sufficient space at the old iOS 8 requirement.

The distribution of eligible devices breaks out roughly as you’d expect for the various capacities Apple sells:

The rate for the 16GB devices (54%) is higher than I would have initially feared. The 16GB capacity accounts for 58% of devices, so it is vitally important that its users have the ability to upgrade.

This reduction in the space requirement (and other things Apple is doing on this front) make me think iOS 9 adoption to be even faster than iOS 8’s. I’m starting to feel much more comfortable with being aggressive about dropping iOS 8 support and fully embracing the new stuff in iOS 9.

David Smith




As I Learn watchOS

watchOS Series

Over the past few months I’ve been doing a series called As I Learn WatchKit trying to share my journey of building apps for Apple Watch. The series has had a much wider reach and reception than I could have ever hoped. Given this week’s announcements at WWDC it seemed like an update on what I’m planning to do was in order.

Apple has given us a tremendous set of new APIs in watchOS 2. Coming into this week I was very curious to see where they would take the Watch next. I wasn’t sure if they would have a major advancement of the capabilities of Watch Apps ready so close to the Watch’s launch—but that is exactly what they delivered.

The most delightful part of what I’ve seen this week is how pragmatic and thoughtful the approach they have taken is. Rather than introducing a radically new approach to developing Watch apps, instead they built directly on what we’ve all learned in watchOS 1 and just made everything better. With the exception of the unavoidable data management changes related to moving to native apps most of my apps could run as-is on watchOS 2. Which is a tremendous confidence builder in terms of my continued commitment to developing for the platform.

That said…I won’t be leaving my apps as-is.

watchOS 2 brings with a wide collection of new APIs that enable me to make my Watch apps tangibly more useful and performant. I’m especially excited about the possibilities around Health and Fitness made possible today. The addition of CoreMotion and HealthKit to the Watch mean that I’ll be able to do some very robust things with tracking and reporting on my users’ activity.

I’m expecting to continue to share what I learn over the next few months as I dig into these new technologies over the summer…though the name of the series needs a minor update ;)

Today I’m starting a new series called As I Learn watchOS, I hope you come along for the ride.

David Smith




Start-to-Finish: Building an App

Something I often struggle to answer is the question of ‘How do you make an app?’

The process is multifaceted and often complex. I recently had an idea for an application that I thought I could build in a single sitting so I thought this would be the perfect opportunity to try and capture what this looks like.

In the video below I walk through the whole process of making an app. The app is called Take Me There. I show the process from getting the idea, through coding and design, through submission (the real fun starts at 4:29).

The app itself is a single purpose utility that lets you quickly build a list of favorite locations and then easily get directions to those locations. The app was built with the Apple Watch in mind, where I find it really awkward to enter locations into the Maps app. It also supports Apple Maps, Google Maps and Waze on the iPhone.


App Store Link
David Smith




A Humble Suggestion for Activity Rings

I love the Apple Watch activity rings. I really do. Whoever at Apple came up with the idea of showing your activity as three concentric circles that you close when you complete your goal deserves a raise. It taps into the completionist part of my brain a way few other things do. It bothers me to leave one un-closed, which is exactly what it should do.

But I do have one problem with the current approach. This is what the current complications look like on the watch.

The trouble I have is the visual difference between the last three’s exercise ring. I find it very difficult to tell the difference between an almost filled exercise ring and an actually filled exercise ring. This has caused me to miss a few days unintentionally when I thought I had reached my goal, only to discover later that I’d slightly missed it. I hit this on the 42mm watch, looking at my wife’s 38mm the problem is even more significant.

I want the UI to congratulate me for getting there and in some ways celebrate the accomplishment. In Pedometer++ I go so far as to have confetti virtually rain down on you when you hit your goal…and while confetti on your watch face is probably not a good idea, I’d love some kind of high-five from the watch.

I think there is a reasonably simple solution to this. I’d like to suggest that when you close an activity ring it changes color slightly. Nothing dramatic (as I’m sure the intention is to make sure that the complications on the Apple Watch stay subtle and undistracting), but enough to clearly visually show the accomplishment. Something like this:

Apple folks: I filed this as radar #21139998, should you be able to give it some love.

David Smith