What were they thinking?

With its new Watch Urbane LTE, LG has gone with a WebOS derivative rather than use Android Wear, as all their other smartwatches do. What’s that about?

It seems clear that LG wanted a watch to compete with its arch-rival Samsung’s Gear S, which packs an LTE radio for voice and data access directly from your wrist. This is the headline feature of the Urbane LTE – it’s right there in the name. And since Android Wear doesn’t support cellular connectivity, LG needed an alternative. [The Gear S gets around this limitation by running Tizen, Samsung’s own mobile OS, on which it’s based most of its smartwatches to date.]

But even given that requirement, WebOS seems an odd choice. It’s hard to imagine that many developers will create new apps – or port existing ones – for an ecosystem that contains exactly one device. And without apps, any smart device faces an uphill battle for consumer acceptance.

Why didn’t LG just use Android? Not Android Wear, but a parallel fork of the AOSP. I can’t imagine that it would have been significantly harder than adapting WebOS, and it would have gone a long way toward addressing the app problem. There are currently thousands of developers building for Android Wear, which is 95% pure Android. We’ve already made our apps work on the smartwatch form factor; it would be a much shorter path for us to rewrite the Wear-dependent bits than to start over from scratch.

As an aside, though, there is one interesting aspect to the WebOS choice. As its name implies, WebOS is based on web technologies: “native” WebOS apps are actually little web pages, with functionality written in JavaScript. You know what other smartwatch OS uses the same architecture? Tizen. That’s right, the easiest watch apps to port to LG’s new shiny will be those written for its mortal enemy, Samsung’s Gear line.

All this is an issue because Google is maintaining much tighter control over Wear than it historically has over Android generally. This means that all platform-level innovation needs to come from Mountain View, rather than being driven by partners – and clearly, this is holding the ecosystem back. Major OEMS, like Samsung and LG, have already chosen to use other platforms rather than live within Android Wear’s limitations. There are two likely results of this situation.

First, Wear is unlikely to achieve the same kind of market-share dominance in wearables  that Android enjoys in mobile. Whenever a vendor does want to push the envelope, it’ll need to do as Samsung and LG have: use another OS. That fragments the wearable space.

And second, Wear is likely to be far less rich and diverse than Android has been on phones and tablets. We won’t get the experimentation, we won’t find any interesting new use cases that Google doesn’t see coming.

But in the wider world of wearables, innovation will happen. And when a bold new idea does resonate with consumers and take off – there’s a good chance it won’t be Android Wear doing it.

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?

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’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.

FAD Followup

…where FAD stands for Free App of the Day, the Amazon Appstore’s program where they offer a different paid Android app free to customers every day.

This is a followup post to my original FAD thoughts, posted shortly after I had my first app in the program. Exact download numbers are Amazon-confidential, but suffice it to say that Moon Phase Pro got hundreds of thousands of downloads that day, which significantly boosted its visibility in the Appstore and led to a marked increase in paid revenue for weeks afterward. A good deal all around.

Some months later, Amazon offered me another FAD spot for another app, PolyClock – and since my first experience had been quite positive, I didn’t hesitate. This time things didn’t go nearly as well; the total downloads were much lower, and there wasn’t a significant sales boost after the day. I simply chalked it up to the app in question being more niche-oriented, with a narrower appeal. And since there really wasn’t a downside, I didn’t worry much about it.

Then came my third app in the Program, Convertor Pro, after Amazon extended FAD to their European markets. And unfortunately, I have to say that this was a downright disaster. Again, I can’t reveal exact sales numbers, but since around Christmastime Convertor Pro has been selling reasonably well in the UK; it’d been hovering in the top 5 in its category. Not paying for my retirement, perhaps, but a respectable earner.

Then came its FAD spot – and sales immediately plummeted, to a small fraction of what they’d been before. It’s been about ten days now, and its ranking in category is currently around #15 and still dropping.

Of course, I have no proof that FAD was responsible for the drop, but when you look at a graph of its ranking over time, the correlation is hard to deny:

That green bar there is its free day. (The numbers below are its ranking on a given day before FAD.)

So in summary, I’m nowhere near as impressed with FAD as I was a year ago. Perhaps it still makes sense for some apps – but my advice right now is: if your app is already earning any kind of money in Amazon’s Appstore, don’t risk it.

Is This Not Publishing?

A good article in the NYTimes today about Barnes & Noble. First, a few interesting facts:

• B&N and Amazon apparently control 87% of the e-book market between them. Two-thirds of that is Amazon’s, but considering the relative size of the two companies, B&N’s not doing badly.
• There’s another new Nook device due this spring, despite the fact that their latest refresh just happened in October. That’s a quick cycle for products of this nature.
• They claim they’re on the verge of expanding outside the USA, which I consider good news all around.

