I would like to distribute an application where only registered and paying customers of our company can have access to. The app would be distributed in the app store for free and users would have to log in with the registered details to use the application.
The problem is that the app will have certain amount of functionality based on what the registered customers have paid us. For example customer A paid us $500 for the registration and hence he will have the full functionality of this application. On the other hand customer B paid us $250 and this customer will only have half of the functionality of this application.
Is my company allowed to do this?
You cannot do this sort of thing in the App Store, if that's what you're asking?
You might be able to do something similar via the iOS Developer Enterprise Program instead: http://developer.apple.com/programs/ios/enterprise/
You will need to be carefull about Apple's rules for app content. I am far from an expert so I am only suggesting you look into the possibility that Apple will view this as an end around their In App Purchase.
From what we have learned in our research is Apple doesn't allow the sale of app content or features that are not sold through Apple's approved purchase systems. A magazine app that sells a subscription qualifies as selling content. An app that provides additional functionality based on a monetary transaction also falls into this situation. You can sell a widget (food order, event ticket or clothing) without running afoul of this.
If you go down this path, you should not make mention of the payment difference affecting the features in the app. Apple will want a login that gives them full access to the app features. You may want to consider publishing two apps. One fr the different kind of customer.
Perhaps someone else can shed more light on this issue.
Related
The iOS App Store offers schools 50% discounts on bulk purchases which is great. Is there a way to determine, at the app's runtime, if the app was installed via an educational purchase?
At runtime? No. There is no way to get any information about the purchase of your app.
In sales reports, thats another question.
I would assume attempting to modify functionality of the app based on educational purchase is against apple's rules. Your contract states:
In addition, you may, at your election via iTunes Connect, instruct Apple to market the Licensed Applications at a discount of 50% of Your established price tier for authorized institutional customers.
Which sounds to me like you can optionally agree to ship the same app but at a reduced price.
I'm writing an iPhone app. The question is regarding the new rules restricting purchases inside the app.
So: the user charges their account up with 'credits' on the associated website using real money via a payment provider. The user installs the app and logs in using the same account as is used on the website: they cannot use the app without first logging in [edit: although they can register an account without adding any credits.].
The purpose of the app is to build up a report about a property, which can then be emailed out, or exported to their account to appear on the website. The report can be built up without using any credits. However, to export the report to the website or email it out, these credits must be expended by contacting the server and debiting X amount from the user's credits.
Here's the question:
The user's account is debited whenever they do this export. Only if/when the user's account is out of credit does the app complain that credits are low (otherwise it doesn't mention them), and it tells the user to go to the website to top-up their account to proceed. Remember that they can't login without an account, which can only be created on the website, and the website explains this.
From the guidelines:
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
So, my app does not provide a link to the website when explaining that their account is low on credits, it just says that this is what is needed to proceed. The export function, however, does require that the user has topped up their account, so in a sense this does fall foul of the next rule:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
I'm somewhat worried that this credit currency will fall foul of these recently-tightened rules, does anyone want to please reassure me (or, break the bad news)?
P.s. Spotify requires that users pay a subscription (on their website) to use the iPhone app. The difference between them and the above is that their subscription is unlimited-use whereas the above has a per-use charge.
Thanks in advance,
Ian
When you submit your app, include a tester username / password to the App Store. Fuel this account with a few million credits so they don't see the reference to Credits Low. There are many apps that get rejected just for having a login - if you make the reviewer's job easier by having a user/pw they can use, it'll increase your chance of acception.
If you app does get rejected, it means you have to change your model anyway. Actually - you might just be able to add 'Buy Credits' as an in-app purchase to appease Apple. Just make sure the credits in-app cost the same or less than externally - as far as I can tell, Apple will let you keep external purchases around as long as they cost the same or more than in-app purchasing.
Additionally, make sure your "low credits" alert doesn't link to an external page to buy more credits-- this may be frowned upon.
I'm sorry to break it to you but it definitely is a grey area and could potentially get your App rejected because you are asking the user to go to an external source to purchase credits which means Apple is cut out from any potential revenue.
I've had first had experience with this sort of rejection, all that was the issue was the description pointed to a web page where you could buy the product but Apple still had a hissy fit about it and added 2 months to the approval time and it ended up with me removing the link.
You could warn the User that their credits are running low, however pointing to the page to purchase them could potentially be the tipping scale.
On the other hand, there are some apps which make it through but there is no certainty. You are at the mercy of the reviewer in the end... You could potentially ask Apple Developer Support for any further information after describing your scenario.
I'd like to sell products through my application (insurance policies) and I don't want to use the in-app purchase mechanism as it would mean sharing 30% of the product price. Instead I would like to provide the user with a page to enter his/her credit card details and perform the credit clearing through my own self-developed secured services.
My question: is selling products which are not content or features, using my own purchasing system, prohibited by Apple or appstore policy?
Obviously, I am not a lawyer, but I think you’ll be OK. Here’s my interpretation of the three relevant rules from the developer guidelines (emphasis mine):
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.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
The first rule prohibits you from unlocking anything inside of your app with something other than the App Store. This would prevent you from, say, making a game that downloads new levels from your server based on your membership to a website.
The second rule prohibits you from, say, making a game and enabling PayPal in it to unlock more levels. Apple wants you to use in-app purchase for that.
The third rule—and this is where it gets interesting—prohibits you from using in-app purchase in an application to buy “physical goods” or “goods and services used outside of the application.” Nowhere does it say, however, that you can’t use other purchasing systems.
With that third rule, I think what Apple is saying is this: anything that runs on the iPhone must be purchased through the App Store, and everything purchased in the App Store must run on iOS. For something like insurance, which isn’t new functionality in the app, I think you’ll be OK. This is absolutely worth an e-mail to Apple’s technical support staff, but if you look at Amazon’s app, you can purchase physical goods using Amazon’s checkout system.
Quoting from Apple's Guidelines - 11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
So, you should be fine. This is validated by apps that are already in the Apple app store, such as Groupon, Fandango, Chegg and others that charge users credit cards for physical goods or goods consumed outside of the app without passing the transaction through Apple.
It would be great feedback for everyone to hear whether you had any difficulties with Apple when publishing your app or not.
11.10
Insurance applications must be free, in legal-compliance in the regions distributed, and cannot use IAP
https://developer.apple.com/appstore/resources/approval/guidelines.html
Also read: http://www.quora.com/How-do-eBay-and-Groupon-get-around-Apples-in-app-purchase-system-despite-being-native-apps
In general you can sell physical products via an app. You cannot however use the InAppPurchase mechanism for this, but are required to use your own payment mechanism.
Ruling on this seems somewhat unclear from the guidelines. Would be interestig to hear whether your app got accepted.
We just recently submitted an app that featured in-app purchase of non-digital goods and everything went through without issue. Take a look at the following to get more insight:
Does Apple test purchase of physical goods during their app approval process?
We have developed an application that allows a user to download audio content. The use of application itself is free, but we charge for the content. In our current business model, we accept payments using premium-rated SMS (which increases the in-app user's balance), however, Apple rejects the app since they do not allow this model for their applications.
Is there any other way (except In App Purchase API) we can accept the payments with?
Apple will only accept in-app purchases for this type of business model. Even then, you still have to submit each and every "in-app update" for approval at least a week prior.
Like Liam said, they want their piece of the pie too and they also don't want people slipping something past them (for instance, highly offensive content, pornography, etc.)
Per Apple:
You can create In App Purchases on both Free and Paid applications. Every product you want to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.
There's no other way with this type of business model. More info here around page 116
Another option would be offering the same service via an ordinary website and then offer the app to allow users accessing their existing accounts. Take dropbox as an example - they offer paid memberships which you purchase on their website. The dropbox app itself is free but lets you access your dropbox account, for which you paid elsewhere.
In your case maybe you could offer "credits" for purchase (payable by premium-rated SMS) on your services website which the user could then spend by accessing his account from within the app.
This is less "direct" (requires the user to visit your website to pay for the content he will download later) and I wouldn't even bet on apple's approval (if the website appears to be merely a place for buying credits without further functionality, they'll propably reject the app too for circumventing in-app purchase), but then again, there are (propably) no alternatives. However, I'd talk with apple about this option before implementing it, to avoid wasting time and money. After all, in-app purchase is the way apple wants people to go if they want to spontaneously purchase content using only their device, so they'll defend it.
The easiest was to look at this is to work out why they refused the application, which is because it is not in their interest. You are selling a product to their customer and they are not getting any commission. In order for them to accept the app I would imagine that you will need to provide an in app purchase mechanism, but you could do this in addition to the Premium SMS as long as the app doesn't send the message
I do some work for a company and we have an idea. What we'd like to do is throw in a simple iPhone app if they purchase with our company. We'd build the app, but the new business would sell it on the Apple Store. Is this possible without having the business go through all the hoops of signing up for the Apple Developer Program?
To be clear, our company would do 100% of the work. We'd just like to give the app to our customer and be done with it. We'd rather not see dozens of very similar apps under our company's label.
No. The submitting company will need to join the Developer Program and be approved and pay the annual fee.
You could (in theory) sell the app through your account, and give them the money. However the application would NOT be listed under their business name, something no business in their right mind would put up with,