In-App Purchase In Free Apps: A Shot Across The Bow of iPhone Piracy?

Next Story

Unsurprising: TI doesn't approve of calculator hacks

bangbangship

Just hours ago, Apple made an announcement that has developers everywhere dancing down their collective, metaphorical street: In-App Purchase is now good to go in free applications. This, of course, comes just months after Apple essentially told a room full of journalists that such ideas were nonsense – that free apps should always remain absolutely free.

Still – hindsight is always 50/50, or whatever that saying is. There were really just too many advantages to allowing it to let it pass by any longer. Freemium applications! Upselling! It made In-App Purchases seem less tacky to the user! Hurray. But there’s one major factor that isn’t quite so obvious; one issue that this, to some limited extent, solves: piracy.

Now, I’ve said it before, and I’ll say it again: none of us here, nor the vast majority of people reading this, are e-saints. When piracy becomes as convenient as it is today, damned near everyone pirates. Even as a developer who was raised around developers and hangs out primarily with developers, I don’t see piracy as a primary issue damning us all to a life of bread lines and soup kitchens.

That said, the statistics are quite depressing. In a post a few days ago, I mentioned that Beejive, a popular IM client for the iPhone, was seeing piracy rates as high as 80% amongst their user base. Many of the comments on that post suggested that if BeeJive was cheaper (It’s currently $9.99, but has gone for as much as $16.99 since launch), less people would pirate it. Unfortunately, that’s just not the case: we’ve talked to developers of applications pinned all across the pricing spectrum, and they’re all reporting the same 70-80% piracy rate.

Unfortunately (or fortunately, depending on where you stand), there has been no easy way to combat this. You can code your app to check for certain key indicators that the user is running a cracked version, but that leads to false positives, angry users, and is generally just incredibly flaky. You can try to encrypt/decrypt everything on the fly after positively confirming that the user is a valid one , but that destroys performance, drains battery life, and is.. well, it’s just absurdly friggin’ ugly. Oh, and both of these methods can still be cracked, with enough effort.

So where does In-App Purchase come into all of this? Here’s the trick: while you can crack an iPhone application and throw it up for all to download in a matter of seconds, you can’t fake an In-App purchase receipt. A pretty notable chunk of the In-App purchase process is actually handled on the developer’s server, in addition to Apple’s – so unlike the initial purchase (which devs actually get to know very, very little about), developers know pretty damn well exactly which iPhones should be running which In-App Purchase. Developers have a specific receipt for each in-app purchase, which resides on their server. Faking this would be like tricking Amazon into shipping you a TV that you didn’t pay for.

By utilizing this receipt, network-centric applications like IM applications can knock piracy rates down to trivial numbers by simply shifting their model: don’t sell the user the application, sell them the service. Give them a very, very basic version of the application out of the box for free – but if they want more functionality (in this example, that would be the full version of the IM app), they need to drop a few bucks before the server will allow them access that functionality. Once the logic for who does and does not get access is all moved server side, pirating an application becomes monumentally more difficult – you’ve either gotta figure out a way to exploit the server, or reverse engineer its workings, rebuild it, and point the client that way, instead.

With all that said, there’s a flaw in this idea: once you require server-side authentication, you’re requiring network connectivity. That’s not an issue for those apps that already require connectivity to be useful, such as IM clients and a number of other genres – but for single player games, it’s just not okay to demand the user to be online every time they play. Do that, and you’re bound to upset the very, very vocal anti-DRM crowd.

Oh well – at the very least, it’s a start. Your thoughts?

blog comments powered by Disqus