Let say I'm a company and I have 2 subcontractors developing 2 different iOs apps. I want to know how much each app is earning to pay them accordingly.
How can I know how much each iOs app is earning per month ?
From the iTunes Connect's "Payments and Financial reports" page I can get the payment per country per month but I didn't find the payment per app that I need.
You are able to get app sales by SKU and a lot more, but you must generate a report first.
In payments and financial records module there is a button in the top right named Create Reports. Click this button and select the regions you want to include. It defaults to all regions. Once the report is generated you can download it and view the data it contains. Each region is archived and once unarchived it is in CSV format. You can view it in a text editor which is rather ugly, or a spreadsheet or enter it into your own database with a custom dashboard for whatever serves your purpose.
For additional info go to the Resources and Help module in iTunes connect. In the news feed there is an entry Feb 25 2016 titled Introducing the new Payments and Financial Records. This has additional info that may be useful.
I could get how much each iOs app is earning per month using my own project and the CSV report files from Apple.
Java version : https://github.com/est-seb/revenuePerAppJava
Javascript (Node + electron) version : https://github.com/est-seb/RevenuePerApp
Related
As opposed to Google Play Console, I can't find a way to check the amount of app sales being made in real time. I am not a patient person so I'd like to be able to check this information multiple times throughout the day.
At the moment, I track my website's performance with Google Analytics so I can see how many people visit the app's manual compared to the amount of people who did the same thing 7 days ago. However, this value can vary up to 40% while having the same amount of app sales so it's not a very good indicator.
The app is dependent on a very small footprint so including a framework that tracks usage statistics would be overkill. I only need a way to get notified how many people have opened this app today. Have you implemented this somewhere in your own projects? Or is there even a section for that in iTunesConnect?
You could log an event with Google Analytics called "App Opened" or something where the label is the identifierForVendor. Another option is to create an UUID and store it in UserDefaults, and use that as the label.
By checking the number of events with a unique label you could see the amount of installs.
This wouldn't require you to add a new framework or to implement anything else.
In itunesconnect, to check app download figure,
App Analytics and Sales & Trends showing two different figure.
e.g.
For same certain period,
App Analytics: App Unit = 1729
Sales & Trends: Unit = 1.81K
Which is correct?
I saw some other post (e.g.this) discussing similar issue. But the discussion later didn't come up an answer.
Thanks.
Check the official definitions (from itunesconnect.apple.com) and you will see that all the numbers can be different:
Sales & Trends:
Data Guidelines: Data includes all device types. Sales data is the
estimated total billed to customers. Proceeds is the estimated amount you’ll receive.
Date and Time: Data is shown in UTC or PST. A day includes transactions that happened from 12:00 AM to 11:59 PM for the selected
time zone.
App Analytics:
Data Guidelines: Data includes devices with iOS 8 or tvOS 9, or later.
Date and Time: Days start at 12:00 AM and end at 11:59 PM (UTC).
Opt-In: We only show data from users who have agreed to share their diagnostics and usage information with app developers. In the last 30 days, xx% of all users that installed apps agreed to share their data.
Diagnostics and usage information may be delayed by up to 72 hours.
Summary
Reporting times are the same if you select the right one (!). App Analytics does not include all sales. If your app is available on older devices, it's not included here. Big question here is: What do you want to achieve? Difference between both numbers in your sample is <5%. For whatever calculations you are doing, just use the same source and don't mix & match.
It's possible that the 3 different reports (including Financial) use different sets of starting and ending timezones, different starting and ending times and dates, and different reporting systems (audited vs. unaudited vs. estimated). Apple says the monthly Financial reports are the most correct.
Right now in application on itunesconnect I have a lot of data in Sales And Trends section (about downloads and payments).
But I need to transfer my application to another itunesconnect account (I need to change the company for the application. So in the details of the application I choose More->Transfer).
Will I have all that data in the other itunesconnect account after transferring the application or will I loose all that data about downloading and payments and so on?
No.
Because you won’t be able to view the app information after the
transfer, make a catalog report (see Requesting Catalog Reports), note
dates the app was available on the store (see Viewing Status History),
and save sales and download information (see Viewing Sales and
Trends).
Apple Documentation Source
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.
I'm developing an app where the user can purchase digital maps, charts and so on. I'd like to wrap these in in-app-purchases. The thing is that I don't know beforehand how many charts there will be, as I'm getting them from another source from the net. There could be hundreds.
I have a server that periodically gets the charts from that source and stores them locally; there may appear new charts in the future or disappear existing ones. All this without manual intervention.
There are three distinct types of charts.
My first solution was to create three consumable items and let the user buy these; this was working fine but unfortunately Apple rejected it, since they require charts to be "non consumable".
But I'm quite at a loss how to implement what I want with the non-consumable type. If I create these three types as non-consumable, and the user buys one, he will get all the other charts in that group for free, since a non-consumable item can only be bought once.
The only solution I can think of is to create a non-consumable item for every single chart. But that's something I want to avoid at all costs: as it is now, the charts are periodically fetched from the remote source without any manual work on my side. I'd like to keep it that way. I don't want to manually create a new non consumable purchases every time a new chart appears.
Any ideas how to make this scalable?
I can't completely spell it out for you with code but you can handle this problem two ways:
Currency.
You do not sell non-consumable items such as maps. You sell currency. With that currency you purchase maps. The maps you feed dynamically whenever the user hits your store front. That way you only need to track a few purchase options.
The other option:
The company I worked for initially set this up very simply. Our app would launch and we would reach out for a php script that handed us back the app store IDs that we had sitting in it. At that point we'd verify them and use the valid returns. This option allowed us to change our in app purchases through iTunes Connect and then in the script and everything was great.
This is an older post, but I just had the same question and found out there is now a way to dynamically provide non-consumables by hosting the product identifier list on your own server:
Every product you sell in your app has a unique product identifier.
Your app uses these product identifiers to fetch information about
products from the App Store, such as pricing, and to submit payment
requests when users purchase those products. Your app can either read
its list of product identifiers from a file in its app bundle or fetch
them from your server.
If your app has a fixed list of products, such as an in-app purchase
to remove ads or enable functionality, embed the list in the app
bundle. If the list of product identifiers can change without your app
needing to be updated, such as a game that supports additional levels
or characters, have your app fetch the list from your server.
There’s no runtime mechanism to fetch a list of all products
configured in iTunes Connect for a particular app. You’re responsible
for managing your app’s list of products and providing that
information to your app. If you need to manage a large number of
products, consider using the bulk XML upload/download feature in
iTunes Connect.
Apple Developer In-App Purchasing Guide
I think your limit on items is something massive like 10,000 or so.
Pre-create a big number of items, add some code to check your website to see what your highest chart number is and make sure the users can only buy charts that you have.
The app downloads the chart names and corresponding product id from your server and then you're just buying a product.
Apple doesn't care if the actual product is already in the app and unlocked by the purchase, downloaded from their server or provided from your website.
Whether you have these purchased directly via IAP or through some kind of in-app "currency" you could simplify the amount of work you'd need to do in the future by using a naming system which would guarantee a unique map name for each item you want to sell. For example:
NSString *myMapName = [NSString stringWithFormat:#"%#%#%#%#", app_identifier, map_type, top_left_corner_location, scale];
This way if your server passes that information for a new map, there's a programmatic way to know what the IAP identifier should be— just make it the value of the string myMapName.
In the case where you use currency (which sounds easier than the alternative option, and is what lots of big apps out there seem to be doing) you just need to make a hash with some data in your map so that people can't guess the code you're storing in their keychain/plist and magically get all your maps without paying :)
In the case where you actually have individual IAPs for each map, sadly you do have to make an IAP for every possible map once. (But you can hire some kid to do that part for minimum wage, right? It's just data entry) They can be basic shells, though, with the actual info provided via your server as described above, once it's verified that the map has actually been purchased.
Hope this helps!