We're having some trouble with the App Store Review Guidelines, specifically these two points in section 11 - Purchasing and currencies:
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
We're making an app for iOS, Android and Blackberry. We wish to provide in-app purchases for iOS and SMS for all three alongside. We can't quite depict from the guidelines whether we can have text underneath an in-app purchase button saying "or SMS XXX to XXXXX" and have them enter the password received back to their phone.
Yes we're using another system to the IAP, but we're offering that at the same time. Could SMS be counted as a different "mechanism"?
Any help on this would be much appreciated. I don't fancy the idea of submitting our app for approval after setting this all up just to have it rejected and have things delayed for weeks.
Thanks in advance :)
Sending an unlock code via SMS will almost certainly be considered a "mechanism other than the App Store" (11.1), and be used as a cause for rejection.
No you can't do that. Apple will reject your app. They don't want any other IAP methods, because they won't earn any money from it! StoreKit is just the easiest and best (and the only :P) API for IAP. Either you just use regular IAP or you will have to stick with Cydia. You can make your app free in Cydia and then manage your own IAP using SMS or how ever you want it to be.
Related
I'd like to offer 100% discounts via one time use coupons on IAPs. Can it be done? And more than just 100 of them, which I think is the number of coupons Apple allows. My goal is to generate future IAPs by introducing players who don't use them to try them.
From what I've been able to tell, it seems that Apple doesn't officially allow IAP promotion codes.
From: https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
1.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
See also
1) https://forums.coronalabs.com/topic/37264-rejected-by-apple-cause-of-promo-code-custom-solution/
2) How to create a promotion code for iOS in-app purchases
If you still want to power ahead and do this, one way is a URL scheme. Briefly, you enable your app to respond to something like: myAppName://... when that URL is present in an email being read using the Apple Mail app, or when that URL is typed into Safari. Then, your app examines the URL parameters and pulls out, say a code identifying the type of comped purchase (e.g., perhaps consulting a back-end server), and makes the comped purchase available to the user.
See also:
A) Free iOS in app purchase for some users/devices
B) Rewarding iOS app beta testers with in app purchase?
C) iOS In-App Purchase, sending to another account (gifting?)
D) Providing a discount code for an iOS in-app-purchase
I have a requirement in my new iPhone application, where I have to made payment like paisapay (Ebay) does. can I open a web page where user can fill information related to payment and server will handle payment? This Transaction will be in secure manner (In standard way). is it possible? Apple will approve app?
If you are using this means to unlock functionality in the app after payment, it will be rejected else it's okay.
As per app review guidelines
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
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
For more reference please read the latest App store review guidelines at https://developer.apple.com/app-store/review/guidelines/
maybe this might help you
http://www.zooz.com/
FYI: In accordance with Apple’s App Store Guidelines, ZooZ can be used without limitation for purchasing physical goods or goods and services used outside of the application.
I want to implement the payment gateway like functionality in my iphone application other than In-App Purchase feature provided by Apple.
So, i have one Question regarding the application approval on Appstore that, if i will redirect user to the UIwebview for payment related functionality, then apple will reject this application for not following the human interface guideline or it will allow this.
Other way i can do it by calling web-service for the transaction of money. So, again there is any chance of app rejection on AppStore.
Please share your thought on this
Absolutely no way you'll be allowed to do this. Check the news the past couple of days. Apple is demanding even giants like Amazon and Sony to go with the In-App purchasing.
Edit Actually, Apple did come out with a softer stance, saying that you'd have to offer both payment options if you did your own transactions. So there's that..
Merry Christmas. I have two questions on In App Purchase.
iAP application process: do I need to submit my iAP items applications, wait for Apple's responses, then build my app accordingly, or, I can just create some iAP items, build them into my app, then after everything's done, submit my binary to Apple?
Intermediary currency: on Apple's documentation I found these sentences:
"You may not offer items that represent intermediary currency because it is important that users know the specific good or service that they are buying."
However, I found a few apps on the App Store offering its users with different kinds of intermediary currency. I'm confused. Is this a gray area in which we developers can play some tricks?
Thanks in advance.
Di
You need to add in-app purchases to iTunes Connect, and wait for apple approval to be able to sell them from real application.
However, you can debug/test them without that approval, via sandbox environment.
I cannot say a lot about that 'intermediary currency' and what Apple actually mean. A lot of games uses in-app purchases to sell in-game 'coins', and everything works fine.
We intend to launch a free iPhone/iPad app on the AppStore.
The content will actually be accessible thanks to a subscription model (login/pwd authentication in iPhone app).
The subscription (about 100$ a month) is handled via a dedicated web server.
If used without subscription, this app will provide minimum value.
Does anyone know if this kind of subscription model can be rejected by Apple ?
I know some apps follow this model, but I'd like to have your thought on this before starting in this direction.
Thanks for your answer.
This is fine AFAIK - As long your app is free and you put in the description that it requires a subscription to whichever service. When you submit the app, you'll need to hand over details to a test account to Apple so that they can test it, but other than that it's no hassle at all.
I know of an app which works just like that on the app store right now - Spotify for iPhone. It's a music playing app which streams music from the web - but you need a Spotify premium account. When you first open the app, you have to sign in, and if you don't have a premium account it just tells you that you're not allowed in!
Javawag
There are plenty of apps which only work if I have an account somewhere, and some for which I have to pay for that account so, without knowing the specifics, there is nothing which immediately rules out your subscription model. There are even Apple apps, iDisk for example, which are useless if you don't have a $100 mobile me subscription.
If there are issues you can look at selling your subscription as an in app purchase (apple will take their 30% which should make them happy) or look at making the app more functional without the subscription.
Either way, when submitting for approval make sure to set up a sample account with a full subscription that the apple testers can use (there is space in the submission for including logins for this kind of thing).
Our app, previously approved, update was just rejected because we sell subscriptions through our website. (We have been doing this for 15 years, without giving Apple 30% of our money.) They are requiring that all subscriptions for iphone/ipad content go through in-app purchasing. I guess we will be looking at building a browser based app instead.
Cheers,
Gerry