I'm going to release an app in the UK and US App Stores. I would like to have two different data sources according to the store my application is downloaded from. Basically I would like my app to connect to my US servers when downloaded from the US store and to the UK servers when downloaded from the british one.
I was thinking of including the origin URL in the as localised string but I don't think this is a stable solution.
Any idea?
thanks a lot
Claus
I'm not sure, but I don't think the app has knowledge from where it was downloaded from.
You could create two apps, one for UK and one for US, and make the apps only available in their respective local App Stores.
However, depending on the amount of apps you would have to produce (if you intend to distribute your app in more than 2 countries in the future), it might be easier to just ask the user which data source to use on startup, or let him define one in the settings etc.
Or use the iPhone's current language or even location to select the data source.
Related
If I make one app that is for different countries but for example is sponsored by "Lyft" in the US and "UBER" in the UK can i make changes to the app store images in each location to show Lyft in the US and UBER in the UK so i can avoid making more than one app ?
If not what is the best workaround for this?
It's possible to upload different screenshots for different localisations.
First of all you have to add additional localisations for the languages / countries you want to target in iTunes Connect.
Then go to the new Media Manager to upload different screenshots for the different localisations. (And not "just" take the ones from your primary locale)
I need to develop an application that will behave differently depending on the user's country. Let's say, if the user is in France, some functionality would be available. But, if the user were from India, he would be able to acces a different set of functionality.
If it were only language based restrictions, I could switch functionality using NSLocale class methods. But my functionality is really dependent on the user's country because of licensing and legal reasons.
What are the best practices for dealing with this situation?
For each market where you have specific requirements due to market-specific licensing or legal issues, you can create a separate app in iTunes Connect and make it available for download only in the relevant market. And if you need to, this also allows you to provide a market-specific EULA. It's a big maintenance burden, but it would ensure that only users in a given market can access the app.
Note that in XCode you can fairly easily build, deploy and publish multiple versions of your project built from different configurations (XCode calls this "Targets"), so you could still achieve this in a single codebase by simply adding some preprocessor definitions in the relevant target definitions and putting #ifdef in your code where you want differentiated logic.
A 3rd party app has no access whatsoever to any information about the user of the device or access to the iTunes account. There is no way to know the user's true country. At any given time, the device may not even be associated with any one person. An iPod touch, for example, may have no user logged into any iTunes account. The same device can ultimately be logged into one of several different accounts.
All you have access to is the user's current GPS location (if the user allows your app to access that information) or their current locale.
Basically, there is no way to do what you need. Of course you could prompt the user but obviously there is no way to verify this information.
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase
If you deploy an application through the iTunes app store, what usage information do you get from Apple? Do you only get the number of downloads/sales, and does this differ for free vs. paid apps? Do you get any information regarding how often it is used, crash logs, demographics info, etc? Is the only way to build hooks to your own server to track this information and would such an app even get approved?
I've seen articles such as this one that includes quotes like:
only about 20 percent of users return to use a free app the day after they first download it and by 30 days out, less than five percent are using the app.
Is that based on surveys, or is it data that comes from Apple? There doesn't appear to be much publicly available data except when Apple shows the top applications, but that is just based downloads or ratings, and nothing deeper.
Most of this information comes from companies like Pinch Media and Admob. They supply libraries you can include in you app which inform their servers of events in your app (specifically launch but also other events decided by you).
They use these events to provide aggregate information on iPhone apps. Several reports have been published recently referencing this data.
You only receive usage information if you somehow program the reporting of such information into your app.
Number of Downloads (Sales if a non-free app) and more recently crash logs are the only information you receive from Apple. you do not even receive personal information about WHO is was that bought your app, only that they did.
You won't get usage statistics from Apple, only download and sales statistics. The reporting is slightly different for free apps(as they won't show up in the financial report), but basically the same information is provided.
You can however track usage information on your own by having your application ping a remote server every time the app is accessed. You can use the unique device id to track a specific user. This will be dependent on internet access for the iPhone/iPod Touch.
Apple does give you how many downloads have occurred as well as what countries they are from. If you want more detailed usage statistics you will have to go to a third party solution, or write it yourself.
Unless Apple is secretly sending usage information when an app is opened, I don't see how anyone can get aggregate statistics about the whole app store. When I upload an app, it is in binary format, and it is probably unlikely that anyone adds in their own code to secretly do this.
HI,
I am developing an application for an esteemed client in Australia. They have certain copyright issues when it comes to uses outside Australia accessing the content via the app.
Is it possible to have a local and an international version of the app, both available via iTunes Store? The international version will only have permissible content. If not, please advice the best option to deal with this issue.
Thanking you in anticipation
Cheers,
Amit
Yes, you can create two versions of the application with different SKUs. The best way to do this would by by using a wildcard certificate and using a different project identifier in the application's plist file.
Using the administrative panel on iTunes Connect you can then restrict the sale of the SKUs to different territories.
These options become available when you have paid the $99 for a development certificate, and and when you upload your application to iTunes.
As others have noted, it's possible to build two versions and to use the iTunes store to restrict distribution based on the nation where the buyer is located.
However there's another issue to consider. You say that the problem is "accessing the content via the app" outside of Australia. But you're on a platform which is inherently mobile, and may not be located in the same country it was when the user got your app. What happens if someone is in Australia, gets the app legitimately, and then travels to some other country? They're no longer in Australia but they have a copy of the app that assumes they are. Would your client's copyright restrictions still permit them to access content that's supposed to be Australia-only?
If not, your problem is rather different than using app-store restrictions. But it might also mean that you get to have a better solution to the problem that doesn't require multiple versions of the app.
Think about it: the iPhone knows where it is. A 3g phone can get GPS-accurate location info, and the older phones get reasonable approximations anytime they have a phone network connection. That gives you lat/long coordinates.
What then? Since your home area is pretty well defined, it might be simple-- draw a rectangle around Australia on a map, and define "in Australia" as being in that rectangle (being a whole continent comes in handy here). If you want something more precise, feed that lat/long into a reverse-geocoding API (there are many-- Flickr has one, for example) to find out what country you're in.
And voila, you can make the app behave one way in Australia and another way outside of it, and you only need one version of the app to do it.
You can restrict which apps are sold in which country/geographical region. Your Australian app you can restrict to Australia and sell another app worldwide.