In-App Purchase Across Platforms

I think App Store receipt-fetching is pretty contained to the Apple ecosystem, so no, I doubt your Android device can make direct use of it. But...

When you create a subscription IAP, you'll get a field called "Subscription Status URL" to use. You can parse JSON data from the store whenever a subscription is created, and from there do whatever you want with it (save what you get to a database). What you don't get though is every renewal notification (so you might think someone is still subscribed after a month, when they aren't still), plus you aren't getting the user's email to use as an identifier. You get a unique vendor identifier (a long string based on your app and that users device), so you're pretty blind to who has access to what. You would still need the user to give you an email or username, some common identifier, that can be used on the other device.

So whatever you're up to, I think you need to get the web version up and running to be a central bridge between all the devices you want to support. Easy Digital Downloads has a nice suite of Wordpress plugins. For this, look at their Recurring Payments and Software Licensing plugins. Users could enter their license number in any of the devices you want to support, which would then make a call to your site, and get back JSON data to tell you if the license in use was still part of an active subscription. Or you just verify the subscription with a username and password however you want to manage that.

Wait, that sounds like what popular apps like Netflix and Hulu do.

I have a simple checkbox in the account section of my app across all of my platforms that simply says "Auto-Renew". If you check this box, your subscription auto-renews, if you uncheck it, your subscription is cancelled. It's that simple. Are you telling me that I can't save some unique token representing my user and then use curl or PHP to simply change the status of my user's subscription when I'm on another platform??? If that is the case, then Apple should not be able to require a company to use in-app purchase for subscriptions, because our services HAVE to work across all platforms.

Surely there must be an answer here. Magazine subscription services, Newspaper subscription services like the New York Times, these are all multi-platform services. If Apple is requiring them to use in-app purchase, then their users must have a way to cancel or renew their subscription in the event that they are not currently using an Apple device.

Any other thoughts?

I’m saying your unique token will need to be something like an email address to identity your user. You can’t expect the vendor identifier (again a number based on a device and particular app) to be of much use outside of the apple environment on its own.

Most of the apps you refer to use a third party payment mechanism and are operating under the 'reader app' exception in the guidelines:

3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as classroom management apps), provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are not designed to discourage use of in-app purchase.

You are welcome to structure your app the same way and avoid IAP entirely.

Your original issue was:

"can I access the in-app purchase API from my server instead of on a device in the event that the user then decides to cancel their subscription while using the app on a Windows or Android Machine?"

The answer is 1) no and 2) no one will want to do that. Anyone who buys an autorenewable subscription on device A will be quite comfortable cancelling that subscription on device A. In general, cross-platform problems affect only a small group of users.

Your second issue was:

"If Apple is requiring them to use in-app purchase, then their users must have a way to cancel or renew their subscription in the event that they are not currently using an Apple device."

Users have a large amount of time to retrieve their Apple device and cancel the subscription. There is nothing the user needs to do to renew an autorenewable subscription - that's what the "auto" means in autorenewable.

Plus I’m not that familiar with how exactly those magazines handle their subscriptions but I’m guessing users can subscribe from their website, and then be able to unlock the premium content across all their devices regardless of whether or not they purchased the subscription through Apple (like Netflix). So Apple is not requiring in-app purchase, unless you want to be able to sell the subscription directly in the app. They aren’t saying you can’t have subscriber-only content in your app without going through us.

CartoonSmart.com and PBK, thank you for your replies. They have been very insightful and may offer the solution I am looking for.

CartoonSmart.com said

"They aren’t saying you can’t have subscriber-only content in your app without going through us."

Actually, they told me EXACTLY that. They know that my service is a subscription service. When I asked them if it was OK to just have users sign up on my website, and if they use the app on Apple, they simply have to Login. They told me that would be inappropriate use of their platform, and since my service is a subscription, to unlock the content on their device, a user MUST use in-app purchase to unlock that content. I was warned that my app would be rejected if it was submitted again without in-app purchase.

I will now go back to the App Review Team with the reader app exception you mentioned and see how they reply. That is exactly the solution I was looking for. I want a user to be able to sign up on our website and handle their account information there, and then login to the app on all of the various platforms that we support.

Well you don't want to depend on your website generating all your subscriptions, and vice versa. You don't want to depend entirely on iOS users either. Apple understands that. I think they are arm-twisting you to include IAP because frankly, you should. But you should have the website option as well. For iOS users, the quickest way to close a subscription sale is definitely going to be using IAP, and you don't want to deny yourself those quick sales.

Here's the flow I think would solve all your problems and get the app approved...

- Add a Subscription IAP.

- Use the Subscription Status URL to get notified when you have a new subscriber.

- Take the unqiue vendor identifier you got from that JSON data and save it to a database of active subs.

- In the app, you now tell the user "Thanks, you're subscribed BUT if you want to access the same content on our website or other devices, you need to complete your profile and send us your email"

- Get the email, save to the database of active subs with their vendor identifier.

- Now IF they ever go to the website, they just need to sign up with that same email and you can check if they are subscribed.

Like PBK said, your app doesn't need a toggle box for Auto-Renew. They subscribed to something, it's assumed Auto-Renew is on. Let the user manage cancelling through iTunes. If you give them a simple toggle box in the app to turn off Auto-Renew, they probably will. That just hurts your business.

