A solution to app store sustainability?

The rise of the app store model for software distribution has been an incredible boon for many independent developers, including the author of this post. It’s provided the exposure that solo devs were unable to get previously, and that – combined with easy payments – has enabled us to sell software in a way that just wasn’t practical before. It’s not only been a game-changer, it’s been a life-changer for many of us.

And yet, there are serious downsides. One that I’ve seen discussed a lot is the “race to the bottom” in pricing: that the default price for most paid apps is $0.99, the minimum that most app stores allow. This is a real issue, in that it devalues the software in the mind of the customer. But on a practical level, the size of the userbases involved has meant that it’s possible to make that up with volume, at least in theory. And the laws of supply and demand teach us that it may well be more profitable to price your product low – and sell a lot of them – than to price it high and only sell a few. So this isn’t a clear loss for devs.

A deeper issue, but one that I’ve seen less discussion of outside the developer community, is that of sustainability. As one well-respected dev said in a recent Google+ post, “Users expect the app they paid $2 for to be updated forever with every new OS release and with additional features, without any additional cost, forever.”

I hope I don’t need to explain the problem with this.

It can be OK as long as the market is expanding: a constant stream of new customers buying the app translates to an income stream for the dev. But the incremental cost of each new user is not zero: it costs the dev more time and effort to support 10,000 users than to support 100, in a number of ways. And if the number of users levels off, then the number of new purchases (and hence income for the dev) goes away, and the dev is left supporting the existing user base for free. Unless the app was extremely easy to develop in the first place (so there’s profit “left over”), was outrageously successful (which most of them aren’t), or has an extraordinarily low maintenance burden (hah!), it will inevitably turn into a losing proposition for the dev.

And although users may like the deal they’re getting now, if it’s unsustainable for developers, it will eventually be unsustainable for the whole app store.

So is there an answer to this, a way for modern apps to have a sustainable business model?

The conventional answer in the pre-app-store software world was to charge for updates. When you bought Windows 7, you had no expectation that you’d get updated to Windows 8 for free. That’s not how old-school software works, and everybody knows it. New versions come with a price tag, and while there might be a price break for existing users (or not), it’s still not free.

The first problem with applying this to mobile or web apps is that none of the major app stores support this pricing model. You can put a price on your app for the initial installation, but there’s no way to attach a price to an update. This is probably why that same G+ post mentioned above went on to say, “This is a fundamental problem that needs to be fixed by the platform providers.”

But if you dig a little deeper, I think you’ll find that it’s not that simple; such a “solution” wouldn’t actually solve the problem for indy devs. The reason is bug fixes.

Although I’d like to charge for updates, as an ethical developer I realize that it’s not OK to charge for bug fixes. These are essentially flaws in my product, and it’s my duty to fix them, to the best of my ability. If Google Play let me charge for updates to my apps, there’d inevitably be some users who would elect not to do it – users who are happy to remain on the older version. But additional bugs will inevitably turn up in these older versions, and since it’s my responsibility to fix them, this means that I end up maintaining two different versions of each app… then three versions, then four, another one each time I release a paid update.

Sure, eventually I can end-of-life old versions, but the time scale for that is measured in years – it limits the problem, but by no means eliminates it. I can also mitigate things somewhat by good use of source code management (so ideally bugs fixes happen once in common code, rather than being duplicated), but this is also an imperfect solution. The reality is, paid updates would actually multiply my software maintenance load. This really isn’t much of an improvement.

An alternative approach to the pay-for-each-update model is to create a new app on the store for each major version. So I’d release MyApp 1.0 for $0.99, then later create a new “app” on the store for MyApp 2.0, also $0.99. This has the advantage that it doesn’t require changes by the platform provider, but has a host of disadvantages:

  • It doesn’t help the bug-fix/multiple-version maintenance headache outlined above.
  • Every time you create a new app, you’re essentially starting from scratch on the app store. You lose your user base, your ratings & reviews, you have to fight your way up the listings again, and so on.
  • Your existing users need to be notified manually of the new version.
  • Migrating users from the old version to the new one is a headache. Settings need to be transferred, the user can easily end up with multiple versions on their device, etc.
  • There’s no way to give a discount to existing users.
  • Many users would scream bloody murder if you tried this (see the “pay once, get updates forever” expectation above)

In other words, this is pretty bad “solution”.

Another approach which is sometimes proposed is a subscription model. There are several variations to this, but they boil down to the same basic idea: charge your users an annual subscription fee for updates. While this is another model that isn’t explicitly supported by the app stores, they do support subscriptions, so it can be accomplished by the developer in their own code; essentially, by only making certain features available to users who have paid their subscription fee. This neatly avoids the version-multiplication problem we’ve had up until now: there’s only one version of the app out at any one time.

