I have one application in iTunes which download books and magazines from server. I have integrated Non-consumable IAP for every books and magazines. Now, I want to integrate Newsstand to application. For that I need to integrate at least one subscription to application. I am confusing how to manage it? How can application get idea that any user has subscripted for that IAP or not?
How server will allow any particular device to download new subscription ?
A user buys a new subscription the same way he buys a standard IAP.
After the purchase you will get a receipt (in iOS < 7) or an entry in the App Receipt (iOS >= 7) that tells you when the subscription was bought and when it expires.
When a new issue is available, (or when a user restores his purchases etc) you will need to check that information and determine if his subscription is valid and provide him with the issues he has subscribed for.
Your server can store device tokens and the base64-encoded receipt to know which users are valid subscribers.
That's the really really really basic info on newsstand and subscriptions. There is much to read and learn in the documentation pages and in Stackoverflow.
I would suggest reading through the tutorials 1 and 2 listed below FIRST. They are a bit outdated now but they will give you a more clear view of what is ahead of you.
Subscription Guide
Newsstand notes
Tutorial 1
Tutorial 2
Related
IAP was implemented in my CodenameOne application. I followed Steve Hannah's blog post Auto-Renewing Subscriptions in iOS and Android.
Hope many application instances will be installed. All applications send data to the same database table. What is the key to differentiate user subscriptions?
THX.
Péter
I suggest looking at the server sample as IAP is pretty hairy on that side of the fence. E.g. here Steve stores a username from your side: https://github.com/shannah/cn1-iap-demo-server/blob/master/src/main/java/com/codename1/demos/iapserver/Receipts.java#L31
Notice that your app will need a unique identifier and login system. As Apple requires the ability to restore purchases so you need to store information about the current user somewhere so you can restore the purchase on a different device.
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 :)
I am looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.
We are an university department for further education courses and we are planning to publish our cd based courses as an additional iOS/Android App. As we have almost finished the development process we are now facing some questions regarding the distribution. The basic idea is to publish the app in a lite version for free (including chapter one of the course). After you have completed this chapter you will be asked to enter your login data. Our students will be able to enter thier data to activate (download missing content from our server) the app. If you are not an enrolled student there will be a link to our course page. On this page you can enroll for the courses and of course there is a charge for this.
But Apple only allows purchases via the App Store or as so called "in app buys".
Will we violate this rule with our idea?
I have found some newspaper apps with basically the same concept: download for free. If you have a print subscription for this newspaper you enter your data and can use the app. If not you can subscribe for the online offer via an in app buy.
After days of research we have no clear answer to this scenario.
Any comment appreciated.
There are two possible solution for your situation:
Without In-App Purchase: You can create an app which can have a eBook (in your case, dummy eBook with chapter 1 content) bundled with the App.
By doing this anyone who can download will have access to the dummy eBook as well.
For downloading of additional-contents user can do login and access the eBooks available with their account.
Kindly note as you are not using In-App purchase there shall be no links for user registration, buy inside your app.
All these you can handle at your web-site.
Your app can check for valid user credential using a web-service call, and user can see the contents available for download.
Advantages: 1) You shall not be paying 30 % to Apple as No-purchases are done using your app.
2) This is total compliance with Apple guidelines, this link and part 11 specially will be of interest.
Disadvantage: Users cannot directly buy/register via app and you need to maintain additional services for user login validation/content mapping/download content etc.
Using in-App Purchase:
You can use Apple provided in-App purchase for selling content/ registration of users etc.
Please note Apple shall charge 30 % on your selling price.
Advantages: Users can register and buy directly using your app. In-App purchase guidelines will help more in this.
Disadvantage: Apple will charge 30% on Selling price.
Given what you are trying to do, there really is no clear answer for your question that this community can provide, I'm afraid.
The true answer is entirely up to Apple's current app review policies. You should probably submit the app, explain clearly what you are doing, and if it gets rejected/denied, you can follow up with an appeal to the app review board.
As far as I know, physical items that are purchased are not subject to Apple's 30% cut. However, since you're offering courses / content over the 'net, Apple may want some percentage (between 0 & 30%) of the the profits you're making. Maybe they have a different arrangement with newspaper publishers. Ultimately, you'd need to submit the app and find out what the reviewers and app review board say.