I have a website that provides a service that customers pay a monthly subscription fee. I have created apps for Android and iOS to connect to the subscribed account. With this subscription they can connect an unlimited number of users with android/iOS applications to the account.
If I release the App into the Market as free but customers need to register for a paid subscription for the main account on the website then will be seen as a breach of the Market T&Cs for the Play Store and the App Store?
Thanks for any help.
You should be fine - some large companies do this, examples off the top of my head are: Rdio, Economist.
You can only purchase via their website, but by linking accounts you get full functionality.
The company gets to save on 30% fees, but the app is not allowed to provide any links to your purchase workflow on your website - otherwise that will violate the terms.
This is the same for both Android and iOS.
Related
My team is working on a digital music app where users can buy music from local artists on their smartphone. We are targeting Android and iOS platforms to start with. We have the following payment mechanisms on our Android app (among others):
PayTM wallet
Credit card
Netbanking
Our Android app passed the review and is live on the play store.
We used the same payment mechanisms on iOS - Apple rejected our submission saying:
We noticed that your app enables the purchase of content, services,
or functionality in the app by means other than the In-App Purchase
API, which is not allowed on the App Store. Specifically, your app
utilises the PayTM wallet system.
Given our business model, what is the best possible way to comply with Apple's In-App Purchase guidelines, yet function in a truly cross-platform manner. Fundamentally, content purchased for an account should sync to all the devices the user is logged in, irrespective of the platform.
We don't mind using Apple's IAP model, however:
The user's purchase on iOS is mapped to his Apple ID which does not map to his account on our platform. As per Apple's guidelines:
Non-Consumables are In-App Purchases that only need to be purchased
once by the user and are available to all devices registered to a
user.
Our music is priced by the artists($0.5, $2.4) whereas Apple requires their in-app purchase products to be in specific tiers (Tier1: $0.99, Tier2: $1.99, etc.)
App store allows a maximum of 1000 IAP ids per app. How can we possibly map a product Id uniquely to a piece of music when we have more than 1000 different items to sell?
2) You can allow the user to purchase 'tokens', say 99 Tokens for $0.99 or 1099 tokens for $10.99 then charge a certain number of tokens for each purchase - 50 Tokens for a song that costs $0.50. The Token is a consumable IAP. But it is used to purchase something that is non-consumable in that your server will forever remember that they purchased the song. Tell App Review that you are using a Token system (consumable) but creating a non-consumable purchased item if/when they object to the purchase being unsuitable as a consumable.
1) Regarding the cross platform - the user can only purchase Tokens on the iOS app and only spend Tokens on the iOS app and that gets them the songs. When they get a song they write to your server that they have the rights to that song. If they log into your server from a different device then that song is available to them. Ditto from their Android device. Read Guideline 11.14 regarding why they can play that song on their iOS device.
3) not an issue.
I am developing an application for iOS and Android and this app will be free on the store, but to use all features of the app, the user will need to pay a licence every month/year and if he doesn't pay it, he will have only a limited access to the app, with just few features. Moreover, the first month after he registers, he will have full access.
To pay the licence, it'll can be done in the app or on the website.
For that, do I need to develop a function to check on each connection my database to see if the user has paid, or is there already something done. I have look for "in app purchasing" but it seems that it works only for app where we pay once to have full features, and not every month.
Thank you :)
Regards,
There is a system in in-app-purchase for this, just check the url: https://support.apple.com/en-gb/HT202023 and "Auto-renewing subscriptions" tab
you can go for in app purchase / in app billing
iOS,
In-App Purchase lets you sell a variety of items directly within your free or paid app, including premium content, virtual goods, and subscriptions. And just like apps you sell on the App Store, you receive 70% of the purchase price.
https://developer.apple.com/in-app-purchase/
Android
Use In-app Billing to sell digital goods, including one-time items and recurring subscriptions.
Supported for any app published on Google Play. You only need a Google Play Developer Console account and a Google payments merchant account.
Checkout processing is automatically handled by Google Play, with the same look-and-feel as for app purchases.
http://developer.android.com/google/play/billing/billing_overview.html
I am currently working a on a product that my customers will be paying me monthly for. Their product is just a web application but their clients will all be able to download a free IOS or Android app. For their clients to login they will be issued a login from my customers web application. The free app is completely optional for my customers clients. My customers will be able to use the web application even without any of their clients using the app.
My question is... will I have to pay Apple a percentage of the website subscription costs to my customers?? The app experience to the clients of my customers is completely free. If I do have to pay Apple how would I even go about this? It would be very silly for my customers to have to pay in-app when they dont even use the app.
Just wondering if any IOS developers have run into a similar situation and how you handled it?
You would not have to pay apple, but you would have to make sure that the app itself does not link to (or possibly mention) the external payment system. It would be fine if the app allows logging into a paid account, just not purchasing from the app, while circumventing apple's payment system. You could also consider allowing payments with in app purchases being optional, for app users, with others paying through other means.
See point 11.13 at the app store review guidelines page.
An example of a system like this is visible in the Amazon Kindle app for iOS, where you can log into your amazon account and read books you have purchased with the account, but cannot buy books through the app.
EDIT: however see point 11.12 in the link above, you may need to use in app purchases for users who use the app as it says "Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases". You should still be able to offer a seperate subscription for non-app users.
EDIT 2: As in point 11.14 If your app is providing approved content ("magazines, newspapers, books, audio, music, video and cloud storage") you can "read or play approved content...that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App."
Relevant guidelines:
11.12:
Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement
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
11.14:
Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App
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
Am I allowed to share in-app purchases across ios and android?
I would have a free multiplayer game that is on android and ios.
The user could purchase a digital item with the in-app billing api in his android app. I would verify the purchase on the game server and add the item to his online account. When the user opens the ios app and logs into his account, he would stil have the item since its saved on the server.
This would also be done in reverse.
Does the android or ios policy allow this? Or must digital goods purchased on one platform only be available there?
I have already seen games that do this but I wanted to make sure.
Section 11 of the App Store Review Guidelines details the rules of in-app purchases. The short answer is no, you can not share in-app purchases between Android and iOS.
I'm looking for some advice on an app that I am hiring a developer to work on for me - its my first app and his first solo app, so I at least am still getting a feel for the ropes a bit.
My question lies in the area of in-app purchases. My app will use an in-app purchase system that will be used to purchase "credits" for lack of a better word. Each time a credit is purchased it will enable data stored in the app to be emailed to a particular email address.
I had originally thought it would be good to have an external web-based shopping cart to deal with it, but I understand there are APIs available to embed these shopping cart systems into the app. Additionally I also understand that any "digital consumables" that unlock features of the app are subject to the commission that iTunes/Android charge, does anyone have any initial thoughts on whether the ability to email would be included in this?
Many thanks in advance.
Savvas, that's not true at all ... AFAIK , in Android there's some exceptions you can read here: http://play.google.com/intl/en/about/developer-content-policy.html
Paid and Free Applications
App purchases: Developers charging for applications and downloads from Google Play must do so by using Google Play's payment system.
In-app purchases: Developers offering additional content, services or functionality within an application downloaded from Google Play must use Google Play's payment system as the method of payment, except:
where payment is primarily for physical goods or services (e.g. buying movie tickets; e.g. buying a publication where the price also includes a hard copy subscription);
or where payment is for digital content or goods that may be consumed outside of the application itself (e.g. buying songs that can be played on other music players)
So for example, for buying a coffee, you can use your own payment gateway.
I am pretty sure that both iPhone and Android agreements require you to use their own payment services for all in app purchases.
That means you can't roll your own paypal/visa/any other payment system and have your users use that if you plan on distributing the app via the Google Play Store or the App Store.
That being said, you can still roll out your own payment system if you distribute your app via other channels (for android you can have a look at the Amazon app store and other solutions. For the iPhone there is no official third party app store since Apple prohibits it. Cydia is an alternative app store that many people have though in their jailbroken phones)
Personally I am a big fan of Urban Airship. Works great on iOS and Android.