So I believe that this approach has some merit, but it also has some hurdles. One of the largest is the simple use of the word subscription: in the mind of the customer, a subscription is usually something that gets delivered either continuously, or quite frequently. Think of a music service (your tunes are delivered on-demand), or a magazine (which is delivered monthly). More generally, a subscription fee is something you pay for a service, not for a product.

And delivering frequent software updates as a service is a big ask for a solo developer, especially one who’s supporting multiple apps. Quite simply, I don’t have the capability to deliver frequent, major updates to all of my apps. Releasing a new version of every app, every month is fine if you’re Google, not so much if you’re one person working on your own.

“OK, so don’t support multiple apps”, I hear you say. That’s fine in theory, but it assumes that the single app I choose to support brings in enough income to support me. This is a big reason why I have multiple apps in the first place: because no single one would support me on its own. And once I put an app out there – especially with an update subscription – I’m making a commitment to support that app. I can’t just say, “This one’s not profitable enough, I’m pulling the plug on it.” I can’t afford that, and it’s not fair to the subscibers.

So subscriptions come with a lot of baggage – they’re an imperfect solution at best. Any other possibilities?

The last “standard” solution is in-app purchases (IAPs). Again, there are variations, but the basic proposal is to charge users piecemeal for significant new features. I develop something new for an existing app, it goes in as an IAP, and existing users need to pony up in order to use it. Sounds feasible, and again, it is an approach that is supported today by the app stores.

And it’s a reasonable model when one thinks in terms of the long-standing user: paid $2 for v1.0 of the app last year, pays another $1 for this year’s 2.0 features, and next year may pay another $1 for more new stuff in what I label as v3.0.

The problem comes after several years of this: new users (who are coming to the app for the first time) will find that the app they’ve just paid $2 for comes with many of its best features disabled, and they have to pay another $1 for each of them. They’ll rightly feel like they’re getting nickel-and-dimed here, and will likely voice this unhappiness in an app review. Bad news all around.

But maybe we’re getting close to a good solution here. I think we might be, and I have a proposal to make this work. It’s based on the IAP-for-upgrade model, but with a twist: when the next major update comes, the features from the last update get rolled into the “base” version of the app, for free.

Perhaps the best way to explain this is with a concrete example.
2014: I release the first version of my app, and set a price on it, say $2.
2015: I have a major update for the app, and release it as “Upgrade Pack 2015″ for $1 as an IAP.
2016: I’ve created some more new features, and bundle them into “Upgrade Pack 2016″, for another $1. But when I release this, Upgrade Pack 2015 goes away, and its features get rolled into the main ($2) app.
2017+: Lather, rinse, repeat.

A better labeling system might be to not tie it to specific years, but to use semi-traditional version numbers instead. So the above release history would look like this (the years are just to tie it to the previous example):
2014: version 1.0 is released for $2
2015: new features go into “Version 1 Upgrade Pack” (v1UP), for an extra $1
2016: version 2.0 (containing the features from both version 1.0 and v1UP) is released to all users, no extra charge. Simultaneously, new features go out as v2UP for another $1.
2017: version 3.0 released (v2.0 + v2UP), as well as a new, $1, v3UP
 . . .

Here are the important points to this approach:

  • At each release, existing users can choose whether the new features are worth another buck to them.
  • If not, they’re free to stay on “the old version”, and will get bug fixes all the same.
  • There’s never more than one code base to maintain; a single binary contains all features, and just has some of them paywalled behind an IAP.
  • At no point is there more than one Upgrade Pack available. So new users never get the nickel-and-dime feeling: there’s just the main app, plus one optional Upgrade Pack.

Looking at it another way, users are paying for “early access” to the features in each Upgrade Pack: if they want to wait, they will get them eventually, when the next UP is released.

About the only downside I see is that you’d probably need to explain this to the users as simply as possible, because it is a bit unorthodox. But that’s probably doable. [And with luck, it could even catch on and become orthodox. Call it the vnUP approach.]

Oh, and IAPs themselves are kind of a PITA, and need to be re-implemented for each app store you’re selling on (Google, Amazon, Apple, Samsung, etc.). But that’s one-time pain, and this work can possibly be re-used between projects.

One nice upside is that this can be layered onto a mature app, one that’s already in the wild with an existing user base. As long as you roll out your first UP along with some other, free bug fixes and minor enhancements, PR shouldn’t be too problematic. Then your pump is primed to keep the ball rolling with later versions.

