Put the knife down and take a green herb, dude.
One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white.
MarkUpDown is the best Markdown editor for professionals on Windows 10.
It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.
Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor.
Stop looking. MarkUpDown is the app you're looking for.
|Wednesday, August 19, 2015|
Whoa. Any time you blame Apple, take a step back.
Aren't there ways to provide paid upgrades? I mean, really, is it that complicated to dream up a way to include paid upgrades using In-App Purchases (IAPs)?
I understand that the MAS doesn't have a simple mechanism for making app upgrades, and is pretty clearly trying to, at least implicitly, encourage you to make software that your user buys only once and receives free upgrades forever. I understand that this isn't sustainable for indie devs, but I also know we're smart enough to work around it.
The problem's solution
So let's say I was, I don't know, writing an email client that I release just before or during 2016, and it costs you $55. It turns email from timesink to a thoughtless extension of your mind, and you can't stop yourself from clicking Buy.
During 2016, I code like mad and add a host of new features. Heck, let's get crazy and say I rewrite the entire app (btw, never do that). Now I want to release EmailClient 2017 for $55 for new folks, but only $10 for you, my loyal customer.
Seems easy on its face, doesn't it? I keep EmailClient on the MAS. It now has an IAP called, "Super Groovy 2017 features" that runs you $10. But, get this, if you never had the app installed, you get these features for free! Wait, what? Wacky, huh?
The "only" problem is implementation, and yep, it's a problem. But isn't that what we do? We solve coding problems.
How could we do it? Well, if you have an email client, you have all sorts of methods, the most straightforward probably being to save a hash to a sandboxed folder with some user-identifying info, some salt, and the date of first use. And any app could do this reasonably safely, even without a simple web service, making the unlock of new features difficult, though obviously not impossible, to crack..
Poof. We have upgrade pricing. Right? I mean, it's a little code smelly, but we have it.
EDIT: I guess there's one issue -- we'll have an IAP those users don't need to buy. That's a tough call; I haven't played around with IAP on the MAS yet. Any context there? Can you hide an IAP inside of the app? Or direct folks directly to the IAP? I think the only IAP I've done is a tip for Pedometer++, and it seems like he had links to each option, which is very much like the prereq IAP stacking I mention, below.
The absolute worst case here is that we have to ship two apps painfully grafted into one. I've heard horror stories (particularly from the Core Intuition folk, if my memory serves) of moving from long untouched libraries to the recent ones, keeping old versions of XCode and OS X laying around to do emergency patches, and other related issues. I'm not sure you could ship some of this obsolete stuff easily in an app that's targeting 10.11.
Which brings me to the other upshot of this plan...
Eventually you're going to give it away for free
Maybe not in 2017, but at some point, maybe three releases later, I'm going to give everyone what's in EmailClient 2017, and give it to them for free. That is, you don't want an IAP list that says, "EmailClient 2017 Features, $10 -- EmailClient 2018 Features $10 -- EmailClient 2019 Features $10". If they didn't upgrade in 2017 or 2018, sort of like the license crackers, are they really in your market? They paid once. Why not give them a two year-old set of features?
And there are going to be times when it doesn't make sense to keep bundling together Frankenstein with the original parts. Occasionally, you might need to update EmailClient Y-1 to keep the tech stack in line with this year's EmailClient Y, but now that releasing grafted upgrades is your actual strategy, you can code defensively so that you minimize code that goes obsolete next year. Sometimes it's not going to be worth the trouble to make Y-1 play nicely with Y, and you'll be stuck. Let's just hope that, for the most part, your code from last year doesn't go obsolete within 24 months in impossible to fix ways too often.
I'm not sure if you can "stack" IAPs -- that is, require that users have EmailClient IAP 2017 before they can see EmailClient IAP 2018. I'm guessing you can't create "prerequisite IAPs", or I would've heard of a game doing it somewhere. "Want 400 gems for $5? You can, but first you've gotta buy 100 for $10!" Or worse: "$20 to unlock 1000 gem packs for $1!"
But not having IAP prerequisites isn't that bad, is it? And if things ever get so gnarly that you don't want to give something away for free, well, you have other options.
There are nearly limitless ways to approach this problem. And, again, that's what brings us to the keyboards each morning, right? Fun, clever solutions to real-world problems. I mean, heck, Overcast already figured out how to perform an end-run around trial apps. Why can't we do the same for paid upgrades?
Which is not to say the MAS doesn't still stink for new releases. This ycombinator comment in particular pains me:
I can see that. I wonder what percentage of folks review what kinds of apps. I have no idea.
I guess this just gives more weight to the lesson I hear everywhere: You have to advertise outside of the MAS to sell MAS apps. The MAS is one and only one of your storefronts (was it Liscio who built up this metaphor? He's been everywhere (#70) recently). You send trucks full of software there, but you're still responsible for convincing people they want to buy. If you count on Wal-Mart's shelf placement to sell your goods, you're not doing enough to grow your business.
Which is not to say we shouldn't keep challenging Apple to make the stores better. Which was Counsell's point all along, I think.
(Btw, if this is the first time you've read my blog, there's a decent, just under 110%, chance you won't want to read everything, which is pretty heavy on "notes to self" style posts. You might prefer to watch just the indie tag instead.
Unless you're Sam Soffes, in which case, if you're not as laid back (in that good way) as you sound, you might take this post badly. But then you could destroy this site's beautiful design, basically unchanged since 2001, and make up for it pretty quickly.)
Yes, the parenthetical in the title is supposed to remind you of Loser.
 I think it was Charles Perry's AltConf talk that had some number like 0.01% of surveyed iOS App Store authors considered their apps financial successes. If you ask me, that's a pretty good explanation for all the abandonware. That and the fact that as the store progresses, by definition there are going to be more abandoned apps. I'm guessing there are very few resurrections. So don't get too down on the app store yet! (Perry's slide is below. Go watch his talk, and then a few more from AltConf too!)
 Now is as good as any to admit I'm a C# guy just starting to write for OS X. Yes, I'm using Xamarin in the hopes that makes going crossplatform much easier. That said, I've used Macs for years, and have even contributed to a few Mac sites and a [trivial] piece in the Mac Bible's 6th edition, but in many places here, I'm talking without platform-specific knowledge of what the implementation would require.
 I've been told that a lock is designed to keep an honest [hu]man honest. I think that's fair. We're doing the same thing here, because, honestly, what percentage of crack-artists were going to pay for your app? It's not zero, but it's also not close to 100%.
 If you find that your code is going obsolete every 18 months, you might need to reconsider your dev workflow. ;^)
posted by ruffin at 8/19/2015 02:03:00 PM
All posts can be accessed here:
Just the last year o' posts: