We have been asked by our client to develop an application that would enable redeeming gift codes that unlock additional content. The Application itself would not provide a way to purchase those codes.
It would work something like this -
1) a customer shops for groceries
2) when reciving the receipt/bill at the check-out the customer recieves a gift code.
3) entering this code in app unlocks additional premium content inaccessible otherwise.
The question is if this app would be approved by Apple?
In our opinion this model falls into the following point in Apple’s App Store Review Guidelines
11.14 Apps can read or play approved content (specifically magazines,
newspapers, books, audio, music, and video) 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
not receive any portion of the revenues for approved content that is
subscribed to or purchased outside of the app
but on the other hand there's this point:
11.1 Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
Have any of you know of application using similar business model?
We did something very similar for a major snack food company. The user entered EAN codes (the European equivalent of UPC codes) from the packaging to unlock different musical instruments from within the application. Apple did not reject the app and it is still for sale today.
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'm making an app for a certain museum. Some parts of the app should be restricted only for visitors purchasing tickets with a code printed on them.
This code can used to get access to the restricted parts of the app.
Is it something apple can reject?
There is no way apple can reject your app. It has changed strict guidelines of its iOS developer agreement to allow in-app subscriptions outside the App Store.
The App Store Review Guidelines states the following:
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) 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 not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app.
Regarding Feb 2018 version of App Store Review Guidelines 3.1.1 this is not possible for now.
https://developer.apple.com/app-store/review/guidelines/#payments
3.1.1 In-App Purchase: 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 use in-app
purchase currencies to enable customers to “tip” digital content
providers in the app. Apps and their metadata may not include buttons,
external links, or other calls to action that direct customers to
purchasing mechanisms other than in-app purchase.
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.
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)
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