I saw there are apps that have a different price on different iTunes stores (according to location). How do they do that? I didn't see any place in iTunes Connect that enables that.
You can't have different price for different country.
The only thing is when you choose a tier, it is not the same value according to the country currency.
e.g. : tier 1 = $.99 (US) = .79€ (Europe) = 230 Yens (Japan)
If you really want to have different prices, you must have the same app multiple times.
e.g. :
Application 1 : only distributed on US country (at any tier)
Application 1 bis : distributed on other country than US (at any other tier)
Application 1 and Application 1 bis is exactly the same application, but with a little difference, e.g. language (if you do not localize your app)
It is possible now! Now you can set different prices based on territories for the same IAP package.
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/WorkingWithYourProductsStatus.html
Meanwhile, there is an SDK (Mage) available, which is also working for consumables and non-consumables (unlike with iTunes Connect where it only works with subscriptions). Additionally, they automatically take care of optimizing prices according to the markets. You can find the documentation in the repository (there is an android as well as react-native SDK available too).
If you are using the option in iTunes Connect to change subscription prices according to locations be aware, that:
If you reduce your prices: all existing customers will also profit from that immediately.
If you increase your prices: all existing customers will be warned and get the opportunity to cancel.
For full disclosure, I'm one of the Co-Founders. We faced the same problems like you multiple times. This is why we created Mage.
Release them as separate apps, then set the target countries so they do not overlap.
Related
Let's say I have the following app (just a stupid example) https://tenant-eight.vercel.app
In words: A customer can see a business name and the address. He can leave a like, that is stored in a MySQL database. The app will send a email in the background to the business owner.
I want to sell that app to clients (b2b), so that they can collect votes on their own.
Let's say I have 100 clients. I would store the company configuration (database api url, company name, address...) in an .env file. Then I would build 100 apps. I need 100 domains, 100 web spaces, 100 databases and so on.... How can I make my life easier?
What is the best approach to realise that with less scaling issues, update maintenance, and so on? (each customer will always have the same latest code - no customer specific features).
Well, a method is just selling your apps source code and relax. Don't want it to get stolen? Two ways (both are sh#tty in an aspect but.. welcome to selling closed source things :p)
Obfuscate the code, which will make it much slower, but not a single soul will understand it unless they are a real tech-savvy person. Clients may also feel less secure.
Make a licensing system with a private npm project, and give out license codes to activate the website (no source code will be given)
I've been using Apple's search API and RSS feeds to look at top-grossing apps. As far as I can tell, Apple limits the results to 300 when looking at the top-grossing apps, but somehow appannie.com has apps listed in top grossing to 1500.
Anyone know how they get their numbers?
Oliver Lo, the VP of Marketing at App Annie, gave a few hints during an interview with pocketgamer.biz (quoted below).
The firm offers a sales analytics tool for developers that both
gathers their sales numbers and processes them. Indeed, App Annie's
analytics tool is used by over 150,000 apps and, in particular, over
40 percent of the top 100 publishers by revenue.
Once a developer connects their App Annie account with their iTunes
Connect account, the sales data is automatically downloaded and
processed.
While App Annie keeps the data from that tool completely anonymous, it
does combine all the download and revenue data it has access to
together to build a global model of sales.
That data is then correlated with the public ranking data in the top
app lists to place sales figures with ranks.
Filling in the blanks
"Imagine a Y axis that represents downloads and X axis that represents
rankings," adds Lo.
"Essentially we create a model of those two data points, correlating
them and growing a distribution of those points through advanced
statistics.
"Through that statistical correlation we are able to generate market
estimates for the downloads and the revenue of the entire App Store
ecosystem."
Source: http://www.pocketgamer.biz/feature/47064/stateside-getting-to-grips-with-app-annies-app-store-stats/
I have an app on the App Store with a Primary and Secondary category set. The app is featured in some of these categories, and this is something I would very much like to keep.
Are there any side-effects to the app's featured status, app rankings or anything else simply by switching which category is primary, and which is secondary (but otherwise, keeping the same 2 categories)?
I can only speak from my experience (!) with more than 12 apps on the iOS App Store for more than 2 years. Most of our apps are in the Productivity (1st) and Business Category (2nd).
We did some tests on ranking and changed the categories (2nd=>1st etc.). The changes (mainly number of downloads) were significant - positive and negative. Obviously there are also different price points that people are willing to pay in different categories.
With regards to featured status we observed that you often get kicked out of the former first category's featured section (New and Noteworthy etc.).
What I can tell you is that sometimes it is worth testing some changes: For us it was worth testing the different categories and when we changed all the stuff back to the "original" setup, the numbers of downloads etc. were the same.
I am developing an app that has an sqlite file embedded inside.
That sqlite file is being copied to the /documents folder of the app, and contains the data of a specific version of a book (it's an advanced search app for a specific book).
I've also implemented an subscription service (via inapp payments) for that app, for updating the content. for Registered users only. Basically the app update will occur once a large number of update entries is fulfilled or a bug fix, so that the newer user would have to download a lesser number of updates.
The problem is that the old users have paid for a specific book. New users could pay for the extra book, at the same price (consider it an updated version). Is there any way to "forbid" the old users from having access to that book resources since they have not paid a subscription or the app at a latter time?
There are different types of inapp purchases: non-replenishable, replenishable, subscriptions, and auto-renewing subscriptions.
The user will always get what's embedded, though, if you don't track user status yourself (which probably is not worth it) - and then you have to deal with the problem of giving him that exact version.
The main question remains though: Do you really want to penalize your early buyers? Their money came to you first (so it is more worth than the current buy), and now they are left behind with less.
If there is really new content frequently, you might want to go the subscription route. Personally, losing my purchased data like a book just because you bring an update would leave you with one frustrated customer less.
A different route is to limit the support for that app to a specific date and then get your users to buy a new (different) App, maybe with making the first app cheaper during its final stages, and then removing it altogether.
You should aim to make your users buy as soon as possible. But with your business model, it is actually better to buy as late as possible, and often late equals never in practice.
This question is for those familiar with implementing the iphone in-app store functionality.
The app I'm building has only built-in features that are unlocked when features are purchased. Further, any modifications or additions to store items will require an app update. Also, it is only in English so has no localized languages for the items.
If we take those assumptions, is it feasible to skip the step of retrieving the product info with SKProductsRequest and simply use hardcoded data within the app? While I may want to extend my app to greater complexity in the future, I'd like to know if this step to keep it simple would introduce some serious issues.
One issue might be, for instance, if we have to expect a few of the items to occasionally be unavailable due to issues on Apple's side and simply trying to purchase it and letting it fail would not be a permissible or workable option in that case (especially if it is uncommon).
Thanks.
I suspect that Apple would object if you used hard-coded prices in your app, although I can't say for certain that they'd reject you.
Bear in mind, however, that localization isn't just about languages. It also gives you localized prices. Currency values fluctuate, so we can reasonably expect the localized prices associated with a given tier to change from time to time. The possibility of getting money from users in Canada, UK, and other territories beyond the USA seems like ample justification for using SKProductsRequest, whether it's technically and contractually required or not.