But in my opinion, the most telling aspect of the article is the central thesis that B&N is seen by publishers as their last, best hope. Not for taking advantage of the exciting opportunities in e-books, but for holding onto their legacy dead-tree business, and all the legacy cruft that’s attached to those business models.

From my point of view – mostly on the outside, as a reader, but also as a bit of an author – it seems clear as day that the old publishing model has outlived its usefulness. This is why Amazon scares the crap out of the old guard; they’re changing how publishing works, and succeeding at it. And they’re hoping against hope that B&N, as the last bricks and mortar bookstore chain standing, can salvage the old model – never mind the Nook.

The best part is how they frame the debate in the article: that Amazon et al will be the death of publishing. But “publishing” is a larger concept that isn’t actually threatened. Undoubtedly it’s undergoing a transformation, but writers (of whatever stripe) will still publish. And for long-form works (as opposed to short-form, whose “publishing” has already been transformed by the web), there will still be a place for those who facilitate it. It just won’t involve the same structures that Random House is using now.

The echoes of SOPA/PIPA seem unmistakable: the entrenched legacy businesses know that they’re dinosaurs, but they’d rather deny that reality than evolve.

Free App of the Day Observations

Early in the life of Amazon’s Appstore, their Free App of the Day (or, as Amazon calls it, FAD) program got a bunch of bad press from developers. Some criticisms included:

• The “freebie” nature of the promotion brought in a lot of users who weren’t actually that interested in the app, but who nonetheless felt compelled to leave negative reviews, bringing down the rating.
• The massive influx of new users – hundreds of thousands in a day – could easily crash back end services, exacerbating the previous issue.
• A general dislike of Amazon giving paid apps away for free, “just like pirates do.”

Overall, I got a sense that many devs felt there was no real upside to the program, but the potential for a substantial downside. A consequent opinion was that this program benefited Amazon at the expense of indie devs.

Having just gone through FAD with an app of my own, I have to say that I don’t agree. Being FAD made for a very intense day, with serious ups and downs, but overall I’m glad I accepted their offer. Not least because sales on the Appstore have picked up significantly in its wake.
For future reference, I have the following observations about helping FAD to work in your favor.

1. Your app needs to have mass-market appeal, and be immediately accessible to the average person. A large number of your downloads will be to people who are only getting it because it’s free, not because the app particularly appeals to them. If it’s a niche app, they won’t appreciate it. If it takes time to appreciate, they won’t wait that long. And in either case, they’re likely to turn on you in the comments.
Corollary: I have little doubt that many apps just aren’t suitable for FAD.

2. Make sure that the app is as stable and bug-free as you can possibly make it before giving Amazon the go-ahead. The user numbers will be large enough that even small edge cases will get thoroughly exercised. And again, you’ll hear about any problems in the comments, alongside 1-star ratings.
I had the bad fortune to have a bug surface that literally only existed on 8 Jan 2012, the day of my FAD spot. On the plus side, it was subtle enough that not many users actually noticed.
2a. Make doubly sure that the app works well on the Kindle Fire. I don’t have statistics (I realized too late that my analytics weren’t working), but I have little doubt that Fire users make up a large percentage of the FAD downloads. If you haven’t bought a Fire yet for testing, maybe now’s the time. If you don’t feel you can justify that, find someone you can borrow one from for a few days. But in any case, test your app double-extra-thoroughly on this device.
[As usual, the emulator won’t cut it. The other major issue I had reported that day was a Fire firmware bug that affected my app, and which I hadn’t noticed in my testing. Moral: test EVERY piece of your app on real Fire hardware.]
2b. Goes without saying, but make sure any back-end services you use are up to the load. If you don’t think they will be, don’t do it.

3. Don’t plan on doing anything else on your Free App day. If you’re building apps on the side, take the day off from your day job. You’re going to get a bunch of emails, and if you respond to them right away, the users will appreciate it – and reward you in the comments. And that’s the other thing you should be doing that day: monitoring your comments. Leave responses where appropriate (but be nice), and my advice is to up-vote the positive comments and down-vote the negative ones. Don’t be afraid to flag the really obnoxious ones as inappropriate; it does seem to have some effect.

If you can’t devote the day to babysitting your downloads, that doesn’t mean you shouldn’t accept the FAD offer, but just be aware that you won’t be getting maximum benefit from it.

4. Enjoy the ride! For most of us, these opportunities come along pretty infrequently, so soak it up while it lasts.