Hacker News Reader

Comment by gojomo | Hacker News Reader

It'd be ugly and put other burdens on the pricing strategy and support permutations, but perhaps app-makers so trapped could approximate their desired result via:

(1) offer a reduced-functionality "version N" to everyone, but for the desired 'upgrade' price. (Essentially, this might only have the features of the prior N-1 version.)

(2) offer an in-app purchase unlocking full/pro features, priced at the delta between their desired "full Version N price" and what was already paid

(3) give owners of the previous "N-1 Version" a code that gives them the in-app purchase benefits for free

Maybe Apple would still object... but since the entire process happens inside Apple's system, paying Apple's commissions, advancing the use of Apple's in-app purchase mechanisms, maybe they'd be OK with it.

View on HN

How do you propose accomplishing (3) that isn't a difficult confusing mess for users and verifies they are indeed an owner of the n-1 version?

The prior version creates a unique proof-of-ownership code (perhaps on request, after consulting the vendor's server).

That code is either cut & pasted, or custom-URL-handler'ed, over to the new install, unlocking the same features as an in-app-purchase. (Or maybe there's a bounce through Safari, somehow leveraging its offer-to-launch-or-install functionality to minimize the steps, or through the vendor's own servers keyed by opt-in email address. Lots of possibilities, really.)

As I said in my other response it seems likely Apple won't allow these upgrade schemes any more than they are allowing Omni to do upgrades around the App Store. Why would they block what Omni was doing entirely outside of the App Store and allow apps distributed through the App Store to accomplish something similar?

Because outside the App Store, Apple doesn't get their cut, and external payments or software-deliveries don't bind people to the habit of App Store purchases and in-app purchases.

With this pseudo-upgrade process, even as convoluted as it is, it all remains inside Apple's system.

I suppose the key question is: does Apple allow promotions that give some people the same effect as in-app purchases, while others still have to make the paid purchase? (I think they do.) I could see Apple objecting if the feature-turn-on is in any way a reward for outside-of-App-Store valuable behavior - that's circumventing Apple's role.

But if it's an extra bonus for an earlier in-App-Store action – the N-1 version purchase – Apple's role hasn't been circumvented. In a way, it's been reinforced. So the same logic driving the prior veto wouldn't apply.

Perhaps. It's an interesting theory. I've seen it claimed in the past that Apple has given explicit permission to activate in app purchasable features through other means such as contacting a developer's server with an unlock code. I'm still leery of going through the effort to build and support a kludgy solution like that and still have the risk of Apple not approving of it.

If you planned ahead, you could keep a version log somewhere inside the software showing which versions they'd had installed. Or, you could have each new version installed 'phone home', maybe ask users to 'register now for free/cheap upgrades later!'. All of them have drawbacks, but would get a significant chunk of the desired experience.

The drawbacks are pretty significant. A lot of users really aren't that savvy or motivated to register ahead or deal with some complicated upgrade process. If you have an app that's been in the store for a while it's even more problematic since more users have old app versions. Anyone that gets a new device and wants to install the upgraded app would have to install the old app version or go through some other odd process if they want to activate the upgrade. Also it seems likely Apple won't allow these upgrade schemes any more than they are allowing Omni to do upgrades around the App Store.

Reply on news.ycombinator.com