We are an university department for further education courses and we are planning to publish our cd based courses as an additional iOS/Android App. As we have almost finished the development process we are now facing some questions regarding the distribution. The basic idea is to publish the app in a lite version for free (including chapter one of the course). After you have completed this chapter you will be asked to enter your login data. Our students will be able to enter thier data to activate (download missing content from our server) the app. If you are not an enrolled student there will be a link to our course page. On this page you can enroll for the courses and of course there is a charge for this.
But Apple only allows purchases via the App Store or as so called "in app buys".
Will we violate this rule with our idea?
I have found some newspaper apps with basically the same concept: download for free. If you have a print subscription for this newspaper you enter your data and can use the app. If not you can subscribe for the online offer via an in app buy.
After days of research we have no clear answer to this scenario.
Any comment appreciated.
There are two possible solution for your situation:
Without In-App Purchase: You can create an app which can have a eBook (in your case, dummy eBook with chapter 1 content) bundled with the App.
By doing this anyone who can download will have access to the dummy eBook as well.
For downloading of additional-contents user can do login and access the eBooks available with their account.
Kindly note as you are not using In-App purchase there shall be no links for user registration, buy inside your app.
All these you can handle at your web-site.
Your app can check for valid user credential using a web-service call, and user can see the contents available for download.
Advantages: 1) You shall not be paying 30 % to Apple as No-purchases are done using your app.
2) This is total compliance with Apple guidelines, this link and part 11 specially will be of interest.
Disadvantage: Users cannot directly buy/register via app and you need to maintain additional services for user login validation/content mapping/download content etc.
Using in-App Purchase:
You can use Apple provided in-App purchase for selling content/ registration of users etc.
Please note Apple shall charge 30 % on your selling price.
Advantages: Users can register and buy directly using your app. In-App purchase guidelines will help more in this.
Disadvantage: Apple will charge 30% on Selling price.
Given what you are trying to do, there really is no clear answer for your question that this community can provide, I'm afraid.
The true answer is entirely up to Apple's current app review policies. You should probably submit the app, explain clearly what you are doing, and if it gets rejected/denied, you can follow up with an appeal to the app review board.
As far as I know, physical items that are purchased are not subject to Apple's 30% cut. However, since you're offering courses / content over the 'net, Apple may want some percentage (between 0 & 30%) of the the profits you're making. Maybe they have a different arrangement with newspaper publishers. Ultimately, you'd need to submit the app and find out what the reviewers and app review board say.
Related
I don't know where to answer these questions. I uploaded the answers in app review information note section but didn't work. What should I do?
The review message is attached below.
Guideline 2.1 - Information Needed
We’re looking forward to continuing our review, but we need a bit more information about your business model and your users to help find the best distribution option for your app. Our preliminary review of your app suggests that your app may be a good fit for our Apple Business Manager program, which is designed specifically for business apps.
Next Steps
Please review the following questions and provide as much detailed information as you can for each question.
Please describe which kinds of users you expect will use your app. Some common kinds of users are:
Users who are part of a single company (including its partners, employees and contractors)
A limited number of companies which are clients of the developer
The general public
Identify the specific countries or regions where you plan to distribute your app.
What features in the app are intended for use by general App Store users?
How do users obtain an account?
If there are any paid aspects of the app, such as for opening an account or using certain features in the app, please explain how users access the paid content.
Who pays for the paid content?
Since your App Store Connect status is Metadata Rejected, we do NOT require a new binary. To revise the metadata, visit App Store Connect to select your app and revise the desired metadata values. Once you’ve completed all changes, reply to this message in Resolution Center and we will continue the review.
You need to navigate to the app in Appstore Connect, click on "Version History" and then click on "Resolution Center". On that screen is a form where you can reply to the inquiry from Apple. It took me longer than expected to find it.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
We have a print magazine and we're going to release an app with subscription model, sort of kiosk app but with extended functionality.
Well, what we want is to solve the following cases:
Case 1 (complex)
User buys a print issue and discovers a promo code in it. This code should allow user to download free digital copy of this issue from our app.
User launches the app, opens a dialog box where he can enter the promo code.
Voila! User gets his free digital copy of purchased print issue.
Digital issue always remains in his list of purchased issues and is a valid purchased issue with all App Store options available for them (restore, etc.)
Case 2 (simple)
User does not have a print issue. He launches the app and buys the same digital issue using IAP.
So, both issues are the same (i.e. "blablabla magazine", November, 2014) but 1st was downloaded using a promo code, and 2nd was purchased with IAP, and they both should have the same properties and "weight" for App Store.
Problem is I don't know if this model will be approved by Apple. Or, if they do, how do I develop this? AFAIK, list of purchased and non-purchased items is provided by App Store and there's no way to intervene this process.
I didn't find any samples of using 3d party promo codes in iOS apps. Can anyone provide a solution for this, please?
Thanks
To keep a record of the promo code usage, I think the simpliest way to do it is to require an account. Once the user is logged with his account, you can tell a server that the promo code have been used with that account. If the user delete/reinstall your app, you will be able to restore all his promo codes from his account.
For your issue with IAP and promo codes, here is the App Store Review Guidelines
See the 11.16 section:
Apps may enable additional approved features or functionality when
used in combination with specific approved physical products (such as
a toy) as long as the additional features and functionality are either
completely dependent on such hardware (for example an App that is used
to control a telescope) or also available through the App without the
physical products, such as by way of reward for achievement or by use
of IAP
So basically, what you want to do shouldn't be rejected.
But by experience when you do something that borderline with Apple's money (possibility to "undercut" IAP), you should expect a review failure, whatever the guidelines review says.
Keep in mind that the guidelines can be interpreted in your advantage, or in you disadvantage.
I am looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
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
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.
I have created a course site, let’s say 10 courses. Each price is $1.00. Now I have each course have ios application. If user pays for my course from desktop site, they can use same course from application also.
Now see, if user has downloaded my free app. If user wants to purchase, I have put up a link which redirects user to my desktop site and purchase course. Once he purchased course, he will be back to ipad app and learn course.
In short apple will not get its 30%. Will these going to be approved by app store when they don't get their 30% cut
The rule is pretty easy, the hard part is how Apple review team will understand the contents that you provide in your app.
If your contents can enhance or complete the app somehow and is distributed in a digital format Apple will require the integration of In App Purchase.
I remember that I've read from a blog a case similar to yours. The writer was complaining that the review team was constantly rejecting its app, because it was selling a CDROM containing an HTML course (I guess) that was "started" in the app. The end of the story is that he was able to put the app to Appstore but after a lot of rejecting. Once the Apple review team had understood that he was selling physical good they released the app.
I your case I think that IAP is the way to go.
Reading the point 11 of App store review guidelines will answer some questions.