IAP subscription Payment outside of Apple ecosystem

I suggest seeing how section 3 (especially items 3.1.1 and 3.1.5) from the following link applies to you.

(There are a lot of details, but the general guideline seems to be: if you use the purchase in the app you need IAP; if you use the purchase outside the app you can't use IAP.)

http s://developer.apple.com/app-store/review/guidelines/#in-app-purchase

Hi pmills,

Thanks for the help here.

3.1.5 (a) If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.) - this is a YES. We would have the same subscription offerings on a website counterpart to the iOS app. So, users can use the same account that has an active subscription to view video content that is identical in the iOS app or our website.

3.1.5 (b) Cryptocurrencies: this is a negative. We are only using PayPal or Credit Cards to collect subscription payment.

3.1.1 In-App Purchase - seems a bit more broad. "If you want to unlock features or functionality within your app, (like subscriptions) you must use in-app purchase." Since we offer the same subscription and video content on a website counterpart, 3.1.1 and 3.1.5 seem to directly conflict with each other.

I am thinking that, because we offer the same subscription services and video content on both iOS app and a website, this should allow us to display payment options in the iOS app with a webvite to collect PayPal or credit card info. Am i wrong in this assumption do you think?

The question is whether it is 'physical stuff used outside the app' or 'digital stuff used inside the app'. The fact that the digital content is used both inside and outside the app does not allow you to purchase it through means other than IAP - 'but officier, I was only going 25 mph before I sped up to 90 mph'. The one exception is a reader app (3.1.3) in which the app just displays purchased content. The rules for a reader app are described in 3.1.3.

I assume your users are using iOS devices, the app was developed using Xcode and you are going to distribute and bill through the App Store. If so, 70% is a pretty big fraction of revenues.

PBK - hmmm good point w the speeding analogy.

Yes, our users will use iOS devices for this app (among others, Xbox, desktop, Roku, Android, FireTV etc etc).

Yes, our devs used Xcode. But we are NOT going to bill thru the app store. We already have a 3rd party billing set up.

Let me back up a bit. Our app is currently in the store and live. We have 3rd party billing and charging already in place and its not thru Apples IAP or tied to users Apple IDs at all.

But, the way we have it set up has a LOT of friction for new user sign up. We have to tell them in our app that they need to go search out our page. Apple will not even let us display the exact URL for this (weve been rejected for displaying a URL previously). From our website is where they create an account and set up their payments.

What i want to do, is make signing up easier for the user. I want to be able to allow users to create an account in the app. And set up PayPal or Credit Card, thru our existing system. Both of these actions, im hoping can be done in a webview (in the app).

I dont want to go down this path and do all the dev work and then have Apple reject it.

Thoughts / comments? 🙂

Thanks!

Again, you can operate as a reader app or you can use IAP. If you operate as a reader app then you have already discovered what you need to do...."weve been rejected for displaying a URL previously"....

If your goal is "make signing up easier for the user" then use IAP. If your goal is "bypass the 30%" then stop saying your goal is to make signing up easier for the user, ignore the user and go for that extra 30% (actually it's not really 30% because you have to pay the credit card company a few percent and there is an administrative burden - it almost makes the 30% fee worth it - especially when you add in how many more users you will get when you 'make signing up easier for the user', and autorenewable subscriptions and....).