Apologies in advance for a policy, rather than a programming question, but given the paucity of information available online I hope I can be forgiven for asking it here.
I would like to use the new recurring subscriptions from Apple in an iOS app. I have coded payments before and have no problems there, however nowhere can I find guidance on what is allowed under the new subscription type. The implication 'seems' to be that there is no special guidance, however all the discussions I can find are talking about 'content' providers rather than service providers.
I would like to use the recurring subscription for a service that people subscribe to. I am not offering any content per se.
Using the old non-renewing subscription type (that is really so broken it isn't worth using) I'm 99% sure the app would be accepted, but all the talk of content providers has me worried that Apple really don't want SAAS providers to use the recurring subscription model and want to restrict it to publishers of content.
Does anyone have experience with using the new payment model for software as a service?
I'd love to get some better idea as to whether it's viable or not before we build a whole payment solution around the concept!
I am sorry that i am coming into this a little late, but i have an answer for this.
Basically about a month ago i submitted my app and it got rejected for not including iAP as it links to our SAAS website for users to set up their subscriptions. So off i went and implemented Auto-Renwing subscriptions. didn't take me too long and from testing worked fine. So i resubmitted. and got rejected again.
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.
Cloud-books is set to Auto-Renew Subscription.
Based on product functionality, it would be more appropriate to use the non-renewing subscription In-App Purchase type. The Auto-Renewable Subscription product is best suited for apps that require or feature dynamically or frequently changing content, such as digital periodicals or radio subscriptions.
Even though when creating an iAP product there is a nice little line that says this:
Non-renewing subscriptions can still be offered, but auto-renewable subscriptions are now preferred for the following reasons:
So from my experience auto renewing is NOT allowed for SAAS.
I think the policy around auto-renewing subscriptions on iOS may have changed recently, but it's tough because there's still a lot of older information and testimonials from developers out there. Marco Arment's blog talks a lot about the policy here and here, but those are from 2012 and 2013
As of now (mid-2014), from what I've been able to gather, the relevant policy has changed from this:
"Apps that use IAP to purchase items must assign the correct
Purchasability type Appler In-App Purchase is currently an
Auto-Renewable Subscription. However, it would be more appropriate to
use the Non-Renewing Subscription In-App Purchase type. Auto-Renewable
Subscriptions are intended for periodical apps, such as magazines and
newspapers."
to this:
Apps may only use auto-renewing subscriptions for periodicals
(newspapers, magazines), business Apps (enterprise, productivity,
professional creative, cloud storage), and media Apps (video, audio,
voice), or the App will be rejected.
So it seems like an older restriction that was mostly focused on periodicals has now been expanded to a bunch of other use cases. There are a number of public examples of apps like Evernote that have switched to auto-renewals.
Source: https://developer.apple.com/app-store/review/guidelines/
If I understand your question, you are offering "another month of this service" as a subscription item. This would be a common model for subscription-based games, etc. Probably your best indication of whether or not it is allowed is to look for other apps that do it.
In addition, don't be afraid to contact Apple! They're not monsters, and they do answer questions! You can email tech support or, if that doesn't get you a helpful response, ask to talk with one of Apple's iOS biz-dev managers. They have people whose job it is to help you make your business succeed. If they don't know the answer, they'll find it; if the answer is "no", they'll help you figure out ways to do something similar. They're quite friendly & knowledgable, like a genius bar dedicated to the iOS app business.
Let us know what you learn!
As I mention in my comment to #Joe Meredith's response, I received a similar rejection. Although I thought that this was due to an unwritten rule, I just noticed that this Hacker News commenter found a written rule that explicitly states that
Apps containing "rental" content or services that expire after a
limited time will be rejected
As for 2019, things have changed a little bit. Apple now do allow the usage of the SaaS model with IAP Auto Renewable Subscriptions:
Permissible uses: If you offer an auto-renewing subscription, you must
provide ongoing value to the customer, and the subscription period
must last at least seven days and be available across all of the
user’s devices. While the following list is not exhaustive, examples
of appropriate subscriptions include: new game levels; episodic
content; multi-player support; apps that offer consistent, substantive
updates; access to large collections of, or continually updated, media
content; software as a service (“SAAS”); and cloud support. In
addition:
Related
I'm interested in unlocking features for a fixed time period in my iphone app via promo code. These same features are also offered for subscription outside of the app store. Is this still legitimate? It's imperative that the app isn't rejected by the app store for violating the terms of service.
Moreover, if we allowed the user to 'spend points' for this subscription (in app), would this be a violation? I suspect so but thought I would ask.
I've seen apps out there that use earned points to unlock features, or the user could just speed up the process and purchase it with an in app purchase, so that seems fine
Having out of app subscriptions seem debatable but I feel like they would be fine - apple would still earn a profit as people would be encouraged to buy out of the app.
Keep in mind that apple will take out a cut for themselves on every purchase (including in app)
And welcome to StackOverflow :D
I am building an app for a client that will have 30 days of content for free, thereafter you are required to buy a subscription via in app store purchases.
However, I have read that you will get rejected if you have trials.
Don’t set time limits on any of the functionality of your app, either
for run times or life times. Applications that only run for a set
number of minutes per session, or that expire altogether after some
period of time, don’t recruit customers so much as leave a bad taste
in their mouths.
Finally, they also say "your app will be returned to you by the App Review Team for modification if it is found to have time limits".
This seems odd because I know the Guardian and all major newspaper apps have limited functionality.
The Guardian app is free but you get limited functionality?
The Daily app is free, but you have to pay for daily subscriptions
and has limited functionality for the period of your subscription.
The Times app is free, but is a free trial (of sorts) (plenty of
complaints about it)
There are other examples which seem to differ from Apple's policies.
Lets say you have an app that is free, but then you have to pay for subscriptions to gain access; however according to the rules this is considered limited functionality -- yet there are lots of newspaper apps that do exactly that.
I'm confused.
Can someone clarify the situation? Can apps have trials?
Thanks
It is difficult to clarify the situation because unfortunately the guidelines are not necessarily set in stone. They can and do vary on an app and publisher basis.
In the case of The Times and The Daily, both apps are produced by News Corp. It is perhaps safe to say that News Corp has a good deal more influence with Apple than a one-man development shop producing an iPhone game. Apple would be loath to admit it, but there are clear cases of popular apps on the store that don't conform to the guidelines, where they have tacitly made an exception.
So what I would say to you is this: be sensible. Don't have an app that quits automatically when your trial runs out. Think about what would be acceptable to users. It's very much a case of nothing ventured, nothing gained. Take a risk, submit your app with your limited trial, and see what happens.
With the Guardian app, we had to deliver an app where you always got at least some fresh content if you were using the free version. Subscribing opens up more content to the user.
I think, you are mixing up "content" and "functionality".
You can deliver content items (i.e. an magazine issue) for free or user has to pay for it — so the first n issues, or all issues in a certain timeframe, can be free, while the others need to be paid. But if an user purchased an content item before, you have to re-deliver it for free.
You can sell functionalities (i.e a search in the magazine's archive) as-well. But you cannot give it to the user for free for a certain time and them make him pay.
So the general rule is: What ever the user got from you — you cannot take it back from them and make them purchase it again.
There are plenty of free apps which provide limited functionality. They don't provide time limits though (or at least they shouldn't). I'm guessing it won't be as clear cut as accept or reject for Apple, because I did encounter an app which closes itself after 10 minutes, opening a web page to purchase it (closing an app is also against the Apple Human Interface Guidelines, as an app should never terminate itself).
The guidelines mention this is only allowed for specific types of content:
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
Is there a way for the developer of an App Store application to tie a sale to an individual user/device ID/Apple account? In other words, a method for the developer to double-check that a specific user has legally purchased the software?
I haven't been able to find a reliable answer to this yet. I'm not looking for specific code examples, just some sort of idea as to how possible (or difficult) this is.
My intent isn't to penalize piracy; it's to be able to provide additional benefits to paid customers. As such, I'm not looking for a way to identify a cracked or pirated version, which I gather has already been solved.
Thanks in advance for any help you can provide!
None of the answers were all the way there, so I'll summarize.
First, as per Tim's answer, Apple does not give you any information to identify customers of a standard app purchase, or to identify one specific sale from another.
However, using In-App purchases provides you with a method to identify a valid purchaser, directly from Apple. The information you receive in this manner is uniquely identifiable; it doesn't give you a user's device ID and/or Apple Store account, but it can be used to verify a specific transaction.
Apple's documentation on verifying store receipts.
You can roll your own system to do this. You're not permitted to look into Apple's information elsewhere on the phone, but you can let your users create an ID in your system, through your application's interface. Gather the information voluntarily from your customer at the time you have them create their Profile on your system. You can get the Device ID, but you may want to collect something like an email address, too, so that you can continue to provide them with consistent service, as they upgrade to a new iPhone, or add an iPad to their fleet of Cocoa Touch devices.
Be sure to use an encrypted http connection when you're talking to your server, so that you don't accidentally expose your customer's information.
To quote "Dr. Touch"...
AntiCrack contains proven technology
to mitigate the risk of your apps
getting pirated by automatic cracking
tools
You do not have access to any purchaser information from the Apple store. Apple considers these customers THEIR customers, not YOUR customers and so will not make any customer identification information available to you...
-t
I am a complete novice and have no technical skills and little knowledge concerning iphone app development an in-app / itunes store purchases.
But I have been playing with some ideas for my coffeeshop / lunchbar and was wondering If any experts would like to give me some feedback on my ideas.
As I said I run a coffee and lunch(break) shop and allot of my customers are iphone (and blackberry) users. What also happens alot is that the customers ring to order their coffee and food so that they don't have to wait (and waist their precious lunch time).
I myself am an Iphone user and really like the way it works (most of the time).
So I was wondering I is possible or will it be possible to develop an iphone app for my customers and have them pay for the order "in-app". I get a bill of the order in my mailbox and they just chout their name and thats it !?
Might sound a bit low tech but if apple have someones creditcard details and a mobile ordering display then they could function as a cash register of bank ?
thanks,
Jonathan
You can't do this according to Apple's terms of use:
You must deliver your digital good or service within your app.
Do not use In App Purchase to sell real-world goods and services.
Even if allowed, you'd lose 30% of your revenue to Apple using in-app purchase.
There are point-of-sale apps for iPhone that allow you to swipe credit cards. One of the Twitter founders has a startup called Square that'll be doing this. If you wanted it to be an app that users could install themselves, though, you'd likely be best off doing a custom one and hitting a payment gateway in the backend (Chipotle's app is a good example of this).
The original asker is just asking if this is possible, which it is! If you don't take the term 'in-app purchasing' literally. Just use paypal or some other payment method through the app. Ebay does this and so can you.
As long as you aren't selling something that competes directly with Apple (like Sony's digital book store that got shut down) you should be fine using a payment method other than the built-in functionality called 'in app purchasing'.
You have a good idea on your hands and it should be possible to find a way to take customer's money through the app.
Though you could probably use In-App purchasing for this, you would have some interesting work to do to make it work smoothly. You would probably be better off developing your own shopping cart application that lets your customers order "online" and write a custom iPhone application for them - skipping Apple for the purchase of coffee and donuts...
-t
Does anyone know of an app that implemented an in-app subscription?
EDIT
====
Just to be clear I'm referring to implementing an in-app purchase of type "subscription" as apple defines it and not implementing a consumable and calling it subscription.
=====
I thought about how the subscription model can be implemented and always ends up with more problems to every possible solution I can think of, so I'm wondering if anyone knows of an app that actually does that.
Thanks
FitnessBuilder (http://www.pumpone.com/fitnessbuilder.html) implements In-App Subscriptions. Let me know if you have specific questions about how the subscription system works.
I don't know of a specific app that has implemented in app subscriptions, and that strikes me as being "not a programming question." But Urban Airship offers a hosted in app purchase solution which does have support for subscriptions:
This might be used to buy a new map
pack, game item or subscription based
content.
http://urbanairship.com/faq/
I think you will mostly need to implement the exact mechanics of the system yourself. Users will need to "renew" their subscription by making separate in app purchases.
I've seen MotionXGPS Drive do that... They have a rate of $2.99 a month or $24.99 a year. You still do however, have to renew it manually.
One way to detect if the product is of the subscription type is to purchase it twice. The second time you do it, you'll see a message that warns you about the nature of the product (subscription) and the kind of purchasing (renew).