I want to create an app that will be displayed as FREE on the App Store, but upon opening it, users are required to do and in-app purchase to be able to access any of the content. I am reading the App Store Review Guidelines, but I am not sure if Apple allows this since the users will not be able to see anything on the app unless they subscribe to it.
The reason I need this is because my client wants the app to be sold at $0.99/year and I don't think this can be done by setting only via Price Tier.
Create a membership only app.
You must sign in to use the app (you can give apple a test account)
then you can manage the membership on your own servers. Or allow them to sign up with the in app purchase.
(enable both the user login and the in app purchase to get a user login, then you can give apple a "test" account that requires no purchase)
They will test your in app purchases anyhow so make sure you follow all the rules on Re-Activating in app purchases, this way if the user comes back and reloads their purchase and they have 2 months left you are sure the app will still allow them.
As long as you dont try to accept credit cards from the app, and use their in app purchase system you should be fine.
If you want to enable users to purchase their account from your server, you cannot allow the purchase from the app. The login however can enable the app without the purchase (and the test account should) but in app purchase should allow them to attach their purchase to the account they use.
I think im rambling now so I hope thats enough clarification.
What you can do is present a demo of the app as a feature before the user buying in-app purchase.just a screen extra. So that Apple does not reject it.
The other option is:
If you have a login/password app, you can tell apple that your app requires login before any feature can be given, only if your in-app thing is login related.
Related
Ok, I suspect the answer to this is simple. But here goes...
I am in the process of submitting my app. I am submitting for review even though my In-App purchase integration has not been tested. This is essentially because I am unable to retrieve my list of IAP items if the IAP items have not been submitted/verified. So it seems to me this is like a "chicken or the egg" kind of situation.
My plan is to submit the App and the 1st IAP item. Then I am assuming this will allow me to magically retrieve the IAP item when I run the App.
Am I approaching this correctly, or is there a more intuitive/simpler way to test the IAP retrieval process (and the many other things to test once it is retrieved)?
Per Apple's Documentation:
To perform testing for in-app purchase products Set up test user
accounts within Users and Roles in iTunes Connect, as detailed in
Creating Sandbox Tester Accounts in iTunes Connect Developer Guide.
You’ll need a test user for each territory you want to test the app
in.
Clear any account information stored on your test device.
In Settings, go to the Store settings. Click the Sign Out button. This
prevents an actual user account from automatically being used when
testing.
Important: Don’t enter your test account information in the Store
settings panel. Doing so may invalidate your test account. Connect
your test device to your Mac.
In Xcode, set your test device as your scheme’s destination.
Open your app, and perform your in-app purchase product testing.
Use your test account credentials to test the purchase.
When your app uses the Store Kit API to request a payment, you’re
asked to sign in. Select Use Existing Account and enter your test
account user name and password. You are then asked to confirm the
purchase. The transaction completes.
No financial transaction takes place, but a receipt is generated for a
successful transaction.
It's pretty straightforward, just takes a bit of set up. Good luck!
We're designing an iPad app at the moment which offers in-app purchases for non-consumable items.
As the scope of the project has expanded, we want to allow the option to sign in to an account, and then sign out of that account and into another - similar to how one could on an app like the Facebook app.
My question is: is it possible to link Apple's in-app purchases to one of our system's user accounts, so that a User may sign in to a different device and access their purchases, but if another User signs in to my device, they cannot access my purchases (despite the device being signed in to my Apple ID)?
Any suggestions welcome
All completed in app purchases are tied to the Apple ID that was used at the time of the transaction. Since non-consumable in app purchases can only be purchased once, you can't use those. So, the only option would be to use consumable in app purchases and keep track of which system user account made the purchase. You need to store those purchase records on an external server somewhere though, since Apple will have no way of telling you which purchase went to which of your internal users. If you lose that purchase history your users will have to buy the item again, and probably not be very happy.
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 am stuck with one of the in-app purchase rejection issue in my app and need some help on this.
What this in-app for?
In our app we have options for user to become premium user. A user can become premium user to enjoy some benefits and it is tied to time. There are two in-app products which defines them
One month premium service.
One year premium service.
Since these are time based service, user expects these service should be made available for that user once he/she purchase the product for the specified time, from all his/her other devices. In order to track whether the user is premium service user or not, once the purchase is done, the app writes a entry in server about premium service. So when user uses other device and logs in, he/she can enjoy the premium service without any issues. For this reason I created the above mentioned products as "consumable", thinking that it is controlled by our server there will be no issues. But apple came back with rejection and asked me to change the products to "non-renewing subscription".
Here is what apple says about this
We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
"Premium account service for 1 month and 1 year" IAPs are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Renewable Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
The Purchasability type cannot be changed once an In App Purchase product has been created. Therefore, you will need to create a new In App Purchase product with the correct Purchasability Type. To create a new In App Purchase in iTunes Connect, go to Manage Your In App Purchases, select your app, and click "Create New". The current product will show in iTunes Connect as "Rejected".
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
For more information about Purchasability Type, please to refer to the iTunes Connect Developer Guide.
Now I have created new in-app products which are non-renewing. But this works the same way as I mentioned earlier, i.e. the server keeps track of whether user is premium user or not, expiry date. When user goes to other device and does login, the app comes to know whether user is premium or not and based on that app works.
But I have couple of questions on this,
Should I need to provide the "Restore" button in the app? If so what is the purpose and how it works?
Since the user can access this service only after doing login to the app (it is different from app store account). Will these two logins make any issue?
Please share your valuable inputs.
It is highly unlikely that the user will end up in a situation where they won't be able to use your app unless they restore their purchases, however it is still possible. Imagine your server goes down for a day and during that day some user purchases a subscription, gets a new iPhone, installs your app on the new device and then wipes their old iPhone. I can think of a couple of other, equally unlikely, but still possible situations (Apple receipt validation server going down, etc) in which the purchase receipt will get lost in transit. It's best to provide the button, and if Apple thinks that you need it in your app, you will have a hard time convincing them otherwise.
If by "two logins" you mean user having to log in to your system and then log in to the App Store to purchase the subscription, that should not be a problem.
I recommend you make the changes Apple requested to the Purchasability Type and then re-submit. If you need to clarify a lack of a restore button put it in the notes for the reviewer
Reasons
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.13
We found that your app provides access to account registration. As this also provides the user access to mechanisms for purchases or subscriptions to be used in the app, this is not in compliance with the App Store Review Guidelines.
Since the app includes access to services already purchased or subscribed by your existing users through means other than IAP, this is considered as a form of external mechanism.
Please see the attached screenshot/s for more information.
To be in compliance with the App Store Review Guidelines, it would be appropriate to remove access to account registration.
－－－－－
The hotscreen is regist and login.
We had delete all links from App in 'about' ViewController.
And it just has a regist/login page in my App that is not have function of 'buy'.
But there is can pass with regist/login page in My other apps.
My App is free app that is to show some video in iPhone.
The Video is also free in App that is not need to buy.
The user can regist a user to comment or favorite some video.
I also have a web side for this. and user can buy some Charges Video in it.
－－－－－
I hope someone can help me！！！
It seems that a registered user of yours can access stuff they bought on your website.
That is what apple is complaining about.
If you remove the login/register it will go through or use it just for commenting - maybe you can trick apple by renaming it to login-for-commenting/register-for-commenting (and for the time until it passed, disabling the "view-my-bought-stuff" from your website, so you can enable it without re-submitting the app)
I assume purchases are done at some external web-site of yours.
You cannot refer to Buy in your app, if purchases are not done via App store.
You have to look for alternatives, like use DB at your web-site for user purchases validation.
User can login and their purchased items shall be available for download.
You can have an information button or something which tells user to have a look at your web-site for more information/ "you might also like".
Please note selling your stuff via App store shall be made on Apple inc terms only.
This do not restrict you to sell your stuff outside App store, but you cannot have selling links in your app.
You should not have user registration in your app, until you are using IAP.
This is stated in 11.12.
However I still feel you can have login in your app, and do registration /selling outside the app. This gives you liberty as your app is not selling content/neither doing any user registration.
I am having a couple of apps with my developer license and doing this i passed all validations of app submission both legally and review process as well.