Does anyone have experience implementing this in their apps? I wasn't able to find very much documentation on this topic. It looks like even RevenueCat hasn't implemented this yet. I did find a Google-cached page that contains a question asking whether they will support this. The response was that it's on their radar. But that page has since been removed leading me to believe they have abandoned this plan.
From the Apple documentation:
When providing auto-renewable subscription access across multiple
apps, you must authenticate the user in a way that can be correlated
across apps. Authenticating users via a login allows you to determine
if the user has access to the content. The login process should be
consistent across your apps.
But if you have this, what is the added value of this new subscriptions-across-apps feature? One could already implement subscriptions across apps this way. Is there some special identifier that links the subscriptions on Apple's side that allows users in app B to restore subscription purchased in app A?
Related
I'm changing one of my Mac apps from a paid model to a subscription model, by using auto-renewable subscriptions (IAP).
However, as the app is B2B, some users need to reimburse costs via their employer. While this is acceptable with payments only occurring once, with recurring payments this is simply annoying and sometimes even impossible.
Apple has a B2B Volume Purchase Program that supports companies to purchase a number of licenses and distribute this to their employees. However, IAPs (including auto-renewable subscriptions) are not supported.
I see this as a big limitation (especially knowing they take a 30% cut of sales) and the only way to solve this is to offer an additional mechanism to offer subscriptions next to IAPs, specifically for business needs.
My biggest concern is whether my app would be rejected because of this. I have been going through the (updated) guidelines and found some related items:
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. [...] Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
This will be the case, but not exclusively because of the above mentioned limitation. I won't include a "Buy" link to the alternative method. However, I will include a text indicating that if a company wants to purchase multiple license for its employees, it can do this via our website (using a payment processor such as Stripe). Via this website codes will be made available that can be entered in the app to activate the license.
Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.
The app is distributed via the Mac App Store and it seems that they are more flexible here. However, it's a vague guideline and I'm not even sure if it's related to the problem I'm facing. What does it mean?
Hoping to read your opinions and experiences here. Thanks.
I have been emailing Apple about this but they have never replied. Also asked this question on the Apple Developer Forums but didn't got any help there too.
Decided to simply implement it and submit it to the App Store. They have accepted it without asking questions so apparently it is allowed. Important to mention is that I have not included the payment mechanism in the app. It asks for a license code that will be validated using my own service. This service also handles the payment via a web page.
Hope it helps others.
Apple developers rejected my app with this reason.
"Business - 3.1.1
Your app includes an account registration feature, which is considered an access to external mechanisms for purchases or subscriptions to be used in the app.
This feature does not comply with the App Store Review Guidelines.
Next Steps
Please remove the account registration links and any other fully qualified links to your site that could indirectly provide access to these mechanisms, such as links to web pages for support, FAQ, product or program details, etc."
The users can use the app in demo mode (without registration) with some restrictions, but if they register they can use without registrations.
The registration is not in webview. The client sends the user's datas to server.
Can someone help me?
You basically have two ways to solve the problem.
1) Sell the subscription etc. only through the App Store in the app (similar to Dropbox/Office etc.), i.e. there should be no links to your website, where your users have/can insert payment information. Look at the mentioned examples, how they solve this.
2) Only sell the subscription/services via the web, but never ever link to these pages via your app (similar to Kindle app, partially Spotify).
Your app must still be somehow (open for interpretation) functional for users without a subscription / registration.
The main issue Apple has, is that it's possible to circumvent the store and Apple's 30% cut. Just make sure that users are not able to purchase any digital products & services
Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
Source:
https://developer.apple.com/app-store/review/guidelines/#payments
Yes, You can submit app again but you have to implement one small feature like as guest user login.
In this You will implement one UIButton it's should say "Go without login". Implement this small functionality in your app. Create one user as guest.
When user hit "Go without login" you will pass your static user id and login in the app.
I have same problem. I am create a this solution and it's work
I know, that this question is not directly related to any coding but there are several other question on SO about the App Store and its Guidelines. So I assume, this question is OK.
There are other questions about (more or less) the same issue. However they where asked / answered several years ago and the Guidelines have been updated since then. Additionally the circumstances are always a little bit different.
I am well aware, that nobody can give me any kind of guarantee on which interpretation of the Guidelines is correct. Not even Apple could do this, since everything depends on the review staff an its current mood. However It would help a lot get to know your opinion on what is allowed and what is not. Maybe you already encountered the same problem and have some useful recommendations.
The set of facts:
A Shopping List app is offered in iOS App Store. The app offers functions to create and manage any kind of shopping list. These functions do NOT depend on any external purchase. The fee version limits the number of lists. This limit can be unlocked using an In App Purchase.
There is also a WebApp version that offers the same functions (and a little more) as the iOS version. The WebApp has a one month free trial and can then be extended using a subscription model. Subscriptions can only be ordered within the WepApp, not from within the iOS app.
Both version can be used completely independent from each other.
Additionally the apps can be connected (REST API) to sync lists between them.
Obviously there are pages/controls within the iOS App, that allows to setup the connection (enter username, password, etc.).
Obviously the WebApp has to be described in some way to the user within the iOS App.
Once the free trial ended or a subscription has expired, the sync will no longer work. In this case the user needs some kind of hint why sync is no longer available ==> There has to be information about the subscription model of the WebApp and a discription on how to renew the subscription.
The "Problem":
The current App Store Guidelines are pretty vague on wether this kind of business model is allowed or not:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions,
in-game currencies, game levels, access to premium content, or
unlocking a full version), you must use in-app purchase. Apps may not
include buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
This paragraph is not as clear as it my appear on first sight. Unlocking functionality within your app is only allowed by using IAP. Fine, so unlocking a app feature (e.g. creation of more than 2 shopping lists) would be not allowed. But is the sync functionality I described before also covered by this? Of course there has to be functionality within the app to connect to the WebApp, but the complete sync logic is implemented on the server, not in the iOS app.
The functionality the iOS app offers is "Establish a connection to the WebApp". This functionality works independently from wether the WebApp subscription is active or not. Only the functionality of the WebApp changes depending on the subscription status (accept or deny sync requests).
So: Is it allowed to add some text like "There is a WebApp, too. Use this link to got to the WebApp. Follow this link to renew your subscription" to the WebApp or not?
Or is the part "Follow this link to renew your subscription" forbidden?
What makes the whole thing even more confusing is the following paragraph form the Guidelines:
3.1.5 Physical Goods and Services Outside of the App: 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 IAP to
collect those payments, such as Apple Pay or traditional credit card
entry. Apps may facilitate transmission of approved virtual currencies
(e.g. Bitcoin, DogeCoin) provided that they do so in compliance with
all state and federal laws for the territories in which the app
functions.
Does this read as "Physical Goods and physical Services" (e.g. postal delivery in contrast to digital Services) or this include all Services?
So, is the "WebApp Sync Service" covered by this paragraph and thus the usage of external payments not only allowed but necessary?
Of course I could ask these question directly to Apple. But I would never get an answer. Even if I would, this would still be no guarantee, that the review stuff shares the same interpretation of the rules. So your experience and opinion will be the best "guarantee" I will ever get.
Thank you very much!
I have two similar apps with in-app-purchase (IAP) content that could be shared between them. I'd like to reward customers who buy in one app, by letting them transfer the purchase to the other app. However, I'm worried that my apps would be rejected due to the App Store review guideline that says you can't have any non-App store content activation methods.
As far as technical feasibility, it's clear to me that the Document Interaction mechanism is a means to this end (sans web server). I can have each app register a custom file type. The app in which the user purchased the content can show a link to launch the other app, passing it appropriate metadata as the "launched file" so the second can then mark the items as purchased.
Does anybody know if this has been attempted, and if Apple is approving such an approach?
Note that I'm not concerned about purchase security with this approach, because making paying customers happy is much more important to me than preventing piracy.
This isn't so much an answer to the precise question above as it is a useful alternate technique of accomplishing the end goal. If you set things up correctly, two apps can share KeyChain access, and thus share metadata about purchased IAPs. This requires using the same Bundle Seed ID (e.g. "AXGUKHGX...") for the app ID, in combination with setting things up properly in your app's info plist. This latter technique is a much more elegant approach for propagating sharable IAPs.
The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?