I have an app in the Apple App Store and want to understand where the difference between "Installations" and "Downloads" is. In my mind it is only a different word for the same thing but there is a gap in the numbers.
I would be very happy about an answer!
Installations are the total number of times your app has been installed. Includes redownloads and restores on the same or different device, downloads to multiple devices sharing the same Apple ID, and Family Sharing installations.
Downloads are the number of first-time downloads and redownloads on devices with iOS, tvOS, or macOS. Installations only includes data from users who have agreed to share their diagnostics and usage information with app developers.
You can see the rate of Opt-in users by clicking Opt-In Rate History (see the image above)
Related
Got a general question(s) for you on implementing a free and paid version of an app.
I have it setup now where I have 2 targets within the 1 app/project and I specify with the def syntax for what is in the lite vs paid version.
It works and runs both targets.
1) How do I have the user purchase the paid app directly from the free version? (Found multiple older articles saying linking is fine and others saying that will get rejected and must use in-app purchase)
Can I use a link tied to a tab bar item or button like this,
NSString *iTunesLink = #"http://itunes.apple.com/gb/app/wired-news-uk/id435728870?mt=8";
[[UIApplication sharedApplication]
openURL:[NSURL URLWithString:iTunesLink]];
OR do I need to implement the storekit for an In-App purchase?
2) I was going to put a new Tab Bar item at the bottom (to link to paid version) - haven't tried yet but I should be able to setup the tab bar one way for the free version and another way for the paid version, correct? Essentially, hiding the tab bar item to purchase the paid version once upgraded.
3) Submitting each app (free and paid) version to the app store - I'm assuming I will be able to set the target and archive the binary for upload for each, right? Two separate app submissions in itunesconnect?
I have several Lite/Paid app pairs in the app store (all were originally created before IAP existed). I've made many updates to these apps over the years so it seems Apple is fine with the idea in general, if you do it right.
1) You can't actually purchase the paid app from inside the free app. The best you can do is send the user to the store for your paid app.
2) That should work. In one of my apps, I have an extra icon in the main toolbar that brings the user to the app store page for the paid app.
3) Yes, you submit two completely separate apps. You setup two apps in iTunes Connect each with their own unique app id.
A single project with two targets is the easy and proper way to setup your code. For me, I do two archive builds, setup two apps or app updates in iTunes Connect, and submit the two apps/updates to iTunes Connect. I always keep both apps in perfect sync. Apple always seems to review them together and always pushes them out to the store at roughly the same time. Only once did the two get approved more than an hour or two apart.
The main thing you must be careful with is the free version. It can be "Free" or "Lite" but not "Demo". The free version must fully function. DO NOT have any UI elements in the free version that are disabled because they only work in the paid version. It will get rejected. If it doesn't work in the free version, make no mention of it at all in the free version.
Most of my app pairs, the free version allows for limited data compared to the paid version. When the user attempts to add data beyond this point, I popup an alert with a nice reminder that the free version a limit and offer them the chance to upgrade. Other than this, there is no other annoying popups offering the paid version. It's OK to have a button or whatever in the free app to let the user upgrade, just don't shove it their face or popup any sort of reminder after X uses or time. A free version of an app must fully function in its own right.
Here's my take on free/paid app pairs versus IAP:
Cons of IAP:
- No promo codes for IAP
- You can't make IAP free for some period of time (sale or whatever)
- Free apps tend to get lower ratings because any yahoo can download.
- Extra coding for IAP
Cons of free/paid pair:
- Two targets, two app releases, two sets of images, two sets of stuff in iTunes Connect
- Split downloads and ratings/reviews.
Personally, since I've been doing this for several years now, the extra effort of submitting two apps is trivial.
Edit:
One thing I forgot to mention - there is still no guarantee that Apple will accept the apps this way. But there are plenty of examples of such apps so it should be OK if done correctly.
If you want to have two apps, then you must have two technically independent submissions with different app id-s. It may be tricky to have it from the same project, not sure if you can do it using two targets. Technically AppStore rules do not allow "upselling" paid version from free one, but if it is not too aggressive, then maybe it will be approved. Safe solution would be to use InApp Purchase, this gives you many benefits:
quite is easy to implement
no need for two application codebases
you have single download count and item in appstore
Actually this solution with two separate apps made sense before in-app purchases, I do not see much point of that today.
Re: Apps in the Apple Store (iPhone &iPad) --
I've never seen a source that lists how many times a certain App has been downloaded / paid for. Is there one?
I'm deciding what to do for my next App and would like to check around and see how some individual Apps are selling that are in my area. To see if there's a market for whatever I'm going to do.
I believe Apple used to list how many times an individual App had been downloaded. But it's not there now.
Thank you.
Log onto your developer account and go to iTunes connect. Information about all of you apps is there with download reports, crash logs, etc.
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.
I'm considering including some large movies in my app, but I don't want users to have to re-download the movies each time they get an update. When a user downloads an update from the app store, do they end up re-downloading the entire bundle? Or only parts of the app that have changed relative to their version (i.e. do updates only ship some sort of binary patch)?
The whole app. iTunes actually stores multiple versions of all your apps, and they are submitted to Apple as zipped app bundles.
The whole bundle, as submitted to, tested, approved and codesigned by Apple.
iTunes will delete any previous versions of your app.
If you have very large content that you don't want installed on every update, you might want to consider allowing users to download it from a website for offline use, and have the app store it in the app's sandboxed Documents directory, which should survive app updates (baring weird update bugs).
My experience is that large apps take a while to update. There are many ways Apple could theoretically implement a diff (and it's probably advantageous for them to offer a diff between the two latest versions, since it reduces their bandwidth bill), but as far as I know, they don't.
"Large" apps (>20 MB, currently) can only be downloaded over Wi-Fi. If you make your app big enough, that means users won't download the update until they get connected over Wi-Fi. Also consider that existing users have already paid you — I don't advocate screwing over your users (if only because they'll leave bad reviews), but taking a while to update apps isn't a big deal; that can happen as I sleep.
I'd worry about new users/initial installs:
New users won't be able to download your app unless they're connected over Wi-Fi. I'm not sure what the difference in sales figures is — I can't see it in our graphs (so under 10%?), but it probably depends on the type of app.
A lengthy initial install leaves a bad impression: They've never used your app before. They just found it on the App Store, decided it was worth buying/installing.... and now they have to wait.
If you don't mind running your own servers, then it's definitely worth considering.
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.