I have an app that I was going to release as a free (lite) version with some of the total functionality and a paid full version with advanced functionality. Now, with in app purchase for free apps I am thinking of going that route with the ability to unlock features as needed. I'm not talking about a trial version that expires.I want people to be able to try out the app and get an idea of the interface and functionality before deciding to purchase the full functionality of each major section of the app, basically.
Here's an analogy of what my app would be like. Let's say you have a cooking app that teaches you to cook in different styles. There could be major section for French, Italian, and Chinese. Each section could have some rudiments unlocked in the free app so users can see the UI and basics of the functionality. Then, the user could decide to purchase each major section (or not) individually with in app purchase or buy the full versioned app (with the free/paid model).
One concern I have with offering a free app with in app purchase would be with feedback. I would be very clear in my description in the app store that there is in app purchase for full features but I'm worried that less serious users could/would leave negative feedback. I suppose that's always a risk but curious about any experience with this.
It also seems that it could be a whole lot more complicated keeping track of what portions of the app are locked and unlocked with in app purchase. I know I'd have to have all the code for the full functionality and "lock" the portions that haven't been purchased. How do people usually lock portions of their code? I'm not talking about the process of purchasing (I've read the In App Purchase Programming Guide) but after the purchase has been made. Would I just keep track of what the user has purchased and put conditionals on the sections that are initially locked? Or is there another way to do this as well?
My instinct is for the in app purchase (particularly since users could purchase the major sections that they want individually).
I would highly recommend using the in-app purchasing over having different versions available.
If you have different versions, users need to re-download the whole thing if they want to upgrade. This means they need to have twice the storage space and use up twice the network bandwidth to upgrade.
I don't think your review concerns are founded. If your application is well made and users like it, you'll get positive reviews. To avoid having users be confused, make sure the application clearly states what can be purchased. Also, some people just dislike everything and will give you one star. These users are unavoidable, but if your app is good, there should be enough good reviews to balance them out.
You're correct in your assumption that you would have to have conditionals for locked/unlocked content. However, this shouldn't be an enormous issue. Just persist what the user's purchased in a plist (suggested by Apple) or other persistent storage and make a class that you can query to find out if a particular feature has been purchased.
I suppose it makes sense to have lite app (with unlockable content via IAP) and full paid app. I'm saying this basing on own experience of selling apps on the AppStore. If interested you may want to look at my post in our company blog about IAP vs paid app.
http://bees4honey.com/blog/marketing/in-app-purchase-vs-paid-app/
In two words - having lite version with IAP and paid version will increase a total revenue in comparison with having only lite with IAP or lite+paid.
Related
I have an app I am working on that I want to be free but with ads. I want to also have a premium version that does not have ads but costs a small amount to purchase ($1.99). I want to know if other developers, especially those that have distributed such an app, if it is a better practice to create 2 apps or if it is better to make one app with an upgrade option built-in. I like the idea of having a separate listing for the paid app but I can see where that could be a lot of extra work to maintain a separate app for such a small feature difference.
first of all,
if you are going to develop apps for appstore, you can't create 2 apps have the same basic features but one has pro features
that's according to app-store review guidelines 4.3 spam
says....
4.3 Spam
Don’t create multiple Bundle IDs of the same app. If your app has
different versions for specific locations, sports teams, universities,
etc., consider submitting a single app and provide the variations
using in-app purchase. Also avoid piling on to a category that is
already saturated; the App Store has enough fart, burp, flashlight,
fortune telling, dating, and Kama Sutra apps, etc. already. We will
reject these apps unless they provide a unique, high-quality
experience. Spamming the store may lead to your removal from the
Developer Program.
Blockquote
if not.
then second.
both will work fine,
there are games like limbo have free and paid versions on google play
that's your decision anyway,
if there is a lot of difference between free and paid,
if it's just about unlocking some features and remove ads,
it's a simple answer. if both of options will give the same functionality,
choose the easiest way
and "separate listing for the paid app" not a good idea, why?
#KiloKw2 mention to that
It depends on your personal preference. If you would want to create 2 apps then you need to also have two unity projects at once and if you would integrate the premium stuff as paid expansion then you would need add a code into the game which enables them if the used bought them. I would personally go with having just one game with a built in paid expansion as I find easier that way. Having two of the same apps at once just complicates everything for no reason
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I'm going to develop an iPhone app, and want to make sure what I want to do is possible, and will be approved by Apple.
I'm going to create an app that will be fully branded on per submission basis. I want to have one app per customer (our customers are companies) with their logo, skin, etc.
This apps will be downloaded and installed by the employees of each one of our customers.
In other words, we would use the same base code (logic doesn't change), but will brand it for each customer. Something similar to what Magento (http://www.magentocommerce.com/product/mobile) does, they created an Ecommerce mobile app, and they brand it to their customer, but the app logic remains the same.
Would Apple consider this as duplicate apps? what is the best way to do it?
Thanks in advance.
I would have said "no problem" until I read:
This apps will be downloaded and
installed by the employees of each one
of our customers
It sounds like what your creating is (a set of) private applications, which are intended to be targeted only to specific users - i.e. employees of the company.
Apple has a separate "enterprise" development program geared towards this - allowing developers to deploy programs for their own company - and do it outside of the App Store.
If your program is very specific towards the companies, Apple may make you do this - rather than putting the Apps up for general consumption on the App store.
See here for more details:
http://developer.apple.com/programs/ios/enterprise/
Also:
If your application is really intended for a wider audience, and your could in-fact sell/distribute it a such - you could "skin" the app dynamically. For example, on first-time launch, when you "register" with some "service" - based upon your email address it could download the appropriate skinning graphics.
I can say I know of several companies built on this strategy. The code doesn't change one iota from app to app, only images and names change and they continue to bring in revenue.
EDIT: Note this is against apple policy and if they find out they have been known to ban accounts. They consider it spamming and prefer that you sell one app that provides in app purchases. Directly from their feedback on a particular group of app submissions:
Thank you for submitting your
Photography apps to the App Store.
We've completed the review of your
apps, however, we are unable to post
them to the App Store because they
provide the same feature set and
simply vary the content. Apps that
replicate functionality with different
content create clutter in the App
Store, hindering users' ability to
find apps, and do not comply with the
App Store Review Guidelines
https://developer.apple.com/appstore/resources/approval/guidelines.html:
2.20 Developers 'spamming' the App Store with many versions of
similar apps will be removed from the
iOS Developer Program
You can now use Apple's Volume Purchase Program to release differently branded versions of the same app to different customers. The app can be free or paid. Each customer must have a DUNS number (Dun & Bradstreet). See the FAQ for details.
Apple doesn't offer promotional codes for in-app purchases. What's the best way to let users try the features or content unlocked by in-app purchases for free, while complying with Apple's Developer Guidelines?
The idea is to allow a special set of users (reviewers, key fans, etc.) to access the content or features offered as in-app purchases without paying.
Examples of apps that worked around this limitation would be much appreciated.
You could submit a version of your application that has all features unlocked by default.
Submitted apps have a publish date that you can set when you submit (and I believe you can change this on the fly as well) you could simply prevent the app from being published in the App store but still be able to give promotional codes for it.
Promo codes apply to a specific app version, so when users redeem promo codes for a version of an app that hasn’t been released yet, they download the prerelease version.
Source
Something like shareware? An app, that has a subset of features enabled until in-app purchase? Apple allows it now.
As example. We've a puzzle game, that has 12 difficulty levels. 4 or 5 of them are available for free and others are unlocked after in-app purchase.
I'm working on this now.
What I'm doing is I generate a random code/guid and store that on my webService's DB. Then give that code to who ever you want. They enter that code and it calls the web service passing the code, and device UDID. The webService returns another code indicating if that promocode was valid. If valid then the app will add that purchase to NSUserDefaults or Core Data (however you keep track of purchases).
If you don't have a server up and running (say the content is already in the app bundle) and you don't want a server would require you making an algorithm to generate keys that your app validates. However this is far less robust. Using a web service allows you to prevent 1 working key from being distributed between all users, as you can tie 1 promo code to 1 device.
I have created an application and I have purchased an account in AppStore.
I wish to configure the app such that it will run for free twice and after that the user will have to purchase the full version. I want to implement the purchase of the full version inside the trial version (using in-app purchases).
Apple does not allow trial software in the App Store. You can have 'lite' versions of your applications, but Apple requires that they are fully functional applications that do not expire and are not simply advertisements for your for-pay app.
Once you figure out what type of features you want to offer in a 'lite' version, one thing you could do to offer an in-place upgrade for customers in to use the in-app purchase mechanism. Apple now allows free applications to sell in-app purchases. So you could have an app call 'Foo' and inside 'Foo' you could have a menu option to unlock additional features, which would bring them to the in-app purchases dialogs where they could pay you to unlock more content of the app.
Check out Apple's tips & tricks for App Store submission: http://developer.apple.com/iphone/news/appstoretips/
There (listed on Sept. 18th, 2009) you will find a tip titled Just Right "Lite" that reads:
Using a "Lite" version to show how it
feels to use what you make and what
kinds of things your app can do is
definitely a good way to find
customers who will pay for the full
version of your application. But store
shoppers tell us it only works if you
follow a few simple rules:
Make sure the functionality you decide to include is complete. Battles
that require weapons only available in
the full version, for instance, are
annoying and irritating instead of
enticing.
Don't set time limits on your "Lite" version, either for run times
or life times. Applications that will
only run for a set number of minutes
per session, or that expire altogether
after some period of time, don't
recruit customers so much as leave a
bad taste in their mouths.
Only display the UI for what your "Lite" version will do. Grayed out
menu commands, "more track/car
choices" you can see but not select,
etc. makes your "Lite" version feel
more like a commercial than a product,
and an annoying and ineffective one at
that.
Do include information about your full application, including an option
to buy, in either your application's
About section or on the splash screen.
Just make sure the option to continue
using the "Lite" version is there as
well. A good impression lasts forever.
It's important to follow these simple
rules not only to create a better user
experience, but also because your app
will be returned to you by the App
Review Team for modification if it is
found to have time limits, incomplete
functionality, or disabled
functionality.
The most relevent part of that text for yourself and your proposed App design is the last sentence that contains "... your app will be returned to you by the App Review Team for modification if it is found to have time limits..."
Here's a good walkthrough on adding in-app features to your app.
http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/