The real genius of Apple’s payment plan

Of all the things Apple introduced at its latest media event, the one that sticks out to me the most is not any iPhone feature. It’s not Apple TV and it’s certainly not anything to do with the watch.

It’s the iPhone payment plan. It’s absolute genius.


It’s not because it further weakens the relationship between consumers and cellular carriers to Apple’s benefit (although it does)

It’s not because it gives Apple control over a massive supply of second-hand iPhones they could resell at lower prices to lower-income markets and demographics (although it does).

No, the real genius of the Apple payment plan is that it increases iPhone lock-in by an order of magnitude. Now, once you go iPhone, you will never leave.

You see, Apple has made it so you can get a new iPhone (and AppleCare+) for a reasonable $30-ish a month. It is over the course of 2 years, although Apple will let you get the new iPhone when it comes out every year. Of course, at that point the 2 year clock resets. Now here’s how it means you’ll never leave:

Let’s say it’s November 2016. You’ve had your iPhone 6S for one year (with one year to go on your payment plan). The new fall range of smartphones comes out, including (I’m going out on a limb here) the iPhone 7. What are your options for the next year?


Who *wouldn't* sign up for the shiny new iPhone?

Who *wouldn’t* sign up for the shiny new iPhone?

Option A: keep using your iPhone 6S. Pay $35 a month for the next 12 months.

Option B: upgrade to the iPhone 7. Pay $35 a month for the next 12 months.
Pretty easy decision, right? If you’re paying the same amount of money over the next 12 months, why not upgrade?

And here’s where it gets positively diabolical:

Let’s say you want to switch to Android. You have to pay the cost of the Android. And you have to pay Apple the remaining $420 you owe on your old iPhone payment plan. Apple has now erected a $420 moat around leaving Apple.


Let that sink in: Once you’re in the Apple payment plan, it is more expensive to go to Android than to stay in iPhone.

And that of course is on top of losing iMessage, your apps, the approval of your hipster Apple friends, and whatever other digital ecosystem lock-in Apple has put in place by then.

Once you go into the iPhone payment plan, you’ll be using an iPhone and giving Apple money until the day you die.


Not bad. Not bad at all.



As Windows Phone market share declines from an already low baseline, fans and pundits alike point to the possibility of Windows 10’s new “Universal Apps” as a potential weapon to reverse Redmond’s sinking fortunes in mobile. The ability for a developer to write her app once and easily bring it to multiple devices—from PCs to phones and even Xboxes—could entice more developers to take the plunge. Microsoft’s dominant share of desktop software would translate into a dominant share of mobile software as developers happily earn more return on their investment by bringing Windows apps to multiple screens at once. It could finally give Redmond a weapon to “increase the availability of applications for—and lift sales of—the company’s smartphones.”

While developers in the early days of smartphone apps might have found that compelling, there has since been a dramatic change in the nature of apps themselves—and not one in favor of Microsoft (or anyone else looking to promote universal apps across desktops and phones).

What was this change? The Great Mobile Divergence.


First generation apps were mostly small screen derivatives of regular computer experiences. Think apps like tiny office apps, simple games (Trism) and scaled down app versions of websites we all used on our desktops (Yelp, Facebook, Twitter, etc). Almost every bit of functionality of a smartphone was a lesser version of PC capabilities (from RAM to CPU to screen size), limited further still by nascent SDKs that put tight limits on what developers could make their apps do.

But it wasn’t merely limitations of technology that doomed early apps to be lesser versions of their desk-bound selves; as developers we were limited by our own imaginations—which had only just begun grappling with the potential of what a smartphone can make possible. In 2008—on Day One of the iPhone SDK—everyone who wanted to make an iPhone app was a desktop developer, and thought like a desktop developer.

Consumers were no better: beyond a few obvious use cases, we had yet to consider how else smartphones could work besides as a smaller PC, and had yet to demand it. To paraphrase Henry Ford’s apocryphal quote, we were asking for smaller desktop apps in the same way we once asked for faster horses.

For the reason of all these limitations, making a mobile app in early days meant taking things out of your “main” desktop software, not putting exciting new things in—let alone starting with the idea of a mobile experience (or entire business!) first. If Microsoft had been able to roll out Universal Apps then, their mobile OS would almost certainly be doing much better than it is now.


In the years that followed, our hardware, software, and imaginations have improved by leaps and bounds. Devices that started out as basically tiny, less capable derivative devices of our computers evolved into an entirely new category of device with a panoply of sensors and radios, backend services (and SDKs that let us exploit them) that made it possible for the developers—ever more skilled and creative with their new smartphone canvases—to create entirely new experiences.

