I'm working on an app that is basically a client to a custom service. The custom service is accessible via an iOS app or Android app, and recognizes users by their email address.
My intent is that users can purchase a subscription to the service from any device. On each device, though, I want to use the native store. The only way to make it on an iOS device is to go through Apple's In App Purchase. This should be a renewable subscription but tied to a specific service account (email address) rather than a device or group of devices.
I assume I can do the In App Purchase on the device, and I'm going to have to track the subscription within our custom service.
What I'm not sure of is how to tie this to a single email address, so the user can't upgrade as many service accounts to Premium accounts as they want. (The user can't sign in to multiple service accounts, but I'm concerned about them uninstalling the app and restoring purchases to different service accounts.)
How do I do this? Netflix and others manage this, but I'm not sure how.
Related
my name is Antony Basta and I am the developer of an app called SecuriKey. SecuriKey allows any old apartment building intercom to be controlled from an app. Users can create entry codes that work once, up to a certain date, or are instantly revokable. There is no need for any new or additional hardware – it works with the buildings existing intercom.
Currently, the app is using Stripe for subscriptions and it was initially approved 2 months ago for the App Store. I pushed an update a few weeks ago and Apple Rejected it because I am not using In-App Purchase (IAP). I submit an appeal, mentioning that we offer a consumable service that takes place outside of the app (guideline 3.1.3(e)), it is effectively a "Reader" app since we provide VoIP numbers to our customers (guideline 3.1.3(f)), and SecuriKey requires hardware to function – that is, it will not work without a physical intercom (guideline 3.1.4). Additionally, we do ship physical goods to our customers (NFC tags and Security Signs) monthly and require monthly service personnel to service the building using the physical goods for our own back end workflow. A lot of back and forth has occurred between the review team and at the time of this post, the app is still being reviewed by the board. I thoroughly believe we fit within all of the mentioned IAP exception guidelines – but that's a conversation for another day.
As I wait, I began to delve into using IAP for this product. I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made, and I am able to create an account and collect a payment. But there's one huge oversight. This is a cross-platform app. Meaning, roommates or family members who use different mobile operating systems, can be logged into the same account. A user may sign up from the iPhone but his/her roommate/family member may have an android that also has access to the service under the same account. Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either.
Has anyone ever dealt with something like this? How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)?
If Apple says you have to use IAPs, you should leverage IAPs and not a payment service provider like Stripe.
I'm confused with what
I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made,
means but does not sound like the right thing to do.
Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either
Your user will have to use Apple's Platform (i.e. an Apple device that they are signed into) to cancel the IAP subscription.
How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)
You can't. Take a look at the IAP experience for subscription services like HBO Max. Accounts are all ultimately provisioned through the same system, but the funding source may differ. When you attempt to manage your subscription, the website or android app could inform you that the subscription is billed via Apple, and send you to a page like this: https://support.apple.com/en-us/HT202039.
If the user has no Apple devices, they can contact Apple Support:
If you don't have an Apple device or Windows PC
You can cancel Apple Music on the web.
You can cancel Apple TV+ on the web.
If you want to cancel a different subscription from Apple, contact Apple Support.
We are planning to distribute our app to certain clients using iOS Private Distribution redemption links. I have gathered all the information from Creating Apple Business manager account to downloading the redemption links from the business manager account.
I have enrolled myself in Apple Business manager account, waiting for apple approval on the same. Before going ahead i have the below questions
Does each redemption link work only for a single user or multiple users can use the link to download the app.?
How do we keep the Redemption link secure.?
Can the Apple Business manager account gives more analytics on our app installations and distribution process.?
Once the app is approved and released, does the subsequent builds should go again apple review process? How does the user know the app updates has been released with newer version?
Each redemption code or link is only valid for a single user. It is the same as if you gifted an app to a user. Once they redeem the code the app is "owned" by their Apple ID. This is one of the major problems with using redemption codes for custom apps; If it is redeemed using a personal Apple ID then you can never remove the app from the user, even if they leave the organisation.
The redemption link itself is not secure. You need to consider the process by which you will send redemption links to users to ensure that they reach the intended user, such as sending it to their work email address
Apple Business manager tells you how many of your "purchased" apps have been redeemed. Once a code is redeemed the user can install the app on any device that has their Apple ID logged in. This is not visible in Apple Business Manager
The review process is the same as for an App Store app; new releases are reviewed as with any app update. Updates will appear in the user's "available updates" list in the App Store app and will be installed automatically if the user has selected that option.
Using redemption links/codes is not best practice for custom apps. It is strongly recommended that you use an MDM to manage deployment of custom apps to devices.
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!
Lets say I have website where user can purchase subsciption x,y,z and I have app where user can also buy same subsciption. What happen when user alredy bought sub on website and then login to app? Can we push informations to apple server or just check in app with our backend if user has sub and ignore apple?
For the multiple plateform scenario you have to maintain the server DB along with the status of the account is either purchased or not. If user is paid then which type of subscription (x,y,z) it is. For app (android, iOS), you have to use API's and for web you have fetch data from server DB.
Can we push informations to apple server.
No, you can not do this. Apple IAP data only maintains that you have purchased from the IAP. And same as for the google in app purchase.
Hope now you have been cleared.
We plan to implement all the subscription server-side services. Here is the flow for our client iOS app:
The registered user enters phone number, we check if the number is valid and if it is, the user can subscribe and thus use some features of the app that an user without an active subscription can't. The subscription is not free and it doesn't go via AppStore; the user is charged at the side of his/her provider, based on his/her phone number. The user isn't asked to give any of his/her credit card data. One of the features that gets unlocked when user subscribes is the possibility to download digital content.
The question is: would Apple approve this flow? I know for subscriptions as in-app purchase types, but the plan is to have something different in our iOS app.
And what about promo codes? Is it possible for vip users to use our promo codes in order to subscribe..?
Apple will not approve any purchases that get added to an iOS device, are initiated on the iOS device, and don't go through the app store. You can do purchases through your web site; in that case you will have to avoid links to your website from the app.
On the other hand, physical purchases must not go through the app store. So if you have an app for buying hand bags, you can not get payments through the app store.
Apple will also give you a very hard time if you ask users for their personal information, like their phone number, and if there are features they can't get without giving you such information.