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?


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.

Travel Weather

This idea was inspired by WUnderground’s Road Trip weather, but I envision something much more configurable, useful. Basically, to be able to set dates (and optionally, times) for a list of locations and see the current weather forecast for each time/date combination. Obviously, it would update with new forecasts as time passes.

It could be standalone (enter your itinerary manually), but would be better if it integrated with something like TripIt. It’d also be nice if you could enter endpoints for driving directions (for a multi-day road trip) and build from that.

First-Person Minesweeper

That’s it, in a nutshell… Reorient the classic Minesweeper from top-down to first-person. It’d be surprising if nobody has done it before, but I don’t think that I have seen it. My vision is for it to have a maze/dungeon appearance, where the game play involves knocking down walls as the metaphor for clearing cells.

Not clear how you’d get “past” flagged cells… Maybe a 3D aspect?

Working title: Sweepminer

Flip Tablet

Given that nobody seems to have a screen technology ready for market that’s both (a) daylight-readable, and (b) comparable to an AMOLED or IPS LCD indoors… an interim solution would be a single device with both a conventional tablet screen and E-ink.

My original vision is for a tablet with a conventional 7″ screen, but on the back, it has a 6-7″ E-ink display. I’d expect that only one of them would be active at any one time; the device’s motion sensors could detect when you flip it over, plus it’d also have some other mechanism to select a screen – maybe a hardware button, maybe a particular touchscreen gesture. But however you do the flip, it’s basically just deactivating the one screen and activating the other; if they don’t have identical resolutions, that’d probably involve a configuration change, but that should be no big deal.

So the use model is basically, when you’re indoors you’d generally use it like any other 7″ tablet, with the conventional screen. But when you’re outdoors, you could use the e-ink instead; sure, you’d be somewhat limited by the constraints of E-ink, but you could still do a lot more than you can with a conventional tablet outdoors. E-book reading is the obvious killer app, but most web surfing would be fine – especially reading long-form articles – as well as email and chat.

Apart from the two screens, I see it being a pretty conventional tablet in other ways. It’d be nice if both screens were covered in Gorilla Glass (or equivalent), since the device doesn’t have a back to set it on. And since it’s meant for outdoor use, waterproofing would also be a bonus. Possibly it would make sense to optimize a few apps for E-ink, but I suspect there’d not even be much of that needed.

Cameras might be interesting – again, since the device doesn’t have a back, the question of front- or rear-facing gets a bit muddled. Maybe it has two intermediate-res cameras (say 3-5MP), one on each side, and you just use whichever one’s appropriate for what you’re doing. Or maybe the E-ink would be so lousy as a viewfinder that we can effectively ignore it – but I’d see some interesting use cases if that’s not the case.

Moving beyond the original form factor, the same idea could theoretically work in both larger and smaller sizes. The 9.7″ screen from the Kindle DX would sit nicely on the back of a 10-inch tablet, for example. Thinking about it, it’d also be really handy to have this tech just in a phone – you wouldn’t get full smartphone functionality in direct sunlight, but it’d be a heck of a lot easier to place and receive calls, send & receive texts, and do email than with current displays. [I’ll need a different name, though – “Flip Phone” has too much baggage.]

Another variation is to arrange the two screens in a clamshell, something like Sony’s Tablet P. I’d like to see a 180-degree hinge, personally, so that you could close it with the screens on either the inside or the outside, meaning that you could still use it like an ordinary tablet or E-reader. This form factor would obviate the need for Gorilla Glass, as well as enabling some interesting use cases – such as using it like a mini-laptop, with soft keyboard on the E-ink side serving as IME for whatever’s running on the LCD/LED. But it also introduces some awkwardnesses: other than specialized use cases like the keyboard, does the device still only drive one screen at a time? Or does it get into the same kind of split-screen craziness that the Sony did? And it obviously increases the build complexity.

