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..
Related
we are developing an iPhone app as an extension of a classifieds system (web site). On that web site users can buy (prepaid) credits and use them to boost and promote their ads. Will Apple reject our app if we implement consumption of credits? We are not gonna allow buying the credits, just using them (users will still have to buy credits on the web site).
Only worrying thing I found is item 11.2 in App Store review guidelines:
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 there a way to contact Apple directly regarding this question?
And a add-on question. I suppose we can implement a payment gateway system like Amazon and Ebay and get a way with buying credits? I don't see any restrictions in guidelines regarding non in-app purchase system.
"In-app purchase" is only required to purchase content or extra-functionality or extra feature or to remove any type of limitations inside the application. To achieve these things you shouldn't use any other external purchase mechanism (per App Store review guidelines ยง11.2).
In your application, the user will only use the available credits which are already bought on your website, so there is not an issue, although you shouldn't provide any type of link to your website inside your application.
Genererally "will Apple reject this if..."-questions can only be answered as such:
Apple does as they like. If they feel this in some way breaks the review guidelines, they will reject it and tell you, but you have no way of knowing for sure until you have submitted the actual app. In your case, I can't see why they would ban it, as you are not able to use real money within the actual app, but as I said, you don't know.
If you want to try to get an answer from Apple, you can try to contact them from this page.
I finally got an answer from Apple. It took a while and it wasn't worth a wait. I think Siba was right, but I'll get back to you after we submit our app just to verify everything.
Apple replied:
Thank you for taking the time to contact us about your app design and concept questions. I understand that you would like to know if you
implement consumption credits into your app would be acceptable for
your app.
While we cannot pre-approve apps, we can address compliance questions
about specific App Store Review Guidelines or sections of the iOS
Developer Program License Agreement (PLA). I understand that this may
be a little frustrating and I apologize for any inconvenience this may
cause, however, we may only answer specific questions concerning the
following resources, unless the app is submitted for review so that we
may test the functionality.
I've to implement online payment method in my app for selling some products like gift items. Which method will i use?in App purchase or paypal? Does paypal implemented apps accepted in appstore? plz help me.
If they are actual items that one would use outside the app. Like a book, or a DVD, and not something for use in the app, you need to use paypal or something similar. In app purchases are only meant to purchase added functionality or extra content within your app. See also Apple documentation
Apps with other payment methods than in app purchase are accepted, as long as the purchase is not added functionality or content for your app.
To answer your question lets understand two basic things:
You use Paypal implementation only and only when you purchase physical goods like gift items as you mention.
You use In App Purchase when you need to provide/ unlock some feature inside your application itself.
In your case as you mention you need to have transactions for gift items you have only one option i.e use online transaction APIs like Paypal.
Regarding your second question, Yes Paypal integrated apps are accepted in App Store. There are plenty of such apps already in the App Store
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.
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