The main issue I think you're left with is figuring out when the subscription is actually cancelled. Your separate database of active subs might not be 100% in sync with App Store receipts, but so what? Maybe someone that just so happens to be accessing the content on their Android device (that signed up via the App Store) gets an extra day / week / or month even past when their subscription ended. Thats far less harmful to your business model than a toggle box to turn off Auto Renew.

EDIT I should mention your Subscription Status URL gets cancellation notifications too, but it doesn't always have the vendor identifier. So thats why your active subs database might not always be in sync.

Thanks for the reply.

I'm not sure how I feel about this approach. Our app is fairly unique. It will not fly off the shelf, it is not something you would browse for on the App Store and just download for a trial. We will be going to real estate brokerages and giving demos and selling the service directly to agents and real estate investors. In a couple of years, we hope to have a few thousand users.

There is a high turnover rate in the real estate industry. Agents come and go like flies. What I don't want is to answer hundreds of emails a week simply trying to explain to people how to manage their subscriptions. People who have Windows computers, might have an iPad tablet, or an Android Phone. If I use in-app purchase to sign up for the service, but they use the other devices to manage their accounts, there will be no way to cancel an Apple Subscription on the other platforms, which will draw a lot of emails to explain to them how to handle it. Through my research, I have found there is NO WAY to cancel a subscription on an Android device. On Windows, you can use a link to forward them to iTunes to manage their subscription, but Android is a real problem. If I had made a game and needed every subscription that I could get to maximize profit, your suggestions would be the best option. But I want to spend my time creating new options, improving the app, and selling it through public demonstrations. I don't think I would get many additional subscriptions through chance on the app store by enabling in-app purchase. I will have to give this a lot of thought.

If it won't fly off the shelf, then you won't have to deal with hundreds of emails a week. 😉

Plus all you need is a well written FAQ page and autoresponder for your emails "Thanks for getting in touch, please check our FAQ as we've probably already answered your question".

Example FAQ...

Question 1: How do I cancel if I subscribed from the iOS App?

Question 2: How do I cancel if I subscribed from Android?

I would put your focus into the approach that 1) gets it approved 2) gets you the most subscribers.

Worry about the problems that come from success when you are succesful =)

I respectfully disagree. A person who has multiple devices and purchases a subscription using the iOS device will have no problem at all realizing that they need to cancel the subscription using the iOS device. Be real here.

If you wish to fall under 3.1.3(a) you must adhere to all the requirements stated under 3.1.3(a). You cannot unlock code in your app using a non-IAP purchase and then claim to be a Reader App. A reader app can only display content.

OK, PBK, now you are confusing me a little bit. On one hand, you tell me that I can structure my app to be a reader app by having a third party payment situation where users sign up online and handle their accounts online, and they simply log into the apps on their devices to view my content, much like the New York Times or Netflix or Hulu, and thus avoid the need for IAP altogether. I just installed Netflix as a trial and all you do is simply log in, there is no sign-up forms, there is no financial exchange that takes place within the app, there is no IAP. Just a login.

Then on on the other hand you state "You cannot unlock code in your app using a non-IAP purchase and then claim to be a reader app"

Could you please clarify this? Just like the other apps, I want a central location to sign up and handle account information, and the apps that are actually on devices will be log-in only. There will be no sign-up section, there will be no financial exchange in the app at all, so no need for IAP. They will just log in to view my content That I obtain from "professional databases."

So can I structure it this way or not? And if not, why not? People will be reading property information and looking at property photos obtained from professional databases.

Any clarification would be greatly appreciated.

It is not correct that : "I can structure my app to be a reader app by having a third party payment situation where users sign up online and handle their accounts online, and they simply log into the apps on their devices to view my content... and thus avoid the need for IAP altogether."

The guideline on reader app is:

3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as classroom management apps), provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are not designed to discourage use of in-app purchase.

You may need to provide a means to purchase the content in the app through IAP to satisfy:

1) you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase,

2) your general communications about other purchasing methods are not designed to discourage use of in-app purchase.

And I wrote "(y)ou cannot unlock code in your app using a non-IAP purchase and then claim to be a reader app" because as stated above, a reader app can (only) "access ... content". That means play a video, display a document, play audio, search a database, etc.. It is unclear to me how App Review will assess your "reading property information and looking at property photos". They may decide it is no more than 'accessing content' and hence you are a 'reader app' or they may decide that your app unlocks code for 'paid subscribers' by allowing them to, for example, show a location on a map or something else that is beyond a 'reader app'. And if so, you fail guideline 3.1.1 (entry #1).

Thanks for the clarification

I can't help to wonder why you develop multi-platform apps first as opposed to a working web-app for what I see as a "professional encyclopedia". This may be a good approach pre-broadband, like in the dawn of CD-ROM encyclopedias in which a CD has two apps' for the two major platforms at the time (Windows 3.x and Mac Classic). At that era there were only two platforms to support. But now you have three platforms to support (Windows, Android, iOS), have no functioning web-app, and no way to synchronize the subscriptions.

If you "pull up" this cross-platform app into a web app (should be easy enough if it's a Meteor or Cordova app), then you could focus on getting the functionality right as you are approaching your customers. Then your users would manage the subscription through the web app, which in turn you can make it in such a way that it "works okay" when accessed through all three platforms (lookup "responsive web design" for details on this).

After having the initial thousand users subscribing to your website, then you can start developing platform-specific apps should your business demands it. At this point, all apps would fall under the "reader app" (section 3.1.1a of App Review Guidelines), since users generally sign up to your website and manage their subscriptions there.