I'm developing an app that allows users to subscribe to each other's content via paid subscription. For example, user A can subscribe to user B's channel for $5/month and I take a small fee from the transaction (user B gets the remainder).
Apple policy states that all in-app digital purchases and subscriptions must be done with Apple In-App Purchase, but does this include digital user marketplaces? I'm in the middle of implementing Stripe but I'm not sure if this is allowed.
If I have to use the In-App Purchases, does this even support my model?
Thanks!
If you want to facilitate the transaction through your app, then yes, it needs to be done through an in-app purchase. You can use Stripe for users that subscribe on your website, but you can't direct users there to make a purchase from your app.
Apps that operate across multiple platforms may allow users to access
content, subscriptions, or features they have acquired elsewhere,
including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must
not directly or indirectly target iOS users to use a purchasing method
other than in-app purchase, and your general communications about
other purchasing methods must not discourage use of in-app purchase.
With in-app purchases, you'll need to facilitate the payouts yourself. This could be difficult since you'll probably want to wait until Apple pays you before you distribute (usually 1+ month after purchase), and you'll have to track refunds and cancellations. If your app is available globally there's also the fact that you'll get paid out different $$ for the same subscription depending on the country it was purchased due to tax differences.
Also, since you can only be subscribed to a single product within a subscription group, you won't be able to have a user subscribe to channel A and channel B with 2 subscriptions.
Really, the best solution for this type of marketplace is to use something like Stripe Connect as you've figured out. However, you'll have to process this purchase outside of your app and not direct users there from within your app.
A solution to use in-app purchases could be to switch from a subscription to a consumable purchase to unlock content for a specific period and manage the expiration date yourself. This would allow a user to make multiple purchases to unlock multiple channels. The downside is that this won't auto-renew, which may mean less revenue for you. You'd still have to handle the payouts yourself, but it would be simpler to manage one-off purchases then dealing with all of the nuances of iOS subscriptions.
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
I am showing listing of the coupon/offers in the app. On clicking on same I am opening the particular merchant site in safari on the device and making redemption/purchase of the same coupon.
Can this lead to rejection please let me know.
Thanks in advance!!!
NO, if you are selling virtual goods then try to understand below things.
You can use in-app purchases to sell a variety of content, including subscriptions, new features, and services. There are four in-app purchase types you can offer.
Consumable
Users can purchase different types of consumables, such as lives or gems in a game, to further their progress through an app. Consumable in-app purchases are used once, are depleted, and can be purchased again.
Non-Consumable
Users can purchase non-consumable, premium features within an app. Non-consumables are purchased once and do not expire, such as additional filters in a photo app. Apple can host content associated with your non-consumable in-app purchases.
Auto-Renewable Subscriptions
Users can purchase access to services or periodically updated content, such as monthly access to cloud storage or a weekly subscription to a magazine. Users are charged on a recurring basis until they decide to cancel.
Non-Renewing Subscriptions
Users can purchase access to services or content for a limited duration, such as a season pass to streaming content. This type of subscription does not renew automatically, so users need to renew each time.
For more details, https://developer.apple.com/in-app-purchase/
Actually no, if you are not doing in-app purchase. And if your app have something that leads to in-app and to avoid apple in-app you diverting the user in safari then apple definitely reject your app.
In your case, it doesn't seems like the in-app purchase.
Make sure overall app quality and performance is good else apple reject app with other reasons also.
For further details go through this -> https://developer.apple.com/app-store/review/guidelines/
Best of luck!
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
My application currently allows the user to subscribe to our service using in-app purchase auto-renewable subscription. The app provides images, 12 images per month, and every month the user needs to renew his/her subscription to see the new content.
I haven't work on the auto-renewable model before, so I have built a model to validate the receipt and it works, but should I check if the user subscription expired or not, and, if so, how?
Also, does the app store only allow magazines and newspaper items to be auto-renewable?
I haven't worked on the auto-renewable model before, so any help on this matter would be highly appreciated.
When a user signs up for an auto-renewable subscription, they continue to be charged until they manually cancel it. This is obviously great from a developer’s point of view, because it takes a lot more effort to cancel something than to just let it continue.
You might already be familiar with a class of apps that use auto-renewable subscriptions already: Newsstand.
Newsstand was first introduced in iOS 5, and allows content providers to easily distribute their newspapers and magazines. With it, Apple introduced the auto-renewable subscription model, which allows you to set a subscription duration and manage renewals automatically through the StoreKit framework.
However, Apple has placed some very strict rules around auto-renewable subscriptions, meaning their usage is (usually) exclusive to Newsstand apps.
So sadly, if you want to provide content or features for a limited duration, outside of Newsstand, then your only option is to use non-renewing subscriptions.
found that here: http://www.raywenderlich.com/36270/in-app-purchases-non-renewing-subscription-tutorial
An auto-renewable subscription is an iOS In-App Purchase category that allows an app to provide and charge for content or features over a set amount of time.
Hear is a very useful link!. It provides almost every details about auto renewable subscription
Auto-Renewable In-App purchases continues charging the user (weekly/monthly/yearly etc.) until they cancel it.
You can check if the subscription has expired using the a validated receipt. It contains subscription expiration date and time.
If you want to lock content if subscription has not renewed, you may want to check receipt info against current date/time, on applicationDidBecomeActive delegate. There are open source libraries that lets you verify receipts locally as well.
And any kind of app can have Auto-Renewable In-App purchases, not just newsstand apps.
I was wondering how can I ask a user for credit card details and charge him without using Apple's in-app purchasing mechanism.
My idea was to post the user's credit card to my online credit billing system and make the transaction on the website, behind the scenes, and then report back to the user with the transaction results.
Will Apple approve this kind of app?
Apple will not approve such an app, unless users are purchasing something which cannot be purchased via an in-app purchase.
For example, a pizza store is allowed to collect credit card details to pay for pizza's. But a digital music purchase must use the in-app purchase system.
From apple's documentation:
There are four supported kinds of products that you may sell using
In-App Purchase:
Content includes digital books, magazines, photos, artwork, game
levels, game characters, and other digital content that can be
delivered within your application.
Functionality products unlock or
expand features you’ve already delivered in your application. For
example, you could ship a game with multiple smaller games that could
be purchased by the user.
Services allow your application to charge
users for one-time services, such as voice transcription. Each time
the service is used is a separate purchase.
Subscriptions provide
access to content or services on an extended basis. For example, your
application might offer monthly access to financial information or to
an online game portal.
Anything in that list must use the in-app purchase system, and anything else must not use it.
By the way, these things have changed many times, and could change at any time in future.