I am currently building an app for an existing and large Royalty Free music library. They sell stock music to be used in productions/websites/commercials etc. What they sell is the license to use the music in your production.
What they want to build is an iPhone and iPad app that is basically an extension of their website. Users can browse and purchase music through the app. I am building a web service to connect to the existing website and will most likely use Webview to handle payment via PayPal. The user is then sent a download link for their music via email after successful purchase
The question I have is whether Apple will reject due to the way we are selling goods. This is an already established business and the iphone apps are just an extension of that.
Any help is really appreciated.
If you sold using in-app purchase (30% to Apple) they would probably accept it. Otherwise not, and you should stick with a web app (which you could highly customize for the iPhone/iPad).
Most likely would get rejected. One option might be to use the iPhone app to browse and sample the tracks, but link out to a mobile safari web page to complete the transaction.
It will definitely get rejected.
My app had a link to our website that had a puchase link. They rejected the app for that too.
Buying directly from the app is not allowed.
Related
I am developing an iphone app and it demands me to sell some real world products with it. I know that guidelines of Apple would not permit me to sell them through In App purchase functionality, So for now i am concentrating more on paypal integrated way. Still, i have ambiguities in mind whether it would be appropriate way or not because i have gone through several forums which says that apple reject such applications. Any input on it would be great help.
Thanks in advance
An iOS application I developed offers 2 payment methods instead of in-app purchasing (also for real world goods). This application has been accepted and has been in the iTunes Store for a few months now.
The way it works is that the application sends you to a mobile-optimized website (opened in Mobile Safari). After payment, the mobile-optimized website shows the app icon + special link "application_name://command", when tapped the application relaunches and uses the "command" text to update some local data & showing a "Thank you for your payment" screen.
Further reading:
http://developer.apple.com/library/safari/#featuredarticles/iPhoneURLScheme_Reference/Introduction/Introduction.html
I'm developing a website and a companion iPhone app where users can purchase video content. I'd like to let users buy content from the iPhone app or the website, and then view their purchased content through either medium. My understanding is that the app will be rejected from the App Store unless it uses the StoreKit framework for in-app purchases, so I can't implement my own purchase backend. As far as I can tell, though, there's no such thing as a web version of the StoreKit framework.
Is there any way to make/verify "in-app purchases" from outside an app, e.g. through a website?
There must be, because the DC Comics/Comics/Marvel Comics apps from Comixology all do. You can purchase content either from the in-app store, or via the website. And then you can read the content both in the device or online.
Alas, I don't know how they did it. I guess that the web shop replicates the in-app purchases when you buy something: i.e., the device calls home after an in-app purchase and adds that purchase to your online account as well. And, when you buy something online, you can download it from within the app, bypassing the apple store. You can even download content in one app that was purchased in the other (they are mostly the same app with different branding)
I am building an app for a charity and they've requested the ability to receive donations from the app. In reading the app store guidelines I came across this:
21) Charities and contributions Apps
that include the ability to make
donations to recognized charitable
organizations must be free The
collection of donations must be done
via a web site in Safari or an SMS
I can build the solution in Safari, that is not a problem, but I was wondering if anyone knew if apple would accept the application if the web donation form was accessed within the app through a WebView Control. I have seen other apps accept credit card payments within an app using a webview, so is it possible to do the same with charitable donations or is it a requirement that you actually have to use the Safari application and leave the application to make a donation?
Hope this make sense.
We have a similar app (instead.com and the iOS app along with that in the app store) ... We spoke to some apple employees last year at an apple conference and they said we have to go to safari outside of the app. It was tied to liability reasons. Being in a webview inside the native app still gives the perception that it's the app making the donation or handling the donation. It's 2 sides of the same coin. So they told us we had to go outside to safari.
Your interpretation sounds like that's what Apple means. You are supposed to handle it in a browser, not through native code.
You can call them in California and ask for the App Review Department.
I'm not sure which one of these is the corporate office: (408) 996-1010 OR (512) 674-2000
EDIT:
I called Apple and they referred me back to the same vague manual. The fellow there didn't really know. I guess you should go for it and see what they say.
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
I am developing a native iPhone app, where end user can purchase calling cards of different rates.
The problem I am facing is that, I don't what can be several options to integrate payment / online purchase feature and they can be integrated.
Few sites I have read that, you can implement this using In App Purchase, but there using In App purchase Apple will take 30% of payment. Also, I need to register each of my product with Apple -> iTunes Connect -> Manage In App Purchase, which is again not a feasible thing to do. As my products would have different rates and they get updated regularly, so every time I have make changes in iTunes Connect.
Another option can be to integrate Paypal for purchases but, here I have open the web interface (either safari browser or UIWebView) from native app when it comes to make payment. Problem here is that, opening the web interface would fine, but I need to come to native app and same point in the app from where I did the payment. Also, I don't have prior experience of integrating Paypal.
Please guide me to find the best suitable option to integrate payment feature in native app.
You definitely need to read the Apple-iOS-Standard-Agreement, to find answers about InAppPurchase:
Attachment-2 to the iOS-Standard-Agreement Feb. 15th 2011, 1.1, 2.1, 2.2:
... this makes clear that you are not allowed to use InAppPurchase for selling calling cards. InAppPurchase is only allowed for content & functionality you provide the user within your app.
AS InAppPurchase is not the way you can go, you may use the Mobile Payments Library for iOS, PayPal release last year. The lib is well documented and ships with sample code:
https://www.x.com/community/ppx/xspaces/mobile/mep