Companies went from throwing together their mobile apps after their desktop and web apps to building (and furiously recruiting talent for) dedicated iOS and Android dev teams that are continuously pushing the boundaries of what we think is possible to do with technology.

The smartphone didn’t catch up to the PC; rather it transcended the PC, and took the innovation industry’s center of gravity along with it. The paths of mobile and PC had diverged—probably never to meet again so long as they will exist as a meaningful product category.


The most interesting developers and companies today aren’t shrinking down desktop experiences. They are building entirely new experiences that wouldn’t make any sense—or even be possible—on a PC.

Think about it. The value of a universal app is that you could write an app and have it easily working on all Windows platforms. If I had a bank app, an airline booking app, a casual game, or another app I was already planning on making for PCs, then sure, the idea of universal apps makes sense…

But what good is a Lyft app on a desktop? What good does the Luxe parking app do on my Xbox? What would Instagram even do on my ThinkPad? How could I use a barcode scanning price comparison app on a PC tethered to my desk? Is a PC going to count my steps or monitor my heart-rate in real-time? Can it help me navigate traffic with Waze? What good is a Starbucks card app (or any store app, or any mobile payments solution for that matter) going to do on a device that isn’t mobile? Heck, what would Grindr do if limited to a desktop—find romantic leads within my specified IP address blocks?

The ability to make software easily for a desktop is of little use for the brave new world of mobile-first (and mobile-only) experiences. Microsoft can’t tout the ease of making a desktop and mobile version of App X simultaneously as a competitive advantage if making a desktop version of App X is not desirable—or even possible.

Desktop-first developers will struggle to bring their apps to mobile in a way that adds value. The new generation of mobile-first developers simply won’t bother to bring their software to the desktop, which has just become a more constrained version of what a computing device can be and do.


Smartphone apps can be just about anything in 2015, and Microsoft just found a compelling developer value proposition for what apps could be in 2008—before the Great Divergence. Universal apps won’t solve the app problem that has plagued Windows Phone from day one. While a subset of app developers can and will bring their app to the PC and phone, the most interesting ones simply won’t.

This isn’t to say that Universal Apps aren’t an impressive technical achievement (they are), or that Windows Phone isn’t a nice OS in and of itself (it is, for the most part). We’d all be better off if the mobile OS universe could be more than just a war between two insanely rich and powerful tech superpowers, and it’s a shame Windows Phone couldn’t make it happen (it’s also a shame they had to take Nokia’s phone business down with them in the process, but I digress).

Ironically, Microsoft is standing on firmer ground with a hologram than it is with Windows Phone.



Today (April 24 2014) was the last day of Nokia as we knew it. The staff of Nokia’s Silicon Valley office went to the restaurant down the street and had one last celebration together. We had fun and said our goodbyes.

On April 25, that Nokia ceases to exist, and in its place are two companies that officially have nothing to do with each other: Microsoft Mobile Oy (where the heart of the company will go) and Nokia Oyj (where I will be).

Tomorrow I will still be an employee of Nokia. I will go to my office in Sunnyvale. It will be the same building it was yesterday. It will still say NOKIA on its facade basking in the California sun. But half of the people I’ve worked with will be gone. Up through today we shared everything. Tomorrow we will share nothing but our memories.

I am not writing another piece to lay blame for who is responsible for the decline and fall of this iconic company. I am writing to reflect on what Nokia has meant for the world, and for me.

Of course, the sheer success that Nokia had in its mission of “connecting people” makes it impossible for me or any one person to say what Nokia meant for the world. The story of Nokia is the story of over a billion human beings whose lives were touched, and even transformed, by being connected to anyone, anywhere, for the very first time. It is the story of a small Nordic country transformed into a global technology powerhouse, of a plucky company that achieved what the smartest management consultants had warned them was impossible, and of thousands of individual triumphs of dedicated employees who made breakthrough after dazzling breakthrough in engineering, logistics, design and marketing, only to outdo themselves soon thereafter.

For me, working for Nokia was a wondrous, life-changing experience. Nokia saw potential in me and took me in as a refugee from HP’s webOS debacle. They empowered me to try crazy new ideas that turned into wild successes, and gave me the freedom to help others with theirs. Nokia took me to a dozen countries across four continents, and allowed me to rise from a Developer Community Manager to a Product Marketing Manager to a Product Manager in Nokia CTO’s most ambitious and exciting project. Nokia gave me as much as they could, and in turn I gave them everything I had.

What I had the opportunity to accomplish in less than 3 years at Nokia was incredible. But my story is a short one, and one among thousands of Nokians. I hope others share their stories. They should be told. Not many people can say they worked for a company that had such a great impact on so many people. Thanks to Nokia, I am privileged to be among the few. The “happy few”…

