Why should you?
A simple example:
1. free app, only local app with, no community records, with ads and a low number of lives but with in app purchase option to buy more lives
2. a paid app, global app that you can see your records against every one else, no ads and double the amount of lives as the first app, but users asks also to be able to buy more lives if they finish what they get in the begging.
so, in conclusion, there are some cases when you need the flexibility of paid app that allow user to buy more things in the app even when they paid for the basic app.
Can it be done? I Couldn't find anything about it, only about freemium apps or free with in app purchases.
10x
Yes, paid apps can include in-app purchases, including one-time purchases and subscriptions.
Related
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
I have Freemium apps in the AppStore. Originally it was Paid but I wanted to see if Freemium versions make any difference in Downloads and Sales. It did make difference - number of downloads increased by 10 times but number of purchases reduced by 2 times. So Freemium modal didn't work for me. I want to change back to Paid.
I do not want to create other versions of the Apps as I have really good reviews on all Apps which I don't want to miss. Can someone please help me if it is possible to convert my Apps to Paid and do not allow people to use full functionality who has already downloaded apps but haven't paid?
I will somehow need to detect they have been using old app and not paid. I can do it by releasing an update that store key in the Keychain but I don't understand hoe would those users be able to pay at all as Apple doesn't charge for the App as it is already downloaded in the past, and they won't be able to use full features as they downloaded freemium app....arghhhhh!!! Not sure if this is even possible but want to hear some of yours thought.
I believe paid upgrades are not possible, you will lose profit and you can't do anything about it unless you are willing to create a new app to replace the old one. The move from paid to fremium is a permanent one, you cannot force existing users to pay after the app is free.
It is possible to move back to Paid, without giving the previous Freemium users the full version.
To do this, you have to:
Know the last version of your app that was Paid
Check the user's purchase receipt (refresh receipt if necessary from Apple)
Know whether the user has made any in-app purchases during the Freemium period (e.g. every time the user upgraded, you added an 'Upgraded' item to their keychain)
Switch to Paid
If you have this information, you go ahead and switch your app back to Paid and:
Check whether they have made any in-app purchases (via e.g. their keychain 'Upgraded' flag). If they have, give them the functionality - easy. If they haven't then go to the next step.
Check the user receipt to see what version/date of the app they first downloaded. If it is during the Paid period, upgrade them to full version. If it is not, and the user has not made an in-app purchase, keep them at Freemium.
Disadvantages
There are 2 disadvantages I can see with this approach:
Any user that downloads the app after Freemium will need access to the Internet for you to confirm their receipt. This means the user might download the full version, then at a later time when they are not connected to the Internet, open the app only to find that they have to Upgrade. Of course once they connect to the Internet and their receipt is validated, they will be upgraded, but in the meantime you might get some bad reviews and angry customers.
Your app will now be a Paid app that has In-App purchases. This may confuse users thinking that if they buy your app, they will have to further upgrade via in-app purchases... and put them off.
Of course the advantage is that your Freemium users will stay freemium :)
I have done this myself, and had no problems with the process.
We are in the process of developing a Cordova iPhone/iPad application, our plan is to release the app in the store as a free app.
We initially thought we would be able to offer full and free use of the app for 30 days, after which we would ask the user to pay to access the app.
The payment would be managed outside of the app (i.e. Not an in-app purchase), circumventing Apple's mechanism and the revenue split.
However from all the reading we've done around in-app subscriptions and taking payment outside of the app store it appears this may not be possible and we will struggle to get the app approved.
In an ideal world we would:
Publish the app
User download the app
User uses the app for 30 days
On day 31 we ask the user to pay for continued access
User taps a button and pays via our payment gateway
User returns to the app and can continue to use the app forever
We will also be releasing a web app, same functionality and same payment process required.
Im almost 100% sure that Apple will turn us down for this, we are essentially offering a trial of the app and then asking for payment simply to circumvent the revenue split - at least thats how it can be interpreted.
I'm trying to find a workflow (user journey) that would work in our case but also with the app store process.
Thinking something potentially like the Spotify model, where a subscription is required (Username/Password) and then the app is downloaded?
Your original idea is going to get you rejected for sure. What's wrong with offering some of the features through IAP?
From the submission guidelines:
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
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
Additionally, you can do the subscription model, but beware of this as well:
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
Seems like Apple become less strict to that rule. I can't find any mentions like this: "Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected" in current docs.
Here is a new one:
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.
https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
Also, Netflix has launched the app with the ability to buy a subscription outside of the Appstore:
https://www.extremetech.com/mobile/276066-netflix-experiments-with-bypassing-apple-app-store-subscription-fees
I am planing to publish an iOS app. App should be Free for first 1 month from installation in the Device. Once the 1 month period is over , user has to subscribe to use the application every month by paying some X amount.
1) Will apple allows such applications ?
2) If allows, how to achieve this kind of Payments ?
3) How to prevent user to access the app after 1 month. (Calculation of the Days)?
4) Should i reinstall the app after subscription ?
IAP is supposed to be used to provide additional content and features to an already functional app.
If you render your app useless or without functionality after a month, it will probably be rejected, or banned after approved. I believe you can't have an app that will simply say "Your trial expired.".
In my opinion, you would need to think of a functionality that you can provide to all users, regardless of they paying for it or not, and have the premium or the extra functionality purchased as a In-App Purchase.
Apple does not allow free trials in the app store. If you try to do this, your app will get rejected. Still, there is one category of app where Apple does allow a free trial: apps with auto-renewing subscriptions. These were originally intended for (and only allowed with) Newsstand apps where the subscription is for getting new content such as magazine editions etc.
Apple recently allowed the use of auto-renewing subscriptions in non-Newsstand apps but it's still a very grey area as to what exactly Apple will allow with these. Usually the subscription will have to provide some kind of periodic new content in your app. I agree with those who recommend against using them.
We sell minutes to call other countries, and we want to allow users to make payments within the app. These minutes have a cost to us from wholesalers. Using in-app purchase will dramatically increase the cost to the user if Apple takes a 30% cut.
1 - "You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services." (Source)
I'm not sure if this applies to me or not. Can anyone shine some light on this?
Only Apple can give you a definitive answer, but the way I would interpret the paragraph quoted below, you have to use IAP for purchasing credits, and you also have to be able to use those credits directly within the app (i.e. make phone calls):
Apps that use IAP to purchase credits or other currencies must consume those credits within the application
Section 11.2 of the App Store Review Guidelines says this:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
If the minutes you are selling are consumed by an iOS app (any app, not just the app in which the user buys the minutes), then this rule applies to you.
If you are selling minutes that are added to a calling card that the user physically possesses, then you might be able to bypass Apple's IAP, but you'll have to either submit your app or talk to someone on the review team to be sure.
What you're selling is a digital service - connectivity. Your IAP product is similar to credits in most games in available on the store.
The real-world goods and services they prohibit are things like you'd carry out of a store in a shopping bag, or having somebody carry that shopping bag. They don't allow the sale of tangible things, only electronic. Goods for sale should be transferrable between two different devices.
I don't think you can avoid in-app-purchase for what you're trying to deliver from inside the app.
I think your case is much like Skype iOS app. You will need to go through in-app purchase for your app as the credit will be used to make calls via app to other countries.