I am creating non renewable subscription for one of my application.
I have read document that if I implement non renewable subscription then I have to write code to expire it from server side.
I am all done with it.
But I am little bit confuse that If I am going to purchase that item once its expired the alert says as attached in image. That means it will restore the non renewable subscription or it will purchase a new one?
Also another question I have read that on stackoverflow that If application is providing non renewable sunscription that it must has optional registration flow is it true?
About your first question, non-renewing subscriptions can not be restored or sync via the usual Apple way of providing restoring/syncing between devices. You have to provide your own mechanism.
You can check this documentation and judge yourself how you want to do it.
You can sync and restore non-consumables and auto-renewable
subscriptions across devices using StoreKit. When a user purchases an
auto-renewable or non-renewing subscription, your app is responsible
for making it available across all the user's devices, and for
enabling users to restore past purchases.
Regarding your second question:
You can check how your app relates to the following entry in the review guidelines.
"(v) Account Sign-In: If your app doesn’t include significant
account-based features, let people use it without a log-in. Apps may
not require users to enter personal information to function, except
when directly relevant to the core functionality of the app or
required by law. If your core app functionality is not related to a
specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.),
you must provide access without a login or via another mechanism.
Pulling basic profile information, sharing to the social network, or
inviting friends to use the app are not considered core app
functionality. The app must also include a mechanism to revoke social
network credentials and disable data access between the app and social
network from within the app. An app may not store credentials or
tokens to social networks off of the device and may only use such
credentials or tokens to directly connect to the social network from
the app itself while the app is in use."
Related
I have a question about apple review system.
I have a website where user can subscribe to different plan through 3rd party (the subscription is linked to user’s account) to access to some content.
I have also an iOS application that not let user subscribe to this plan directly from the app (just an informative message to says user that subscription must be made from my website, and their is no redirection to my websites like spotify do it).
Is the application will be rejected because it’s not use In App Purchase ?
Thank you for answer
You should use In App purchase for this purpose. If you don't, your app might get rejected with the following response from Apple.
We noticed that your app contains a payment mechanism other than in-app purchase for digital content or to unlock features or functionality within your app, which is not appropriate for the App Store. In-app purchase is the only valid in-app payment mechanism for digital content.
Note: Continuing to hide functionality within your app or other dishonest acts may result in the removal of your apps from the App Store and termination of your Apple Developer Program membership and all associated memberships.
Next Steps
To resolve this issue, please remove all external or third-party payment mechanisms and implement in-app purchase to facilitate digital good transactions, including unlocking features or functionality within your app.
If you believe your use of an alternative payment mechanism is a permissible use case, please respond directly to this message in Resolution Center with detailed information.
you may visit it for further information and guidelines.
https://developer.apple.com/in-app-purchase/
My iOS app update just got declined due to the fact that we are prompting users to register before they purchase a subscription.
Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage
We noticed that your app requires users to register with personal information to purchase non account-based in-app purchase products, which does not comply with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app content and features that are not associated specifically to the user.
Next Steps
User registration that requires the sharing of personal information must be optional or tied to account-specific functionality.
To resolve this issue, please make it clear to the user that registering will enable them to access the content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional iOS devices.
Please note that although guideline 3.1.2 of the App Store Review Guidelines requires an app to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
Ok.... I understand they are trying to make the best experience for the user, but the final requirement seems contradicting.
Does anyone know how I'm supposed to provide the subscription content available to all iOS devices for a single user, without requiring them to create a user? How can I make content available to the user across all of their devices if there is no user account?
This is directly related to apple updating their guidelines.
Apps that authenticate or set up user accounts must support Sign in with Apple if required by guideline 4.8 of the App Store Review Guidelines.
I’m not exactly sure when they made this update. But I recurved and email on 3/27/2020 stating that they had extended the deadline for apps to implement this change until 6/30/2020
I'm am currently implementing the multi-app subscription model for iOS apps. I have 4 apps that I want to interconnect with the same subscription. So far, the subscription works individually inside each of them and I have a backend server that receives status notifications about subscriptions.
In the Apple docs, they mention that the user should be identified by some sort of credentials between apps to know when a user has bought a subscription in one of the apps. The question here is can we use the user's app store account to identify it instead of creating custom credentials. I find it easier for users to only have their native account to work with instead of having another in-app account.
Is it possible to trigger the native iOS login box?
Thanks!
I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
3.1.3(b) Multiplatform Services: 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.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.
We are a website based service. We do not charge for accounts. We charge for services the user selects to do (such as exporting data). We collect money through our website and store that as credits in our system.
We have built a free app app and have been updating the app.
We would like to provide a user sign up in our app. We are having troubles figuring out if Apple will take issue with that. We understand if we sign up a new account in the app, Apple will take a 30% cut (ala Spotify).
The question is how do they handle free accounts?
EDIT:
Our app currently lets the user charge for services against their current credit balance (such as exporting a file) and have not had an issue with that in 4 years we have been doing it.
EDIT 2:
At one point, they did reject our App for hot linking to our website. That was 3 years ago and I forget if it was because they could create a new accout or could add credits to their account. I can't find a way to go back and look up the rejection notification.
Accounts are unrelated to purchases. Purchases and accounts are often used together, but this is a convenience and not strict requirement.
In your case:
The user may access the app with an account.
No payment is asked for the account.
Through this account, the user may receive content which has been paid for by credit card.
Credit card details have been submitted through your web site.
This is ok, as long as you do not take credit card payments in the app, or provide any buttons or links to credit card payments, from in the app.
According to the App Store Review guide.
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. Any credits or
in-game currencies purchased via IAP must be consumed within the app
and may not expire, and you should make sure you have a restore
mechanism for any restorable in-app purchases. Please remember to
assign the correct purchasability type or your app will be rejected.
Apps should not directly or indirectly enable gifting of IAP content,
features, or consumable items to others. Apps distributed via the Mac
App Store may host plug-ins or extensions that are enabled with
mechanisms other than the App Store.
And
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically:
magazines, newspapers, books, audio, music, video, access to
professional databases, VoIP, cloud storage, and approved services
such as educational apps that manage student grades and schedules),
provided the app does not direct users to a purchasing mechanism other
than IAP.
In other words, users may access content that has been paid for outside of the app.
If the user is directed by the app to pay for something, then you may not use external payment services, and you must use In App Purchase.
So, hot linking to your web site from your app to accept payments is not allowed, whereas downloading content which has already been paid for through your web site outside of the app is allowed.
If in doubt, contact Apple directly through their support form, or the Apple developer program technical support.