But the big upside is that the app store business actually becomes sustainable. If a dev keeps adding new features, she has a legitimate opportunity to monetize her existing users on an ongoing basis. Everyone’s happy: the developer’s making a living, and the users get continuing updates, for a price that’s still very reasonable – or even for free, if they’re willing to wait. It’s a win for everyone.

Users: what do you think? A fair compromise?

Developers: are you with me?

Testing In-App Billing on Android

I’ve spent the last few weeks extending Wearable Widgets with in-app purchasing (variously known as IAP, in-app billing, or IAB). Honestly, there’s no good reason why this should have taken weeks. I can immediately think of a couple of reasons why it has, though. The first is security. Because IAB is essentially a commercial transaction, and because some lowlife will always be looking to scam you out of two bucks, you need to apply various layers of security to it – and these add time and effort. A paradoxical aspect of this is that you’re specifically advised not to use any code examples you might find online, especially those in the documentation, because the scum who crack these apps will have seen all those code structures before – and will probably have scripts ready to break it. But on the other hand, it seems to me that there’s a real downside to asking myriad developers like me to roll their own IAB solutions. Most of us are developers with no significant security experience – meaning that our homebrewed solutions are probably riddled with security holes and rookie mistakes, making them much less secure than code that’s been developed by security professionals. It’s a bit of a programming paradox, really. Further, Google also includes something they call an IabHelper, a pre-written wrapper around all of the IAB routines, and many of their examples are based around this helper class. But it seems to me that this flies in the face of the roll-yer-own security recommendation; I have to believe that any two-bit script-kiddie app-cracker knows right where IabHelper lives, exactly how to recognize it (even in obfuscated code), and how to exploit it. Seriously, why would Google even provide this? But that’s not really what I want to write about here. The topic I want to cover, the other area which has cost me a lot of time in my IAB implementation, is testing. Part of that is simply because it’s a complicated beast – OK, fair enough. But a big part of it is because the documentation for testing this stuff is about as clear as mud, if not actually misleading in some places. So I thought I’d share my experience in testing Google’s IAB as of mid-2014. Be warned, from here on in this entry’s going to be pitched at Android devs who are elbow-deep in IAB; I’m not going to explain every term along the way. If you’re not a developer, you may or may not find it worth your while to read on. But if you are in the target demographic, hopefully what follows will save you some anguish. Google provides a couple of doc pages about IAB testing, and you should start by reading those. They lay the groundwork, and nothing they tell you is really wrong – it’s just not quite the whole story. But nonetheless, you should start there, and get some understanding of the lay of the land. Now, I’m going to tell you the real story. Here’s the first gotcha: that first link above says that there are two ways to test your IAB app, test purchases and real purchases. And the page no sooner describes those two before it  goes on to discuss a third way, static responses. So the main thing I’d like to do here is to lay out the three ways to test IAB, with the things you need to know about each. I’ll present them in the order you should do them; complete your testing with one before you move on to the next.

Stage 1: Static Responses