What would it take to build any of these devices? Obviously, I’d require a hardware partner, some company with experience making white-label tablets but willing to build something outside the conventional box. And it’d take some Android firmware hacking to organize the “flip” – theoretically, I could do this part, but in practice, it’s not an area of the OS that I have any experience with. And finally, it’d require all the overhead that a hardware business always does, like inventory, distribution, marketing, and so on.

IOW, it’d need capital – either conventional venture, or maybe crowdsourced. But either way, you’d need to convince the backers that you had the means to pull this off.

I also suspect that a small, indie hardware venture like this would have trouble competing on raw specs with the big boys, and thus this device would be a tough sell to the average consumer. It’s already going to have higher manufacturing costs, just from the extra screen, and it’d also be at an automatic disadvantage in today’s thinness wars. It’d have the one really unique hook, but would that be enough to hang a device on?

So ideally, this device should be made by an existing hardware player, who can get that stuff right. The obvious candidates are Sony and Amazon – they have the E-ink experience.

But I’m afraid that I’m not the guy to drive it; it’s just too far outside my areas of expertise. And as a WAG, it’d take 18-24 months for someone like me to bring to market – by which time screen technology may well have overtaken it.


The vision here is satnav for pedestrians. Given a route (potentially just a GPX file), it would:

  • Show it to you on a map
  • Tell you where/when to turn
  • Include a “background mode” that would vibrate/ping you when you need to turn, or when you’re off course
  • Show nearby services

Could be fed by either raw GPX, GMaps walking directions (I’m assuming the APIs are compatible), or GPX + auxiliary data. This last case could involve things like written directions (Turn left on Oak Street, go through the hand gate, etc.), specific nearby attractions (restaurants, bars, hotels, …), or whatever. They’d either be tied to specific points in the directions, or just geolocated so the app could show & tell you about them.

So initially, this app could be fed both by existing crowdsourced GPX repos, and by GMaps directions. For directions augmented by aux data, this could either be crowdsourced again, or could come from professional writers in the form of an e-guide that you’d buy and download. For the crowdsource option, I envision it being run quite like an app store; essentially anyone could register as a “publisher”, upload e-guides, set a price, and sell them. Buyers would get to rate and comment on them.

Target markets would be hikers, as well as pedestrian travelers of any sort. [Visiting Munich? Buy the e-guide to the best beer halls!]

From a tech side, it’d require:

  • A good mapping app, including offline maps – for use in the backcountry, or foreign locales – as well as a selection of different basemaps (GMaps, OS, USGS Topo, etc.). It’d also be cool if it had some high-contrast option for better direct-sun readability.
  • The various navigation modes. Background mode seems particularly interesting, because you’d want it to work something like: wake up every 5-10 minutes, get a quick GPS fix, make sure you’re still on course, then go back to sleep to save battery. Wake time could be adaptive, so it’s awake more in the vicinity of turns you need to take, for example.
  • The e-guide store, perhaps just in the form of a mobile-optimized website. This store should also be accessible from the desktop web, including:
    • facility to buy e-guides and send to a registered device. As a first step, this could just be an email with a clickable link to the download
    • management of the e-guides you own
    • publisher tools (especially if we go the crowdsourced route)
  • On-device management of e-guides

Could the on-device client be built entirely as a web app? Possibly, but this introduces additional challenges, like offline storage of maps & routes, and fine-grained control of GPS. I don’t know that a web app can set an Alarm in Android, for example. Might make the most sense as a hybrid app; do some bits in HTML5, for easier portability, and then code fully native bits where you need to. And yes, this one really should be cross-platform, not just Android.

But I also have this vision of a hardware aspect, running Android (of course), as the Kindle to my e-guide books… I see a waterproof/semi-rugged device with a 5-6″ daylight-readable screen, and packing enough battery to run GPS+Glonass for 10-12 hours continuously. Heck, my ForeRunner can do that, why can’t a phablet?

Even if I don’t do my own hardware, there definitely seems like an opportunity to pitch it for OEM inclusion on devices like the Motorola Defy series.