But we in it shall be remembered-
We few, we happy few, we band of brothers;
For he to-day that sheds his blood with me
Shall be my brother; be he ne’er so vile,
This day shall gentle his condition;
And gentlemen in England now-a-bed
Shall think themselves accurs’d they were not here

Henry V, Act IV, Scene iii


The Nokia that we knew ends today, but its impact on the industry and the world will last for years to come.

And the phones it made will last forever.


Literally. Forever.

Nokia, you gave me my first gray hairs, sleepless nights, and countless moments of frustration and anguish as I watched you die and couldn’t save you—and the best, most exciting, most illuminating years of my life as I tried. Damn you. And thank you.


I’ve been spending a lot of time looking at Android lately.  It’s the most important computing platform in the world (so far). If it’s not already the most widespread, it certainly will be in the near future

Since my employer has gotten out of the phone business (sigh…) I now feel free to comment on Android and other smartphone things without worries of running afoul of any company policies on publicly discussing competitors. So here is the first in what will hopefully be a running series of thoughts on Android and how to further improve it. First up: Android and device compatibility with the Internet of Things


It should be anything but controversial to state that Android’s greatest strength–its massive distribution across geographies, demographics and devices that vary in price and features from the very top of the market to devices that somehow sell an entire smartphone for less than some people pay for iPhone cases (in short, its diversity)—is also its Achilles heel.

The ability of Android to bring the power of personal computing to hundreds of millions and then billions of human beings who may otherwise never have experienced it is a tremendous achievement that should be celebrated. However, this creates a tension within Android: how to continue to drive the specs for low-end Android down, while continuing to drive innovation with cutting-edge hardware on the high-end? Let’s look at this through one particular angle, which happens to be the next frontier in mobile technology innovation: support for Internet of Things devices and wearables—particularly those with a direct (Bluetooth/Bluetooth LE) connection to the phone.


My own Android (the brilliant Moto X) has a problem. It has had a stormy relationship with my BTLE, “Internet of Things”-era gadgets: my Pebble smartwatch and my Fitbit. At the intersection of chipsets, drivers, OEMs, developers and OS software (rest assured, they all blame each other), the connections between my Moto X and IoT devices are woefully lacking. My Moto X was simply “unsupported” by FitBit when I first bought it, and to this day the Pebble smartwatch can only maintain the flakiest connection with my Moto X, frequently losing the connection and failing to update the weather or whatever other info my Pebble watches. This of course comes on top of the already-frustrating                    month-long delay between Pebble 2.0 support being released on iPhone and its being released on Android.

