Apple in-app purchase logo

How Apple could fix the in-app purchase issues


Apple in-app purchase logoThe issue

These days Apple is under pressure from angry parents for their handling of in-app purchases (IAP). See this article on Apple Insider for more information on the subject.

In brief: parents are suing Apple for allowing children to purchase content within apps too easily.

Whether Apple should be held responsible for this or not is debatable. There are options to turn off completely the in-app purchases or ask for a password for every purchase instead of allowing the default 15 minutes window of purchase.

All that matters is that Apple was denied their request to dismiss the case.

How do children come to purchase content worth sometimes hundreds of dollars? The usual scenario is as follow:

  1. Kid asks parent to download a new game.
  2. Parent checks the App Store and finds a free game that looks like a nice cute little kid game. And even better, it’s free!
  3. Parent downloads the game after entering their iTunes password (common procedure for both paid and free apps).
  4. Kid starts playing the game. Soon, the game advertises the possibility to progress more quickly by using a hard currency (some currency that can be earned exclusively or almost exclusively via IAP). The use of this currency is often demonstrated early in the game tutorial where players are provided some free units of the hard currency… which players quickly run short of.
  5. As soon as the kid tries to purchase that cute little building, animal, or item, a popup opens, informing the kid that they need more of the hard currency to make their purchase, while prompting them to buy more of it.
  6. Kid taps the highlighted flashy “OK” button, then is taken to a screen where they can choose the amount of hard currency they want to buy.
  7. Kid taps on the icon showing the biggest amount of hard currency (the one with –incidentally– a $99.99 price tag next to it).
  8. A confirmation popup opens, kid taps “OK” (it’s still within the 15-minute window within which users are not asked to input their password again) and goes back to playing the game…
  9. On their next credit card bill, the parents realize a huge amount of money was paid to a certain iOS game.

And that’s the case when the kid doesn’t know the iTunes password of their parents.

I am not here to say whether these parents should have been more careful or not. The point is that those aren’t isolate cases, so there is a real issue.

Ensues usually a witch hunt. Some blame Apple, other blame the parents and other yet blame the app developers.

How to fix it

Truth is, as a parent it’s not very intuitive to navigate the settings of your phone to restrict stuff for the case your kid will use it. Also, if you set up restrictions with password-protection on everything, you end up wasting your time typing your password over and over each time you want to use or download an app for yourself. I am sure some people can get used to it, but frankly it adds a lot of friction every time you pass your device to your kid. So how to make it easier AND safer?

Now, in all honesty, I am sure there could be many solutions to this problem but here is my take. It’s pretty simple, although it’s probably easier said than done:

Include multiple user profiles. Like on the Windows desktop OS. By default, there would be only one profile: in that case no change versus the current iOS.
However, users could set up one or more additional profiles for other users (especially their kids).

  • The kids would tap their own profile icon after turning on the phone, then would type their own password to unlock the device.
  • They would have access to the apps their parents would have set for them, with likely simplified or streamlined menus.
  • The profile would have its own age restriction and IAP settings.
  • To get back to the primary (parent) user profile and settings, just lock the device and unlock it again.

And that’s pretty much it.

Is that feasible? I don’t see how not.


  • KoreanWonders

    Disqus plugin test