The appstore guidelines states, "If your app supports account creation, you must also offer account deletion within the app."
https://developer.apple.com/app-store/review/guidelines/#5.1.1
My app only needs the name and email address of the user for the sign up process. The name is only for greetings; so maybe I can bring it down to just the email address.
Assume the app gives a free trial of a service for 30 days or so. How can I prevent the same user from signing up again for free trial once the account deletion is implemented?
Is soft delete an option here? How would apple know if we are actually deleting account data or just soft-deleting it?
Related
We have a app with a auto renewable IAP for which we offer a initial trial period to the user and charge once the trial period has expired. Our app maintains user account management(user login) and all features (including the IAP) are accessible only when the user is logged in.
There are two scenarios to consider:
Case 1: A new user(app user) opts to purchase the subscription for trial period on a device where she's logged in with her apple id. She later(post expiry of the trial period) installs the app on another device and signs up with a different app account but uses the same Apple Id. Since Apple Ids are opaque to the app, the app has no way to know that this user has already purchased trial, so the app UI presents them an option to start with a trial period. Since the Apple Id used is same, the user will be charged.
Although, this scenario is rare and can be justified on the pretext that the same Apple Id is used so the user is supposed to be charged, but it is fallacious on part of the app to suggest that trial period is available for the new app user(different login id)
Also, the user might not be intentionally doing it to avail a second trial period, but might have forgotten about the previous purchase and may use an alternate email next time they sign up.
How do you prevent the user to be charged if they have already used up the trial for the same Apple ID, or if there's a way to know if the current user(Apple ID user) has already made this purchase in the past, so that you do not show them trial option anymore. Would restore purchases help in that regard?
Case 2: The same app user may intentionally change the apple id on the new/same device to avail multiple trials. While your app will detect the user has already purchased the trial, you may choose to let the user not show the subscription purchasing UI but if you do the purchase workflow on part of Apple would still consider it to be trial period(new apple id) and not remit you the payment for the same.
How do you circumvent these conditions or if there's a flaw in my understanding where these situations would not occur at all.
For case 1: maybe the following may work, but not sure:
Whenever there's a new login to the app, the app should either refresh receipt or ask to restore transactions to the user(this can be frustrating for actual first time users) and the receipt validation should be performed to check if the user had previous purchase and if the transaction id is linked to some previous user. This is basically a kind of self managed restore. But still in this case, the new user will not be able to get the trial period, you can just prompt that the current apple id is already used for trial.
Please suggest if my understanding is correct.
My problem:
I am having a hard time figuring out a way to safely manage auto-renewable subscriptions in iOS with Firebase.
Purchase process:
User1 purchases a subscription
Update User1's account on Firebase w/ the subscription identifier
(used to unlock content)
Store original_transaciton_identifier(OTI) w/ uid of User1 to match w/ receipt verification from Apple.
Grant user access
Edge cases causing my brain to implode:
User1 logs out of AppleId used to purchase subscription, but remains logged in to app w/ Firestore credentials.
Therefore, when I go to verify if the subscription has expired it does not return a valid subscription. I want the user to be able to keep their access until it is expired or canceled. Any tips on achieving this?
User2 logs into the same device User1 was previously using.
Therefore, the same AppleId is being used for both users. I can check if the current user has a subscription, and check the OTI to see if it corresponds to User2...which it won't.
We will show the 'purchase iAPs' screen, but what if this user wants to buy a subscription as well under the same AppleId? Is it normal for me to handle this saying, "Apple Id already connected with another account or something"?
Relevant articles I've been able to find:
How to tie auto-renewable subscriptions to in house user, not appled id
I've been struggling with this for sometime and haven't been able to find many resources. All help is appreciated.
For case #1:
When you attempt to access the receipt Apple will trigger a login prompt for the user to enter their iTunes credentials. If a receipt is still unavailable, you won't be able to verify the subscription status. The "right" way to do this is to store the entire receipt on your server, and periodically refresh it with /verifyReceipt. You'll check if the subscription was cancelled, and update the expiration_date so you know when to cut off access for the user.
For case #2:
Is it normal for me to handle this saying, "Apple Id already connected
with another account or something"?
Yes! If you're able to look at how some other large subscription apps handle this (Netflix, Spotify, HBO, etc.) - it's similar to what you describe. Instead of checking the receipt locally every time, if you maintain the subscription status on your server (as mentioned in #1) this would only happen if the user tries to "Restore Purchases".
This is a pretty extreme edge case, since not many people try to make a purchase on their friends phone and would require TouchID/FaceID in most cases - so it's more of a fraud prevention feature. Once you get millions of users you can get fancy and send them an automated email link to signup with Stripe if you detect this.
Alternative:
RevenueCat can handle all the subscription tracking and these edge cases out-of-the-box, and it plays nice with an official Firebase integration. Disclaimer: I work there.
Background:
I am trying to implement In-app purchasing for my iOS app. The app allows the user to be able to log in to multiple accounts and register multiple accounts. Each registration will require the user to pay a subscription fee (unless a free plan is selected). When the registration is complete the account will be linked to the Apple ID that paid for the subscription.
Question:
If already have done a registration with my current Apple ID(Account A) with a $0.99 subscription every month and then do another registration with the same Apple ID(Account B) with a $1.99 subscription every month. Both accounts have purchased a subscription with the same Subscription Groups. In that case will that Apple ID just be paying for the subscription of Account B since it would be considered an upgrade from Account A.
I can make it so that when an account is created with an Apple ID that have been used, we link the new account with that Apple ID and disable the older one. This would however provides a bad user experience and only ever one account will work with one Apple ID and probably isn't the solution I want.
I did try to set the ApplicationUsername for SKPayment object in hopes that it will appear on the other side when the notification API is hit by Apple but it don't seem to use it for that and is used to detect fraudulent activity.
I am trying to find some documentation on handling this case but to no avail. I'm not too sure how to get around this issue and have a feeling that my app's implementation is not aligned with how Apple expects us to implement it. Maybe I have misunderstood some documentation but any insight to this would be greatly appreciated.
I am stuck with one of the in-app purchase rejection issue in my app and need some help on this.
What this in-app for?
In our app we have options for user to become premium user. A user can become premium user to enjoy some benefits and it is tied to time. There are two in-app products which defines them
One month premium service.
One year premium service.
Since these are time based service, user expects these service should be made available for that user once he/she purchase the product for the specified time, from all his/her other devices. In order to track whether the user is premium service user or not, once the purchase is done, the app writes a entry in server about premium service. So when user uses other device and logs in, he/she can enjoy the premium service without any issues. For this reason I created the above mentioned products as "consumable", thinking that it is controlled by our server there will be no issues. But apple came back with rejection and asked me to change the products to "non-renewing subscription".
Here is what apple says about this
We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
"Premium account service for 1 month and 1 year" IAPs are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Renewable Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
The Purchasability type cannot be changed once an In App Purchase product has been created. Therefore, you will need to create a new In App Purchase product with the correct Purchasability Type. To create a new In App Purchase in iTunes Connect, go to Manage Your In App Purchases, select your app, and click "Create New". The current product will show in iTunes Connect as "Rejected".
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
For more information about Purchasability Type, please to refer to the iTunes Connect Developer Guide.
Now I have created new in-app products which are non-renewing. But this works the same way as I mentioned earlier, i.e. the server keeps track of whether user is premium user or not, expiry date. When user goes to other device and does login, the app comes to know whether user is premium or not and based on that app works.
But I have couple of questions on this,
Should I need to provide the "Restore" button in the app? If so what is the purpose and how it works?
Since the user can access this service only after doing login to the app (it is different from app store account). Will these two logins make any issue?
Please share your valuable inputs.
It is highly unlikely that the user will end up in a situation where they won't be able to use your app unless they restore their purchases, however it is still possible. Imagine your server goes down for a day and during that day some user purchases a subscription, gets a new iPhone, installs your app on the new device and then wipes their old iPhone. I can think of a couple of other, equally unlikely, but still possible situations (Apple receipt validation server going down, etc) in which the purchase receipt will get lost in transit. It's best to provide the button, and if Apple thinks that you need it in your app, you will have a hard time convincing them otherwise.
If by "two logins" you mean user having to log in to your system and then log in to the App Store to purchase the subscription, that should not be a problem.
I recommend you make the changes Apple requested to the Purchasability Type and then re-submit. If you need to clarify a lack of a restore button put it in the notes for the reviewer
I want to create a social networking ios app which costs money, and when the user buys it they are allowed to create only one account on the app. So the purchase is associated with the account somehow... or the app has a specific id on each device its bought on... would I need to use gamecenter somehow...
How would I approach something like this?
Any help would be greatly appreciated.
First of all, more than one person may use the device (think a family with an iPad) so what your doing is inherently a bad idea.
That said, you can use an in-app purchase to let them buy account access - check with the server first to make sure a desired username is available, then let them use an in-app purchase to buy access, and on your server tie that purchase ID to the user name. Even if they deleted the app and tried to re-purchase (while logged into the same iTunes store account) it would see a purchase had been made and essentially be the same user. It even does kind of work with multiple users as they could switch iTunes accounts (though that is a pain).
I would also suggest trying to tie it to the users iCloud account in some way, which is easier for users to switch between on an device (a family might use one iTunes account but have separate iCloud accounts).
If you don't want to give Apple 30% of the registration fee, your only option is to have users sign up on the web and pay there, then have a login they can use in your app. Then it's a matter of trying to prevent duplicate logins on you server, although as a last point of thought, I can't remember a business that succeeded by refusing people's money.
You could generate an unique id on the phone, store it in the keychain, and use that to communicate with the server.
Since you are creating your own account management system, just save the user information once they do the account creation bit and never show the option again. Because developers no longer have access to the device id, you may have problems identifying an existing user if they delete and re-install the app, but I am not sure that there is a solution to that problem.
Edit: As a commenter to this question mentioned, you can save things to the keychain. Check out this link for a good lib for modifying the keychain.