How my Pebble usually connects to my Moto X (or doesn't)

How my Pebble usually connects to my Moto X (or doesn’t)

And again, this isn’t on some off-brand, not-even-Google-Play-certified device I got from a guy in Shenzhen. This is on the Moto X, a flagship Android device (and truly the best Android device I’ve used to date).

And it is clear that my device and I are not alone in this. Perusing Google searches and statements from developers and reviewers in the Play Store show there are countless users with various devices having connectivity issues, making the overall experience frustrating for users and a support nightmare for developers who get to enjoy what I call the “1-star Rage Review” problem in which a user whose device has compatibility issues takes it out on the developer and drags their app’s rating through the mud even though the situation is as likely to be the fault of an OEM with a glitchy BT driver.


The problem is this: Android devices at the high end suffer from lack of consistency in hardware support for next-generation Internet of Things experiences. This makes the Android experience worse for developers and worse for Android end-users—and drives both of them to the iPhone, which by comparison really does earn its “just works” reputation (no wonder given that you can count the total number of iOS devices you need to target on one hand). The ultimate tl;dr for this article comes form Tile, a very nifty Bluetooth LE tag that lets you find tagged things anywhere with your iPhone (and only your iPhone):

The tl;dr right here

That pretty much sums it up

Google, this is a problem.

Given that Internet of Things and wearables are among the next big waves in consumer technology innovation, this is something Google should proactively address.


Idea 1: don’t do anything. BTLE support will improve over time.

While strategic inaction can be a surprisingly underrated plan in some cases, I don’t think this is one of them. Yes it is true that BTLE support in Android has improved and will continue to improve and grow more widespread across the Android device spectrum. But it is still in a state of “improving” on Android right now, whereas iPhone is working right now. If you were a startup with a new idea for a connected Bluetooth gadget, which platform would you target first? No, Google must be more proactive.

Furthermore, even as the BTLE disparity slowly resolves, the next hardware innovation will begin the Cycle of Bad Support all over again (we see it now as Apple moves forward with the M7 motion-sensing co-processor and full API library to support it while support for similar functionality in Android devices is again a piecemeal effort at best between Qualcomm, Google, and OEMs).

Idea 2: mandate better support from OEM as a condition of Google Play certification.

Google could update the Google Play minimum devices specs to include more robust support for BTLE and other advanced sensors. They could restrict the number of “acceptable” chipsets and rigorously test them to ensure compatibility reaches “it just works” levels. Or they could welcome any chips but require them to pass a vastly more stringent suite of testing requirements.

This would backfire because it would either drive device prices up and/or drive OEM partners away.

Saying that all Android phones must have flagship-level support for IoT connectivity puts an unreasonable burden on the makers of low-end Androids, who will pass those costs on to end-users. The phones will cost more. If they cost more, fewer will be purchased. That’s bad for everyone.

What is even worse for Google is that forcing these changes on all OEMs could simply drive many of them to use a non-Google fork of Android that doesn’t come with Google’s expensive requirements in order to continue making phones at lower and lower prices

And all this for what gain? Yes the problem for people purchasing Moto Xs, HTC Ones and Galaxy phones would be solved, but for the rest of the world, “better connectivity to my smartwatch and Fitbit” is not really a pressing concern. Google needs a solution that improves the experience for the high-end phone+IoT ecosystem without impeding the growth of the low-end, phone-only ecosystem.

Idea 3: The Good Idea

Well you knew I was setting you up for this, didn’t you? I suggest Google go for a more pareto-optimal approach. For high-end devices targeting wealthy consumers in developed markets, offer OEMs a supplemental certification program. It could be a narrower band of BTLE chipsets supported, it could be more rigorous testing requirements for any chips, or some other means of ensuring a more reliable and easier to target developer platform.

I’ve even got a name to show Google Play certification of Internet of Things devices: Google PlayThings

Hey, it works

Hey, it works

People like me who are interested in a high-end Android phone and an Internet of Things that goes along with it can buy a PlayThings certified Android. The billions of people on earth who need smartphones to be as cheap as possible can still get a great Google-connected device

The “1-star Rage Review” problem could also be ameliorated. Imagine if only users who had a PlayThings certified phone could leave reviews on the product. Developers and other potential users could get useful reviews instead of being drowned in a sea of 1-star “IT DOESN’T WORK” rageviews. Better, more useful reviews means happier developers. It also means more users, which in turn means even happier developers who will bring more great new experiences to Android.

Moreover, PlayThings as a standard should evolve as the technological frontier moves forward. For example, PlayThings 2014 may focus on BTLE while PlayThings 2015 could add focus on a consistency in motion coprocessors.

While Android can never replicate Apple’s simplicity of compatibility (“works with iPhone 4S, 5, 5S”) being able to say “works with PlayThings 2014 devices” is an improvement on the current practice of maintaining lengthy lists of compatible and incompatible devices from dozens of OEMs.


Of course, any change in a product/program should be accompanied by an analysis to see if it opens up any new marketing opportunities, and a PlayThings program would open up new marketing opportunities for both consumers and developers. Google could start promoting PlayThings-certified phones, IoT things, and supporting apps in its Play Store.

Consumers will benefit from having a visible and trusted place to buy new pieces of hardware to augment their Android experience. With such a showcase, consumers would purchase more new connected devices than they would otherwise, which of course also benefits the 3rd party developers making them and going through the effort to support Android and not just iOS.

Why not use this valuable real estate to promote an ecosystem cool Android-compatible gadgets?

Why not use this valuable real estate to promote an ecosystem cool Android-compatible gadgets?

So there we have it. I think this solution addresses a real platform problem of Android in a practical way that:

  • doesn’t hurt Android’s ability to scale down to the next billion users
  • improves the experience for high-end users
  • also creates a new marketing and merchandising opportunity to make targeting Android more lucrative for today’s most cutting-edge hardware developers.

Google I/O is coming up soon. Let’s see what they have up their sleeves…

Why Gruber may be wrong re: “Smartphone Mojo”

John Gruber wrote a rebuttal of sorts to a piece in The Nation about the iPhone “losing its Mojo” against the ever-growing wave of Android devices.

Gruber did point out (correctly, in my view) that the iPhone does attract the more valuable segment of customers, and so they can still do well with a smaller share of the market because they have the customers that matter.

One comparison I found a bit less convincing was when he talked about how iPhone “was never the smartphone market share leader” being behind Symbian and BlackBerry (while still having a superior ecosystem to the companies with larger shares of the pie).

I don’t think that is relevant to Apple’s situation vis-a-vis Android. See, BlackBerry and Symbian were not at all into the whole “ecosystem” thing. Symbian (pre-Qt) and BlackBerry (pre-BB10) developer platforms were technically rough and a headache to develop for. The powers that be behind Symbian and BlackBerry OS weren’t working furiously to match their market size to a developer platform from a technical or business perspective. The difference between Apple building a superior ecosystem with smaller market share then (vs Symbian and BlackBerry OS) and now (vs Android) is that Google has done (and continues to do) spectacular work in recognizing the importance of a developer ecosystem and building the technical and business supports for that ecosystem.

Apple has never been in a situation in which a competitor held considerably larger market share and put just as much effort into its developer platform/ecosystem as Apple did.

Well, that’s not entirely true. Apple did face a competitor like that before. It was called Windows.

image credit:

Apple didn’t do so well when a competitor combined a real ecosystem effort with bigger market share. Nearly killed ’em, actually…

Instagate: Put up or Shut Up

Okay, technical elites. You’re the ones who are the most upset over Instagram’s policy changes. You’re also the most technically able to build new things, and wield influence over others (so you say, anyway) to change how we do things.

Well, you self-styled leaders, it’s time to lead. How about you actually stop using Instagram and start using something else? Put up and do something, or shut up and bow your heads down in servitude/while aiming your iPhone at your food to take another picture of it

Metro++ | Is that text clickable or not?

In what will hopefully be the first of many “Metro++” blog posts on improving the Metro experience, I wanted to focus on discoverability of functionality. One of the weaknesses in Metro as it now exists is that the emphasis on typography instead of chrome means that it isn’t always clear when any particular piece of text is meant to be clickable and do something, and when it is meant to simply be read. This has two negative consequences:

  1. Users will miss functionality by not knowing some text chunks are clickable, which is a Bad Thing
  2. Once they grasp that some text is clickable, they will try poking (or if using Metro with a mouse, clicking) all over all the time to discover the Metro app’s functionality by trial and error—which at least works, but isn’t particularly elegant, and would be seen as a downgrade compared to iOS and Android which better delineate between clickable text elements and non-clickable elements by making the former more button-like

Case-in-point. I only accidentally discovered that header was clickable

Now, how can Microsoft (or an OEM with some significant rights to customize the OS) solve this problem?

  1. Redesign the entire OS. No.
  2. Delineate between clickable and non-clickable text with additional graphical elements. In the Metro UI guidelines, MS shows how to make a clear distinction between graphical elements that serve as buttons and those that don’t: Put them in a circle or a box. A circle/oval would be impossible and look out of place. A rectangle around actionable text would work, but add a lot of clutter, especially if there is a lot of actionable text. So…No, but getting warmer.

What it would look like to button-ize everything: a cluttered mess

I think the solution is right under our nose…or somewhere between the nose and the screen. I am of course referring to smell-based computing the hover!

Crafting Hover

Hover (or onMouseOver) rose to prominence in the early-ish days of the WWW as a mass phenomenon. HTTP websites were a new concept for millions of people accessing the Web for the first time, and much as in Metro today, there was some confusion in what text was clickable (this can still be witnessed today by watching your parents trying to navigate the Internet). This was solved in two ways:

  1. When the cursor was on top of something actionable it turned into a pointer finger
  2. When the cursor was on top of a UI element (such as a nav menu) that was actionable, the element would change color or to another graphic thanks to the power of this newfangled thing called JavaScript

Of course both of those relied on a cursor, which doesn’t exist in a touch interface. Can we make an equivalent of this “I’m here, but not clicking on it” function in a touch screen?


*with the help of some clever capacitive technology

Capacitive touch screens work by sensing a disturbance in The Force the electrical field around the screen, not just at the immediate glass surface. It is actually entirely possible to sense a finger wandering around above the screen without actually touching it, as Sony recently demonstrated with “floating touch” in their Xperia Sola. And so it is possible to have mouseOver effects in the Metro interface! When the finger is near a clickable block of text, that text could highlight itself in a number of ways, but I think 2 good ones would be:

1. Underline, a la IE in the late 90s

OPTION 1: Underline on mouseover

2. A glowing effect around the actionable text

Option 2: Glowing effect on hover

Any of these would address this discoverability shortcoming in Metro, and also look pretty darn cool and futuristic, which helps sell devices at retail, and adds another layer of sophistication in human-device interaction that would make iOS and Android look a bit dull by comparison. Also in Metro, an added bonus is the ability to have graceful degradation from Touch to Mouse, since the onHover signals can just as well apply to MouseOvers. So, that’s what I’d like to see. Get to it, Microsoft!