Although I searched a lot on this site and used Google as well, I cannot find a good solution for my problem.
I'm creating an app that offers a paid web service as an option. I would like give away a initial period of this service and link this to the purchase date of the app.
The Daily app is doing something similar. After downloading the app, you can read The Daily for two weeks for free. After that time, you have to subscribe.
Your help would be highly appreciated!
From Apple's developer guidelines:
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
If your premium web service is at all useable outside the app itself, in-app-purchase won't be a solution, so you'll have to implement the logic on your server, based on user names, etc.
If, however, it's simply a web service that iOS accesses—think if Instagram offered a paid upgrade in the days before their Android app—then you could use IAP subscriptions to do the trick. Again, from Apple's documentation:
Auto-renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically renews the subscription each time its term expires. If the user chooses to not allow the subscription to be renewed, the user’s access to the subscription is revoked after the subscription expires. Your application is responsible for validating whether a subscription is currently active and can also receive an updated receipt for the most recent transaction.
As a side note, it looks like Apple are about to implement free trials, but haven't quite done it yet (there are some interesting hints in some of the documentation, but there's not an option when creating an IAP subscription yet).
I suggest you put some UI in that invites users to subscribe to the free service, and save that YES/NO answer along with the [NSDate date] in a defaults variable synced to iCloud. This means that it will be tied to their Apple ID, and can't easily be deleted by removing the app—next time they install it, you can restore that preference key.
Then, once the trial period is up, bring up your custom UI (since all the IAP UI is custom!) that gives people the chance to subscribe to an ongoing service using the auto-renewable subscription.
Related
I work for a game developing company which releases at least one game a month. For our true fans we want to start providing a subscription to our games, so they can play all our games (on any platform) without constantly having to buy them.
The idea for iOS is to use the in-app auto-renewable subscription. This results into a receipt which we store in our backend. The backend can validate this receipt and provide the apps with information about the subscription of the user.
This system will solve a lot of problems: You can take the subscription in 1 game, and play all the games as well, on any device you like.
But now we come to the problem: After a month the receipt is not valid anymore, and we need to check in the iTunes store to see if the user still has a valid subscription.
My first idea was to use the "latest_receipt_info" field, to get the latest receipt and validate this. But according the documentation this feature should only be used for iOS 6 receipts:
"Only returned for iOS 6 style transaction receipts for auto-renewable
subscriptions."
source:
https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-
Even though I can actually still use this field with my brandnew iOS 10 receipt, I don't think it's smart to use it since it's deprecated.
(another source telling you shouldn't use it anymore: https://forums.developer.apple.com/message/156580#156580)
The advised solution of apple is to implement a SKPaymentTransactionObserver in the app. This will retrieve the latest receipt when it's available, and send this to the backend. Even though this is far from ideal, this could work... however:
This means the app has to be active to retrieve the latest receipt. And in our case it's very well possible a user takes a subscription in app1, and after a couple of days downloads app2, 3 and 4, but never uses app1 again. So in this case the latest receipt will never be fetched (because only the observer of app1 can access the receipt)
To fix this problem we should be able to fetch the receipts from this subscription from any app in our subscription group. But according the documentation on the apple site (https://developer.apple.com/app-store/subscriptions/ ) you can only access a subscription from 1 app, and you have to do the multiple app thing yourself:
You can offer auto-renewable
subscriptions to access multiple apps in your portfolio. Each app must
be approved to use auto-renewable in-app purchases and must be
published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent
auto-renewable in-app purchases in each app offered in the multi-app
subscription so that users can subscribe from any app. To avoid users
paying multiple times for the same offering, you are responsible for
verifying that they are subscribers in one of the apps before showing
any subscription options. To do this, consider maintaining an account
management system in which users create an account with your business
to sign in to each app.
So is there any way to do what we want, without forcing the user to go back to the app he used to purchase the subscription every month?
On the last WWDC we went to StoreKit labs and personally asked StoreKit evangelist about this. We were told that the 'latest_receipt_info' field return by iTunes validateReceipt endpoint is exactly what we are suppose to use in order to check if the subscription was renewed or not.
This is not going to be deprecated in the near future but they do have plans for adding some server-to-server communication that solve few of the problems we ran into:
Your server will be able to get notification from Apple regarding any subscription renewal, cancellation, downgrades etc.
In the latest_receipt_info returned by the validateReceipt endpoint few fields will be added, providing information like whether the subscription will be renewed after current one is expired, whether there was a problem charging the user's credit card etc.
Sources:
WWDC 2017 Session 303 - What's new in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit
We run a SAAS Web app and are going to be launching our app in Apple’s app store (up to now we’ve had a mobile Web app).
We want to offer the ability to purchase a subscription in app due to the ease of use for our customers. No problem, we know how to do that.
The question we have is whether there is an easy way to keep our web app's db updated with the user’s current subscription status so if they access our Web app we know whether their subscription is valid.
Ideally it would be great if Apple offered a web hook option where they would post an update to a url on our server. From what I've read this isn't an option.
We can always post the data to our server from the iPhone app when the user logs in, but if the user doesn’t log in on the iPhone for a while the subscription status recorded on our server will be out of date.
How are other people handling this? Are we missing something?
Update:
The closest I've found is this thread: https://forums.developer.apple.com/message/70707#70707
The app gets a receipt the first time it buys a subscription or
restores a subscription. The app can send that original receipt to
anyone's server. Anyone's server can then use that orignal receipt to
verify the current subscrition anytime it wants. You can't do that
with a non-renewing subscription but with a non-renewing subscription
the user must purchase the extension from the iOS device each time
period.
Followed up with this:
https://hetzel.net/2011-04-01/server-side-auto-renewable-subscription-receipt-verification/
And from Apple it sounds like they definitely do not make any provisions on their end for synchronization:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have
both an iOS and OS X version have separate products with separate
product identifiers on each platform. You could let users who have a
subscription in an iOS app access the content from an OS X app (or
vice versa), but implementing that functionality is your
responsibility. You would need some system for identifying users and
keeping track of what content they’ve subscribed to, similar to what
you would implement for an app that uses non-renewable subscriptions.
Late to the party, but I think this is a relevant reply to this question:
https://stackoverflow.com/a/47537279/543423
Hopefully this is helpful to someone :)
My application is a web-service client. Service has a paid one month subscription. I want to implement subscription payment with IAP. At first I think to implement it as Auto-Renewable Subscription but after reading several posts about it drawbacks (rejecting from the App Store because the content is not a digital content or something like this) I decided to make Non-renewable subscription - but it also has some drawbacks (hard to sync it, optional registration). In on SO post - developer wrote that his app was rejected from the App Store when he made iCloud synchronization.
So can someone with good production experience wrote all pros and cons of both Auto-Renewable Subscriptions and Non-renewable? What should I choose for the one-month subscription to the medical web-service? Thanks
I do not have experience with auto-renewable subscriptions, but I do have extensive experience with IAP and non-renewable subscriptions. I use non-renewable subscriptions for a service that isn't a digital download.
Renewable Subscription Cons
User has to manually renew each month.
You will probably want to consider longer subscription periods. My app has 2 month and 1 year.
Renewable Subscription Pros
Users only pay for what they use. You can turn this to your advantage.
My own app saw a good increase in conversation rates when I explained that subscriptions do not auto renew and so they did not need to worry about canceling the subscription.
You can change the price!
Much more flexibility about how you can use it.
It has the standard popups during purchase. You will have a better conversation rate from the user hitting the buy button to them following through with the purchase.
Auto-Renewable Cons
LOTS of regulations about what you can do with it.
It is very possible that you won't be able to use auto-renewable in your situation.
Only the user can cancel their subscription. You can't add an easy way to do this into your app and keep your users happy.
The purchase process has extra steps that ask the user if they want to share their information with the publisher.
There is no API to know when the subscription will end.
You will have more negative reviews.
Auto-Renewable Pros
Users don't have to manually renew.
You have a more guaranteed income per month.
You will need to sync the subscriptions between devices. I use Parse.com as my backend. Basically, before making an IAP transaction as complete I push the data to parse. Users can then pull that data down onto their device to sync the subscriptions. Parse lets you save the transaction for users with and without accounts. So it has the benefit of giving you real time sales information.
EDIT: Auto Renewable Subscriptions will Change This Fall
Auto renewable subscriptions are drastically changing this Fall (2016). Pretty much every reason not to use auto renewable is going away. https://developer.apple.com/app-store/subscriptions/whats-new/
I had exactly the same experience with a auto-renewable subscription (an app that gives access to a specific information while subscription is active). The app was rejected because "app is not suited for auto-renewable subscriptions, and their recommendation was to switch to non-renewable subscription, and that is what I did.
After that, the app was rejected because there was no way to transfer the subscription between user's devices or after device reset. What I did, was to set up an user/password authentication system and allow up to 5 devices to connect at the same time with one user/password combination and to allow to extend the subscription from any of that user's devices. This solution was approved (back when iOS 5 was the latest version) and is still working.
I am implementing an App with in app purchase of type:non-renewing subscriptions.
according to apple documents:
If your app uses non-renewing subscriptions, your app is responsible for the restoration process.
FROM HERE
My question is, if the restoring is mandatory by apple, how to prevent thousands of users sharing one apple account with only one description?
For example, if in my app, you pay $0.99 that can use this app for 10 days, from apple's requirements, the user must be able to use app within 10 days on any his/her devices, with simply enter the credentials. However, if the user set a simple account credentials and share it with 100 people, then, the 100 people don't have to buy the subscription anymore and can use the app free during the 10 days.
Some people keep assert that people won't share their account... how do you know that? i saw people register some apple id exclusive for sharing apps and games, and only need to pay once.
Besides, i don't implement my own server and my App don't need one. Is there a way to prevent this?
Thanks in advance
Since non-renewing subscriptions seem to require the app (developer) to use a separate (non-Apple) server to deal with the restore process (for example, see How to support multiple devices with non-renewing In-App Purchase?), why not have that server keep track of the number of restores per "user"? Then you could impose a maximum number of restores per "user". Each installed app that has made a purchase could have its own unique_token (for example, see app rejected.how to track user non-renewing subscription). The user would then have to have a username/password, which would be associated with the unique_token, in order to do a restore (for example, see Restore transactions for Non-renewing subscriptions without registration; and see Registration should be always optional on non-renewing subscription?).
I need to build an app for a system, which already has a subscription on its website. It looks like Apple doesn't allow to use any own subscriptions and forces to integrate any app with iOS in-app subscriptions.
Is it any way to integrate two subscription systems? The main problem is that users can manage iOS subscriptions via iTunes and I can't find whether it's possible to get information about this and to stop subscription in the existing system if it's stopped via iTunes.
So is it possible to get notifications about unsubscribed iTunes users?
Using third party subscriptions
First off, it is possible to support an existing subscription system in your app, but it must be in addition to the App Store subscriptions. Also you have to be very careful about the UI you use. You can't prompt users to bypass the App Store and purchase through your server, but you can offer existing subscribers the ability to sign in with credentials they may have previously obtained through your website.
That said, Apple can be fairly capricious in their rulings on what is and isn't allowed in the App Store. I have worked on apps that have done this sort of thing, but they have been for fairly well known magazine publications. There's no guarantee that they will allow it for everyone.
Detecting unsubscribed App Store subscriptions
As for using App Store subscriptions, when a user purchases a subscription in your app, they will receive a receipt in the SKPaymentTransaction object. This receipt should be posted to your backend server to make sure it is valid before you give the user access to anything. See the In-App Purchase Programming Guide for more details.
When you setup a subscription type, you specify how long that subscription lasts. So if you log the transaction date in the SKPaymentTransaction when you receive a receipt, you can determine exactly when that subscription should expire by adding the duration of the subscription to the transaction date.
If it's an auto-renewing subscription, you will receive a new receipt when the subscription is renewed. So once you have validated that with your backend server, you can update your expiry date based on the new transaction date. If you don't receive a new receipt before the first one expires, it's likely the user has cancelled their subscription.
On the backend, your server can also tell when a particular subscription will expire based on the response from the verification server. First there is the status code which will tell you whether the subscription has already expired, but there is also an expiry date returned in the decoded receipt which will tell you when it is expected to expire if it hasn't already.
For more details, see the Auto-Renewable Subscriptions documentation.
Testing auto-renewing subscriptions
It's worth noting that when you are testing auto-renewing subscriptions in the App Store sandbox environment, the length of the various subscription types is dramatically shortened to make it easier to test. For example a 1 week subscription lasts only 3 minutes in the sandbox environment. You can see the full list of times in the iTunes Connect Developer Guide.
So you want the people that have bought the service from the website to be able to use the app, exactly like if they had purchased it from in App Purchases and in App Purchases people to be able to join the service just like people that joined through the site? As far as I know, Apple doesn't allow you to pay through other services as you said, but let's say someone buys the service from the app. What should happen would be that the money will be transferred to the company. Then after the payment you should include some code doing what the site does after a new person has payed for the service, so create his account as a paid account. Then, the app should also have a login screen where the registered users (no matter where they registered from) will be able to login into the app and use the service. Now the problem is indeed that if the subscription is stopped through iTunes you would never know, though a way around this would be to make a check in the server of this company which should monitor the income coming from one account. Then if this user has stopped paying (or stopped the subscription) you would be able to stop the service from the app. And you should recheck the server for payment after the duration of the subscription has passed, let's say a weekly subscription should be checked every week. (Sorry I would do this a comment but I haven't got enough reputation for this)