Benchmarking in your pants – 10th Anniversary Edition™

One of my favorite posts is one that’s over ten years old: Benchmarking in your pants.

In that essay, I compared the original iPhone to my iMac, both with native and web apps. One of the reviewers of my treatise on the iPhone SDK thought it would be fun to see how those numbers stack up to an iPhone X.

The code still runs, so why not?

Test Original iPhone iPhone X Faster by
100,000 iterations 0.015 secs. 0.000408 secs. 36x
10,000 divisions 0.004 0.000043 93x
10,000 sin(x) calls 0.105 0.000107 981x
10,000 string allocations 0.085 0.000367 230x
10,000 function calls 0.004 0.000040 100x

These numbers should be considered very approximate. I only used three digits of precision in the original measurements, this time over 5 were needed. Also, there was no attempt to use more than one core.

Still, it’s easy to see why today’s apps are much more sophisticated. They run code hundreds of times faster.

They also have screens that are a bit larger than 320 × 480 :-)

Apple’s Lenovo

To bring long-term value for clients, companies need to continually reinvent themselves.

This quote comes from an IBM announcement that it was selling its PC business in 2005.

IBM’s business was moving towards services, and it was less dependent on hardware sales. But it still needed hardware to provide services for its clients.

The deal let IBM focus on its future. Lenovo got the ThinkPad brand, engineering talent, and a sales channel. This was one of those rare win-win scenarios they teach in business school.

Apple is no stranger to reinventing itself. Thirty years ago, it was selling a $15,000 printer.


It was a beautiful device that produced stunning output. It launched the desktop publishing revolution and established Adobe as a central figure in the software ecosystem.

And today you can’t buy a printer with an Apple logo.

Someday soon, we’ll look back wistfully at those beautiful displays Apple used to make. With the announcement of the new LG partnership and displays, we’re seeing another part of Apple’s business being outsourced.

Maybe it’s time that Apple does the same thing with the Mac Pro business described by Marco Arment.

Like IBM, Apple is in a bind. Its future and the bulk of its revenue depend on mobile devices. Yet we can’t make these products without the horsepower provided by the Mac.

Besides Apple’s own internal needs, there are many professionals creating content for mobile devices. These folks need fast and capable computers to create apps, music, and videos. We all need powerful Macs to enrich the mobile ecosystem.

John Gruber said it best, “It’s the heaviness of the Mac that allows iOS to remain light.” But will iOS pick up this heavy load by the end of this decade? I don’t see it happening with my own work.

Licensing just the operating system was a disaster for Apple. Professional customers don’t have the time to build and maintain their own Hackintoshes. Any partnership to build Mac hardware would need to be structured so that it benefits Apple, the partner, and customer alike.

Just like IBM and their clients have benefitted from Lenovo.

Adulterated Swift

There has been some discussion lately about Swift not having the dynamic features of the Objective-C runtime. Brent Simmons has been doing a great job of pointing out why this is a problem.

It’s very easy to overlook the importance of the dynamic runtime environment. Many of the things it enables happen behind the scenes. There’s no better example of this misunderstanding than a developer who says their app is “Pure Swift”.

That’s because you can’t currently write an app that only uses Swift. The purity of your code is lost as soon as you #import UIKit.

A picture’s worth a thousand words, so here’s a project that demonstrates why it’s impossible. The app itself is ridiculously simple: there’s a button, a few labels, and a single action method. It’s as “Pure Swift” as you can get.


This project also contains an Objective-C category named NSObject+Adulterated. This category overrides two methods that lie at the heart of the dynamic runtime: -respondsToSelector: and -methodForSelector:. The normal operation of these methods is not affected; the only additional functionality is some logging to the console when they’re used. Other than being in the bridging header, the code is not used directly by the app.

When you run the app, you’ll immediately see all the places where Swift is not being used. Pretty much everything you take for granted in your app is using the dynamic runtime. Layout, drawing, animation, and event handling are all dependent on something that Swift doesn’t have yet.

Of course, you’ll immediately say, “This isn’t Swift’s problem! Just rewrite the frameworks!”

And that is exactly the point I’m trying to make.

The community around Swift’s evolution is amazing. The language is improving quickly and dramatically thanks to talented developers inside and outside of Apple. It’s a remarkable open source project.

My concern is that there isn’t a corresponding discussion about the things we’re going to build with this new language. As you’ve just seen, frameworks are important, yet there is no uikit-evolution mailing list. There is an imbalance between the tool and the craft.

I’m guessing that part of this problem lies within Apple itself. There are plenty of developers in Cupertino who have built large applications and the frameworks that they use. I’m absolutely certain that this subject has been discussed in detail by some very smart folks. And they, of course, can’t talk about internal projects.

My suggestion for the folks on the Swift project is to be a little more forthcoming about future plans with frameworks and other infrastructure besides the language itself. It’s a big piece of a puzzle that long-time app developers want and need.

A lot of hand-wringing could be ameliorated with a simple “Yep, we’re working on it.”

Strapped In

A lot has happened since I purchased my Apple Watch on April 10th, 2015. One unexpected aspect to owning this device is my fascination with watch bands:

Apple Watch Bands
My current collection of watch bands. And no, the watch isn’t upside down.

From left to right, in order of date purchased:

  • Sport Model with Blue Band ($400) – I picked the aluminum watch with a blue band because I knew it would be spending a lot of time in the water. To date, I’ve used it 110 times for over 35 hours of swimming.
  • Milanese Loop ($150) – I was intrigued by this band as soon as I saw it during the video at the product announcement. I love how the metal feels a lot like fabric. It also dresses up the utilitarian Sport model so it doesn’t look out of place when I’m someplace nice.
  • Black & Silver Nylon ($30) – This NATO-style band from Clockwork Synergy popped up on my Twitter timeline thanks to my pal Rob Rhyne. I love that it dresses up the watch and is waterproof.
  • Red Sport ($50) – When Apple started selling additional colors for the sport bands, getting one in my favorite color was a no-brainer. I also like that a little of my purchase goes to a worthwhile charity.
  • Orange Silicone ($20) – This band by MoKo was another recommendation from Twitter by Neven Mrgan. To me, the most interesting thing about this band is that it shows why Apple went with fluoroelastomer for their bands: it’s stiffer and “breathes” better than silicone.
  • Black Goat Leather ($200) – The leather bands from Apple are nice, but I prefer the classic look of this one from Lucrin. The company also offers a huge range of colors: my wife loves the dark green one I gave at Christmas.

In this survey of my growing collection, there’s an interesting datapoint: the value of these bands ($450) exceeds the cost of the watch itself ($400).

If Apple decides to change the interchange mechanism in some future version of the watch, I will have very little desire to upgrade. As I continue to “work in” my leather band, I hope I’ll be using them for a long time.

The New iPod

Something tells me that there were a lot of Apple Watches under the tree this year:

Clicker Downloads for December 2015

That graph shows the last month of downloads for my free Clicker app for watchOS. Since this app does nothing on an iPhone or iPad, the only reason to get it is if you have a new watch.

Many of us, myself included, originally thought of the Apple Watch as a device in and of itself. But the more I use the computer on my wrist, the more it feels like a satellite to the computer that’s sitting in my pocket.

Accessories have always made great gifts for folks who love their computers. Giving the watch as a gift is a perfect option for someone who’s always playing around with the apps on their iPhone. Just like the iPod was an ideal match for someone who loved playing music on their desktop computer.