We currently have an app in the itunnes Appstore which features in-app-purchase for Apple users as well as login for paying users through our own system. Now this app has existed for a while so apparently Apple is OK with it. Maybe because those who have paid through our system are public schools and municipalities... I frankly don't know since their guidelines state:
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
And this worries me because:
If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer's work, or manipulate ratings) your apps will be removed from the store and you will be expelled from the Developer Program.
Now recently we updated the app with a new feature which was unavailable for the in-app-purchase customers but enabled for our personal customers*. Again Apple is fine with it but I worry that is only because they don't know... I don't dare ask Apple directly as I might end up getting our app pulled etc. so that is why I ask my question here:
If Apple are fine with the old setup that had all features available for in-app-purchase customers could this new added feature which only works for our customers and not Apple in-app-purchase users be a major issue? How flexible is Apple on this area in everyone else experience?
'* (This is a dumb setup I know, but the problem is our services is locked to only be used for our personal customers and this new feature requires our services.)
Related
I'm changing one of my Mac apps from a paid model to a subscription model, by using auto-renewable subscriptions (IAP).
However, as the app is B2B, some users need to reimburse costs via their employer. While this is acceptable with payments only occurring once, with recurring payments this is simply annoying and sometimes even impossible.
Apple has a B2B Volume Purchase Program that supports companies to purchase a number of licenses and distribute this to their employees. However, IAPs (including auto-renewable subscriptions) are not supported.
I see this as a big limitation (especially knowing they take a 30% cut of sales) and the only way to solve this is to offer an additional mechanism to offer subscriptions next to IAPs, specifically for business needs.
My biggest concern is whether my app would be rejected because of this. I have been going through the (updated) guidelines and found some related items:
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. [...] Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
This will be the case, but not exclusively because of the above mentioned limitation. I won't include a "Buy" link to the alternative method. However, I will include a text indicating that if a company wants to purchase multiple license for its employees, it can do this via our website (using a payment processor such as Stripe). Via this website codes will be made available that can be entered in the app to activate the license.
Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.
The app is distributed via the Mac App Store and it seems that they are more flexible here. However, it's a vague guideline and I'm not even sure if it's related to the problem I'm facing. What does it mean?
Hoping to read your opinions and experiences here. Thanks.
I have been emailing Apple about this but they have never replied. Also asked this question on the Apple Developer Forums but didn't got any help there too.
Decided to simply implement it and submit it to the App Store. They have accepted it without asking questions so apparently it is allowed. Important to mention is that I have not included the payment mechanism in the app. It asks for a license code that will be validated using my own service. This service also handles the payment via a web page.
Hope it helps others.
I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired
elsewhere, including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.
Recently, I finished developing an app in which users unlock resources using codes. These codes are free but users need an authorization from a contact to get them.
I had uploaded the app in iTunes-connect but now Apple said I must remove this feature from my app because it goes against 3.1.1 guidelines (In-app-purchase).
Reading this guideline, I found that:
Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
but, as I said (and I told it to Apple), I don't use any kind of purchase in my app nor out of it.
Is there anything I can do, as this feature is 100% of my app?
Edit:
I found this in the guidelines (this is my case, if we asume "purchased=free"):
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as educational apps that manage student grades and schedules), provided the app does not direct users to a purchasing mechanism other than IAP.
so, can I use this to pass the review?
3.1.4 Content Codes: Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. In limited circumstances, such as when features are dependent upon specific hardware to function, the app may unlock that functionality without using in-app purchase (e.g. an astronomy app that adds features when synced with a telescope). App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using IAP, provided that an IAP option is available as well. You may not, however, require users to purchase unrelated products or engage in advertising or marketing activities to unlock app functionality.
https://developer.apple.com/app-store/review/guidelines/
I assume that the resource in question is something used by your app. If so, you probably have to use another approach to unlock resources other than using codes. As the guideline said, anything used by the app must be brought within the app (IAP). Codes can come from anywhere such as your app, your website and social network. The latter two are obviously not in your app.
But after all, if you let the user to unlock some part of your app, you have to use IAP, otherwise apple would reject it.
For these 2 rules:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
Is the applicability of these rules reduced/removed if the enablement/disablement of the features/functionality (11.1) or the content purchase (11.2) does not actually occur within the app on the device.
For example, you write an app that requires free registration but if you visit a website outside of the app (and not linked to from the app) to "upgrade" your registration (by paying money) the app gains some more functionality or content next time you use it.
Thoughts?
My thoughts: you'd be violating the guidelines, but your app could get approved, of course. The payment does indeed not occur inside the app, but the application "utilizes" such a system (which is very broad) thus is in violation.
This reminds me of the Newsstand/subscriptions discussions going on before. Basically, if you offer something outside an app, you have to make the same (or better) offer inside the app (via IAP subscriptions). Perhaps this is applicable in your case, too. Although, according to 11.3, you may not offer services outside your app if purchased via IAP (so you may not unlock features on e.g. a website too.)
You'd also try and offer a free app. Once users (somewhere, somehow) upgrade their account, they can access the members only app, a new, separate app. But approval is still questionable, which brings me to my last part:
"We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it."
— https://developer.apple.com/app-store/review/guidelines/
In short: submit, pray and find out.
What you describe sounds similar to the situation that resulted in apps that used Dropbox being rejected (Link). Apple determined that since the apps that used Dropbox functionality required the user to visit the Dropbox site to sign up those apps were in violation of those rules and were thus rejected.
Apple says,
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
For example my IOS app will be used to make consultations with a web service and will be given free to users by my customer, since the web service is ours and flexible, it can offer different and hunderds of types of consultations (e.g first-aid guide, TV troubleshooting, Internet Connection trouble shooting..etc) and this can all be updated in web service by user. But this does not mean that users can use the app to buy some new guides. It will be offered to the users for free with a specific description of "This app includes this 10 guides" but we are charging the customer for license of using out web service and iPhone is one of the many ways we are offering client to access the web service and get that knowledge.
Is this possible? and what are the Apple restrictions?
Can I sell this app to CompanyX which offers 10 different troubleshooting guides?
Then sell CompnayQ another build with supports 50 different guides?
Apple have made it clear in their terms for the App Store that you must not offer anything for sale - neither products nor services - from inside an app unless it uses their purchasing APIs. This is why e. g. Amazon had to remove the buy-a-book feature from their Kindle app for iOS. You must not even have a link to a website in your app that would take the user to your website for purchase in Safari. AFAIK even a text hint on some screen inside your app telling people to go to your website for purchase of further services might be problematic in the review process.
In my opinion (which is just that, an opinion) you will probably be good with different apps for CustomerX and CustomerY, each offering free access to a specific subset of your web services. You will even be good if existing users of any of the apps can buy access to additional services on your website and then use them in their respective apps, as long as you do not link to that page from your app. You will, of course, still have to implement some kind of user-id system to recognize which users have access to the additional services, and which don't.
I suggest you take a look at how Amazon does it, because their Kindle app has certainly had a lot of scrutiny from the reviewers. Follow their lead and you should be good.
If you sell guides in the app you probably have to use in app purchases, where apple will remain 30% of the money. otherwise your app will probably get rejected.
if you have an developer account you can check the app store review guidelines.. point 11.2:
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app 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