This is where you should start: write your first pass at your IAB implementation, unit-test all the routines involved, and send the transactions off to Google Play with an SKU of android.test.purchased. [You can also use .canceled, .refunded, and .item_unavailable to test unsuccessful responses. But let's go for success right now.] These are the easiest tests, because you don’t need to upload or sign your APK in any way (other than the normal debug signature that the IDE automatically applies). These tests can also be run by any user – although apparently you’ll get incomplete information returned if you don’t test using your developer account, so I recommend sticking with a device registered to the same Google ID as your Play developer console. When you issue an IAB request with one of the static-response SKUs, the process will look something like this:

stage_1_1
 
  1. The purchase dialog Google Play shows will be completely dummied-up (see above).
  2. Assuming you’re using android.test.purchased, the transaction always succeeds.
  3. It returns to the calling activity’s onActivityResult() handler with a resultCode of -1, and a blank INAPP_DATA_SIGNATURE, but otherwise real values matching what you sent in the purchase request.

One important point I didn’t see anywhere in the docs: after you use a static-response SKU once, that SKU is now “owned” by the user that the device is registered to. And it will show as such in any subsequent IAB calls, which makes retesting a hassle. Apparently, it will reset by itself in a day or so, though I didn’t test this. I didn’t have the patience to wait a day between each debugging run of my app. But it turns out that you can also consume it in your app, with code like this:

IInAppBillingService.consumePurchase(3, context.getPackageName(), purchaseToken);

where purchaseToken is returned from the purchase request you sent. In my experience with static responses, the purchaseToken was a simple construct like “inapp:my.package.name:android.test.purchased”, but YMMV. And that’s about it for static responses. When you’ve done all the testing you can with them, you’re ready to move on to…

Stage 2: Real SKU, test user

This is the case that Google calls test purchases, and it involves sending your real item SKUs but in a test mode. Everything is like a real purchase, except that no money actually changes hands. It sounds so simple in the documentation… but there are a couple of serious pitfalls. First, you’ll need to get things set up on your Google Play developer console. You’ll also need to wait several hours after doing these changes for them to roll out through Google’s server network.

  • You’ll need to have created your IAB items (on the In-app Products tab of your app in the console)
  • The user ID(s) you’re going to test with must be whitelisted for IAB testing: Settings > Account Details > License Testing. Note that real SKUs can’t be purchased by the user who owns the Google Play account, even in test mode.
  • You need to upload a signed APK, with a higher versionCode (in the manifest) than anything you have published on Play.

When you actually do your testing, it will also need to be with a signed APK, and one that has the same versionCode as the uploaded-but-unpublished APK in the last step above. The bad news here is that there’s no using the debugger at this stage: logcat is your friend. But the good news is that it doesn’t actually have to be the same APK as you’ve uploaded to the dev console; it just needs to have the same versionCode. This requirement – for an uploaded but unpublished version of your APK – is never really, explicitly covered in the docs. It’s mentioned obliquely, but nowhere near as directly as it needs to be. If your test version hasn’t been uploaded to the APK tab on the console, the IAB call will fail. OTOH, if it is published at all – even in the alpha or beta channel – your test users will really get billed for the IAP. This one took me days to work out: silly me, I thought the alpha channel was specifically for this kind of testing, and as long as I had the user’s Gmail address on the whitelist, the transaction wouldn’t post. Wrong. The whitelist is ignored for published APK versionCodes. In fact, it’s even a bit worse than that – the whitelist is ignored for all versionCodes less than or equal to anything published. Let me illustrate that with a concrete example:

  1. The production versionCode of my app is 9 – that’s my baseline, before I started implementing IAB.
  2. After I had a first cut of IAB done – with versionCode 10 – I published it to my alpha-test group and had a whitelisted user try it. He got charged, because 10 wasn’t unpublished.
  3. Learning from these mistakes, I uploaded a later version (13) to Google Play, but did not publish it. I then emailed the APK to some whitelisted testers, who successfully used the IAB feature without being charged.
  4. Moving closer to release, I built versionCode 14 and published it to beta. I fully expect users of this version to be charged, and they are.
  5. However: the next day, one of my whitelisted test group from step 3 – still on versionCode 13 – tried out the IAB and got charged for it. My best explanation for this is that, even though 13 is still unpublished, the whitelist is igored, because 14 is published.

The bottom line is, upload to Google Play but don’t publish anything at this stage. But once you have all those pieces in place, and have given them time to take effect, here’s how it’ll go:

stage_2_1
  1. The purchase dialog will be real, but with the extra “test order” line shown above.
  2. The purchase always succeeds, AFAICT
  3. The return values are all real (token, payload, etc)
  4. The transaction appears in your Google Wallet Merchant console with a “Test:” prefix

As with static responses, this SKU is now owned by the user, causing a similar headache for any retesting you need to do. You’ll need to cancel it from your Merchant console (or alternatively, it will apparently expire in a week or two). Be aware that, in addition to cancelling the purchase, you’ll also need to clear the cache for Google Play Store and Play Services on the device – and probably reboot, and maybe wait an hour or so – before the SKU will stop showing up as owned.

Stage 3: Real Purchases

This isn’t really “testing” IAB any more; everything is live, from the APK down to the financial transaction. But Google includes it on their testing page, so I’ll discuss it briefly here as well. Basically, this is the scenario your user will be in whenever the versionCode of the APK they’re running matches one that’s published on Google Play, in any channel (Alpha, Beta, or Production). It’s also the way the purchase will play out if the user isn’t on your IAB, or the whitelist entry hasn’t percolated through the Googlenet. As confirmation of any of these situations, any time Google Play shows a purchase dialog without the “test order” verbage (compare the above and below screenshots), the user will get charged for the purchase.

 stage_3_1

I’m not going to go through the whole process here, because it’s a live transaction, and everything happens accordingly. If you do need to retest in this case, its like Stage 2: clear the cache for Google Play Store and Services, reboot the phone, wait an hour.

Time Is Money

One recurring theme you might notice from the above is all of the waiting that goes on. From hours to weeks, there are many, many aspects of IAB testing which require you to just twiddle your thumbs (or go read Engadget) for extended periods. Which is why testing this has taken so damn long. As of today, I’m really not sure that IAB was worth doing, especially for (what should have been) a dead-simple implementation like mine: I have exactly one product, essentially an unlock key to turn the “trial” version of my app into the “full” version. There are several other tried-and-true ways to implement this sort of freemium model, and I’m not at all convinced that IAB was the right one to choose. Sure, it may be slightly lower-friction for the users – but enough so to justify weeks of extra developer time? Will it actually gain that many more conversions? It’s impossible to know.

What if the war is over?

According to analyst figures, Android is hovering at around 80% of mobile device shipments worldwide. iOS accounts for most of the remainder, with about 15%, leaving roughly 5% for everyone else to fight over. And fighting they still are, but at some point everyone else has to ask themselves: is there any justification for continuing? It’s looking more and more like future technologists will recall this decade and say of some particular date, “That’s the point when the mobile platform war was won by Android.” Like how we can now look back on, say, World War II, and make pronouncements like, “The Allies had essentially won by the time of the Normandy invasion in June 1944. Germany just hadn’t admitted it yet.”

My hypothesis is that, right now, early 2014, that point in mobile has already passed. We’re just too close to the battle lines to see it.

This hypothesis may be wrong, of course, but here are a couple of indications that it may be right: The most successful tablet platform after Google and Apple is Amazon – and it’s Android. The most interesting, talked about, up-and-coming mobile platform of today (in my opinion) is Cyanogen Inc. – and it’s Android. In other words, the platforms lining up after Android and iOS… are Android. That’s not proof, sure, but for the rest of this article I’m going to explore some of the consequences that I would foresee if the hypothesis were true.

If my hypothesis is true, it means that we’re moving into a place – or rather, realizing that we’re already in a place – where it can be safely assumed that any mainstream mobile device (not made by Apple) is running Android. Because, what else would it be running? Think of the PC market any time after about 1992: there was never any question that a given Dell, Gateway, or Compaq would be running Windows. Sure, Apple was doing their own thing, and there were any number of niche platforms, but for the real mainstream, there was only one. Forget competing ecosystems, that’s a fantasy.

I’m certainly not the first to draw a parallel between the mobile platforms of today and the PC platforms of decades past, with Google filling the role held by Microsoft in those days, and Apple as, well, Apple. But that’s the dynamic that always gets the attention, Apple-as-underdog vs. The Establishment. Apple’s got experience in that role, and is apparently happy with it, that’s what they do. We don’t need to worry about Apple. But what about everyone else?

Everyone else, in this case, falls generally into two camps. First, there will always be niche platforms nibbling at the periphery, filling the needs of some particular corner of the market. Like how the various Linux distros do on PCs – and sure enough, open-source analogs to those are appearing in mobile, like Ubuntu and Firefox. It’s always possible that one of these may break out into the mainstream, but for now, I think we can safely call them niche platforms. And by definition, they don’t affect the big picture very much.

The second camp contains the dinosaurs, the platforms which were big players in the pre-iOS world and which didn’t evolve quickly enough to stay competitive. Nokia has already fallen, sold itself out, admitting that it had lost the battle. The others that are still holding on are BlackBerry and Microsoft, of course: both have lost the large market share they once had, both have reinvented their platforms as “modern” alternatives – and both have completely failed to get any significant traction. And both are still in denial about having lost the war, both still think that they can claw their way back to relevancy.

If my hypothesis is correct, it’s already too late for either of these contenders, and has been for some time.

The writing has been on the wall for BlackBerry for years now, and although they’re hemorrhaging money and employees (not to mention CEOs), they still talk like they can win this thing. Does anyone outside – or even inside – of Waterloo actually believe that any more? BlackBerry 10 is a fine OS, and its current hardware is more-or-less competitive, but that’s like saying “Germany could still win in 1945 because they built good tanks.” I’m not going out on a limb at all when I say that BlackBerry, as it was, is finished.

What can this particular dinosaur do to avoid complete extinction? The first step is to admit defeat, and ring down the curtain on the BlackBerry OS. Then bring the quality BlackBerry hardware over to Android – it’s the only option now, remember – and work to leverage whatever other strengths BlackBerry Ltd. has left. I’ll bet it still has good supply chain connections, and some lingering relationships with carriers. If necessary, it could build an emulation layer to run legacy BlackBerry apps on Android (they’ve already done the reverse), as a bridge for existing customers.

Beyond that, a good strategy would be to play the security card that BlackBerry was once renowned for. Deserved or not, Android has a reputation for being wild and insecure – BlackBerry could conceivably build a locked-down ‘droid that would offer execs (and others) a secured experience. Better yet, BlackBerry could buy that expertise: Geeksphone has recently announced its Blackphone project along those same lines. Even the name’s a good fit. I’ll bet BlackBerry has enough left in the bank to aqui-hire Geeksphone, kick-starting Waterloo’s Android conversion and even picking up some long-lost geek cred in the process.

The other dinosaur in the room is Microsoft… and it’s complicated. They’re too diversified to get dragged under by the failure of their mobile platform; they can keep it on life support indefinitely if they so choose. But on life support it most certainly is: in the last quarter of 2013, sales of Nokia’s Windows Phone handsets fell by 7% – in the quarter that includes the Christmas buying season. And Nokia is almost the only one making these phones any more; if it wasn’t for Microsoft buying Nokia’s hardware division, there’d hardly be any Windows Phones at all these days. You can be certain that this battle is lost if the oft-rumored Nokia Normandy, running Android, comes to pass – a sure sign that Microsoft has admitted their defeat. [Did you say Normandy? What was that about WWII earlier?]

But that’s not happened yet. Right now Microsoft is also in the search for a new CEO, and the direction that the new leader takes will tell the tale here. S/he might double down on Windows Phone, and make a last shot at relevancy with a big shakeup. Buying T-Mobile might just do it (think about that one for a minute).

But probably not. My thesis is that the war’s already over, right – and if so, what’s Microsoft’s place in the post-war world?

One option is to just get out of the phone business entirely. Sell off the remains of Nokia (who’d probably go on to build some great Android phones) and fall back to the businesses that Microsoft knows, and more-or-less dominates. Take their ball and go home.

If we’re truly moving into a post-PC era, though, Microsoft won’t want to sit that game out. So again, the first step is admitting defeat, and learning to live under the rule of the victors. Let the Nokia division build those great Android phones, and build its own place in the Android market – a place that’d probably be significantly larger than its Windows Phone market is now.

As for Microsoft proper, well… At its core, Microsoft is a software company, and you know something? Its software could actually run on someone else’s operating system. Here’s a plan: Release Office (and other apps) for Android. Retool its server products to work well with Android clients. Build Android integration into XBox. Better yet, do all of these things for iOS and MacOS too: Apple and Google could be its partners instead of its competition. There’s no intrinsic reason that Microsoft has to control the whole software stack, it’s just done that for so long that everyone (especially in Redmond) expects that’s their rightful place in the world.

Which brings us to the big opportunity here: if the war is over, the combatants can stop fighting and start cooperating. Can build great things together. Think of it as a mobile platform peace dividend.

Afterword: Through most of this article, I’ve been drawing parallels between the mobile market of today and the PCs of yesterday. But it hasn’t escaped my notice that the PC market is still around (if shrinking), and may be undergoing a real shakeup for the first time since Microsoft established their dominance. To wit: I wrote this piece on Chromebook… indicating that it’s never too late to introduce a new platform contender.

What’s Next for Wearable Tech

The news out of CES last week highlights the growing profusion of wearable devices: smartwatches are the most widespread, but there are also smart glasses, earphones, bracelets, rings, and more. It’s a real “wild west” time for these devices; nobody really knows where they’re going, or what the best use cases are.

For developers, the situation is especially acute, because essentially every device is siloed right now. If you have a good idea for a wearable app, you need to write it for Pebble, rewrite it for sony_sw2Sony’s Smartwatch, again for Google Glass, and so on. It’s true whether you’re building primarily for the device itself, or even just trying to interface your existing phone app with a wearable display: each device has its own little ecosystem. Some of the more shortsighted manufacturers haven’t even opened up their devices to outside devs (I’m looking at you, Samsung).

It’s not dissimilar to the state of the phone business circa 2005. Most phones of the time supported apps, and there were even a few smartphones around, but they were all siloed in this same kind of way. If you wanted to deploy a phone app to a good-sized audience, you had to write it for Blackberry, then rewrite it for Windows Mobile, JavaME… and don’t get me started on Symbian, where Nokia couldn’t even maintain compatibility within their own product line. It was a mess.

Even within each of these platforms, there wasn’t a good, low-friction way for devs to sell and deploy their wares. The different silos may or may not have had “stores”, but those that did were all pretty small, and app discoverability and monetization was a real challenge. And again, this is mirrored in the current state of wearables: Sony’s Smartwatch pairs with Android phones, so they’ve piggybacked off the Google Play store. Pebble, on the other hand, is just opening a store of its own. Glass has a small selection of officially-sanctioned apps curated by Google, but it’s far from easy to break into, and (as of right now) you can’t charge for your apps there. And so on… it’s a mess.

The first thing that changed in the phone business, of course, was the introduction of the iPhone. Apple was the first vendor to really nail it, not just the device, but the app store too. And for the devs, it was a veritable gold rush. This is one route that the wearables market could take: one vendor could “get it right”, have a device that’s a breakaway success, and build a big enough silo to be self-sustaining. You get a definite sense that most of the current players are hoping for this kind of outcome, but don’t know how to get there.

But there’s another route, one that we’ve seen before in the phone business. I’m talking about Android, of course: although it was released over a year after the iPhone, and took another couple of years to really pick up speed, it’s become the dominant ecosystem in mobile. And it has done it in large part by not being siloed to a single vendor; its openness has unified the vast majority of phones and tablets onto a single platform. The wearables market doesn’t just need something like Android to unify it, it needs Android. And essentially all the pieces are already in place, if you know where to look…

To start with, Google already has one of the leading wearables – Glass – and it’s running full Android on board. Google has also bought one of the pioneers of the modern smartwatch era – WIMM Labs – and rumors about a forthcoming “Google Watch” have been rampant for a couple of years now. It’s not really a secret that Google is moving into wearables, but I’ve seen little analysis about the bigger picture of that move – not just about Google selling a smartwatch or Glass to the general public, but about the broader ecosystem play. So here’s how I see that playing out.

Sometime this year – most likely at I/O – Google will take the wraps off Android 5.0, let’s call it Licorice. Licorice will give Android full, native, first-party support for wearables, in much the same way that Honeycomb brought first-party tablet support to what had previously just been a phone OS. [Sure, there were Android tablets pre-Honeycomb, but they were half-baked, not-overly-successful forays into unsupported territory. Remember the original 7" Galaxy Tab, back in 2010? That's what the Galaxy Gear is now.]

The wearable support features introduced in Licorice will include:

  • A new screen size bucket, for screens less than 2″ in size, which will extend the lower end of the existing small-normal-large-xlarge Android screen size range. Alternatively, Google could extend their newer minimum-width-and-height resource selectors with maximum-width-and-height descriptors, but that seems clumsier to me.
  • A set of new UI conventions and development paradigms appropriate for small, glanceable displays without keyboards. Want to see a preview? Look at the Glass Development Kit (GDK) introduced last month. It’s all there, and most of it would work equally well on most any wearable, not just on Glass.
  • New low-power optimizations, quite likely in cooperation with one of the major ARM vendors. This actually already started with support for Bluetooth LE in Android 4.3.
  • Wearable-specific extensions to the Play app store, analogous to the improved tablet support that Google brought to Play in 2013.

The point here, of course, is to extend the Android phone-and-tablet ecosystem to include wearables as first-class citizens. And this will enable a whole new generation of Android wearable hardware. Glass is the forerunner, but for everyone speculating about of “the public release of Glass” or “the Google watch”… you’re thinking too small. We need to be thinking about a whole range of such devices, from a variety of manufacturers. Some will bear the Google name, but certainly not all.

I expect that the first of these devices (after the current Glass XE) will arrive at the same time as Licorice, probably also with announcements at I/O. We’re getting further into speculative territory here, but I think we can make a good conjecture from Google’s past hardware ventures – essentially, projecting Google’s known hardware tendencies into the this next realm. There are some definite patterns to the hardware Google has used to introduce other new ventures – phones, tablets, and laptops (Chromebooks) – that will likely also apply to wearables.

  1. The pioneer hardware, designed and built with Google’s close supervision, defines Google’s role in a new space. This is essentially a public hardware beta, whether or not it’s openly acknowledged as such, and is usually a bit clunky and prone to widespread criticism as “an unfinished device, for early adopters only”. Well duh.
    • Phone: G1
    • Tablet: Moto XOOM
    • Chromebook: Cr-48
    • Wearable: Glass XE
  2. The second wave is populated by other OEMs, producing variations on the original hardware, more or less independent but still running Google’s OS. This crop of devices begins the move into the mainstream, and historically, has included the early Android and ChromeOS devices from all the major manufacturers.
  3. After a year or two of this, Google weighs in again, producing a device that “sets the standard” for where the big G thinks the ecosystem should be going. The Nexus One, Nexus 7, and Chromebook Pixel all fit this description.
  4. Everyone iterates, of course, Google and OEM alike.

The first thing to notice in the Android wearable space is that we’re still in phase 1 of this progression. Glass is the only official-Android wearable device we have so far, and the Explorer program is nothing if not a public beta – we’ve got a long way to go. I think Google’s Web DNA includes a strong “release early” tendency, and that applies to hardware too.

And if other Android wearables follow the same sort of pattern, then they’re even further behind. The first “Google watch” we see is likely to be a hardware beta comparable to the G1 or Cr-48: clunky, unpolished, with just a glimmer of its true potential. As I said, it’ll probably be announced at I/O 2014 – hell, it’ll probably be given away to attendees – but don’t expect it to be an instant game-changer. Google plays a longer game than that, and wants you to be a part of the process.

Ready for another gold rush?

AFTERWORD: What about Apple?

Apple doesn’t play the same game as Google, of course, but the introduction of the iWatch is at least as eagerly anticipated. The thing is, Apple thinks different: it develops its hardware in strict secrecy, and doesn’t release until it’s been polished within an inch of its life. Compare the G1 to the original iPhone, the XOOM to the iPad, the CR-48 to the Macbook Air. A Nexus or Pixel can go toe-to-toe with its Cupertino counterpart, but that’s only after a couple of years of public hardware iteration.

The point being, Apple won’t release an iWatch until it’s good and ready. Could be anytime, could be years down the road.

The other thing about Apple is that it doesn’t tend to join a rough-and-tumble, free-for-all market like wearables are in right now. It tends to let other companies make the early mistakes, learn from them, then release a product that overcomes the widespread issues affecting the first generation. If this pattern holds, Apple might not release its iWatch for some time yet. You can bet they’re watching the space closely, though, and refining their own plans all along.

The API of Unintended Consequences

A change to the Android API that arrived in the KitKat is that alarms don’t necessarily arrive when your code requested them to. From the docs:

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; seesetWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.
Now, many apps won’t be especially bothered, but I have two apps with clock widgets that rely on the alarms being delivered exactly on time; otherwise, the clock widget is wrong until the alarm does get delivered. Which means that my widgets now need to use setExact() rather than just set().

Which is fine as far as it goes – but what’s not mentioned above is that there is no setExactRepeating(). Here’s another extract from that same page:

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whosetargetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.”

This means that my widgets must now reschedule their alarms every minute. Which means my widgets are now running more code every minute than they were before. Which means that my widgets are now using more battery than they were before – exactly the opposite of Google’s stated intent with this change.

Footnote #1: I should also mention that, in my testing, these inexact alarms occur on KitKat devices even if targetSdkVersion is set to 18. That’s not what the docs (quoted above) say, but that’s how it works on my Nexus 7.

Footnote #2: No, I can’t use AnalogClock and Chronometer to avoid these alarms (and use less battery). They’re too limited for my widgets. My analog clocks are 24-hour (the AnalogClock class is 12-hour only), and the Chronometer class really isn’t suitable for digital clocks.

Resistor Decoder

An app like Barcode Scanner but for resistor color codes: Using the camera (and probably requiring the flash), read the color bars off a resistor and output the resistance value.

I have little doubt that it’s possible, but at the same time, it’s probably a nontrivial problem in image processing and pattern matching. And, beyond its niftiness factor, it’s not something that very many people would pay for. So, not worth the effort, unfortunately.

It’s more the sort of thing that some geeky Googler should do in his 20% time. Or, some random geek with more time on his hands than me.

Meta Cloud Drive

After seeing yet another “sign up for our new cloud drive, get 20GB free” offer, it dawned on me: could you make a “meta” cloud drive that works purely by piggybacking off others?

The idea is that the MCD would have interfaces to loads of “normal” cloud drives, and would manage your storage appropriately. So if you had 5 or 10 GB from each of Dropbox, Box.com, GDrive, iDrive, SkyDrive, Copy.com, Wuala, and so on, you could easily end up with a couple hundred gigabytes. Then your MCD would bring them all together, managing them as a single virtual drive, so you don’t have to worry about what’s actually stored where.

If you had enough space, it could even incorporate RAID-like functionality: replicate individual files across multiple cloud services so that, if one is unreachable, you wouldn’t lose your data.

Ideally, it’d also manage your accounts with the different services. If you had existing accounts you would go ahead and enter those credentials, but I’d like to see it automate the sign up process for others. IOW, you open an MCD account, and can then automatically sign up with 10 services behind the scenes. We might even be able to do something crafty with referral bonuses behind the scenes to leverage extra storage for our users.