July 13, 2018

iOS in-app purchases incompatible with any other payment systems for multiplatform tools?

I am about to release the mobile app for everydayCheck and I'm having problems with the review due to point:

3.1.1 In-App Purchase:

If you want to unlock features or functionality within your app, (...) you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc.

Right now I allow payments from Stripe on the web app, from android in-app billings and from iOS in-app purchases. Without redirecting anyone to pay from anywhere. The problem is that iOS seems to want to have full control and want all the payments go through the iOS app. My question here is, how do multiplatform companies such as Todoist handle this? They package all their platforms together under a single premium account, however, there might be people who start using todoist via web and pay there before even downloading the iOS app.

Technically, it's no issue, the problem is how do you get your iOS accepted when premium payments can be also done from other platforms?


  1. 2

    For anyone else stumbling into this issue, I tweeted to Amir from Todoist.com and he answered this: https://twitter.com/amix3k/status/1017796669524627457

    So I'm crossing my fingers waiting for the app store review answer :)

    1. 2

      This is so wonderful to see one Indie Hacker help another.

      I had the same question for my project (www.tribefive.me for reference) but decided to punt on it for now since we only launched with a free version.

      You just saved me multiple hours of research =)

      1. 1

        yes!! I'm becoming some sort of expert with the app store and google play so feel free to get in touch when it's your turn to go through this via crucis haha

        ps: just be careful of what you give for free because you wont be able to put it on a pay wall afterwards. (just in case you were thinking about it)

        1. 1

          Thanks for the willingness to help.

          We got through AppStore submission very quickly. Actually, we put v1.0 into review expecting it would get rejected just so we could know what we needed to fix before the "real" submission. However, v1.0 got approved in ~24 hours! Now we pushed out v1.1 and v1.2 and each one had ~24 hour turnaround with no questions asked from the Apple review team.

          Can you elaborate more about limitations later as a result of launching free right now? For Tribe of Five, all the 30 day challenges are free right now. In the future, we want to try charging for them.

          I might be misreading, but seems like you are saying I won't be able to charge for them later? If so...uh oh!

          1. 2

            damn you got lucky, my experience is pretty different, but I guess it has to do with the fact that I tried to launch with in-app payments from the beginning.

            Gotten rejected several times and now it's gonna take a few days because they really want to make sure I'm not breaking any of the in-app payments guidelines. (Thus, this post)

            Take this with a grain of salt but the way I understood the guidelines and everything I read, once you open certain features of the app for free, you cannot charge for users to access them in the future. It's the same idea as you have to grandfather users at the time to change the pricing, i.e users who paid say $5 when you later want to charge $10 for the same features. The difference is that I'm not sure you are allowed to grandfather free users. Just be careful with this... You might have trouble with future reviews when you introduce the in-app payments. On the other hand, I'm pretty sure you can find easy workarounds, i.e rebrand the type of challenges you want to charge for as if they were a different feature or who knows, maybe they oversee it... but frankly, they are really being very picky with my app so I'd be cautious!

            1. 1

              That makes sense that the bar for free apps versus paid apps is significantly different.

              Thanks for the tip - I will read much more into them Apple guidelines and limitations.

              Best of luck with the next review!

  2. 1

    You just need to store the information about the registered users.

    Example:

    1. user buy on web

    2. user logs into iOS

    at this time you know that particular user has already got a "pro" plan, hence you simply unlock what's needed.

    iAP is just a way to make payments, but it doesn't bind to the actual UX. Just make a backend check upon login and you are good to go.

    1. 1

      Thanks Tommaso, my questions was not so much about how to pull it out technically but about if it was breaking the App Store guidelines and therefore, apple could reject the app.

      I added a comment with what Amir from Todoist answered me that is quite helpful and reassuring! :)