Hi guys I need some help with Apple App Store.
I've an application that is localized in several languages and I want to release a different bundle for each language (to reduce the app size).
Can I use the same app name?
Thx,
SL3
You can't use the same app name or have multiple binaries for the same app version. And as Radek said, it would be a bad idea anyway.
Localizing an app in various languages should not require that much more size to make you think about splitting it in different bundles.
By the way, it's a bad idea thinking of publishing different applications for different localizations, for a couple of reasons:
You will have to handle n different development/release/review streams, with great problems when you need to update the app (Apple will have to review n versions instead of one)
A user will not be able to switch languages if he likes to. Think about a Spanish person that lives in Italy. Which version should he download?
If you use dedicate developer profiles under Xcode, you should create and import a different one (or a different group of them) for each localized version.
Also, you will split all the number of downloads, reviews and so on between the apps. If your app is downloaded by 10.000 people its great! But if you split it in 10 pieces, you will have only 1.000 downloads each (mean value). This will greatly affect the scoring in the App Store ... and that's not what you want!
If you built the app in a clean way, adding a localization should result in adding a simple text file, and that is not so heavy.
Related
I have an app that has been released on the app store with separate versions for iPhone and iPad. Now I wish to convert the app to a Universal version but I have an issue which I'm not sure can be resolved.
Both versions of the app use a different bundle identifier (for example com.mycompany.app.iphone and com.mycompany.app.ipad). I want the new (universal) version to overwrite either of the old versions when downloaded from the app store. To complicate matters further, core data stored for that app needs to be retained.
I'm not sure its possible and perhaps the protocol is to release the universal version under a new bundle identifier and have users start again but if a workaround is available it would be really helpful.
your options:
1: Update both your iPhone and iPad apps with this universal binary (with respective bundleIDs and app names)
2: Create a way to sync data between apps by creating a web service. one of the apps I have used extensively - Gas Cubby, does this for transferring data from its free app to paid app. You could implement it in a similar way
3: Nuke one of the apps, update the other app with the universal binary
Option 1 is the easiest. 2 will take longer. 3 is dirty.
(will update this answer with more options if I come across any)
As far as I know and from what I've read before, you can't change the bundle identifier of an app published in the app store.
Due to the sandboxing, accessing the data of your old app from the new app is also impossible.
There are several ways you could go about solving this issue, depending on which one suits you best. You could create a new universal app, and abandon the old ones hoping that the users change their preferences, or you could be pushing the same update to both applications, essentially, having the identical app under two different names. I'm not sure what are Apple's stances on the second option, but it will be a hassle either way. Good luck!
I currently have an Universal iOS app, but with the new iPad3 device we needed to add resources/sprites for that specific device, the problem is that the size of the IPA has become incredible larger thanks to the huge new screen. I was wondering if its possible to have only one Xcode 4 Project that could generate two different IPAs, one with target:iphone and other with target:ipad, that could also include or exclude files depending on the file extension, for example blah-ipad.png wont be on the iphone version.
Thanks!
#Conrad Shultz is correct about why you shouldn't split an existing paid app into two.
For people who haven't released their app, or whose app is free, it's worth knowing that you can duplicate a Target by right-clicking (or control-clicking) on it and selecting Duplicate. I'm pretty sure Duplication is only offered through this context menu. The more obvious 'Add Target' options involve creating a whole new Target and manually duplicating the contents and settings of your existing Target.
Once you have multiple targets, you can specify which resources are distributed with each.
Edit: you will also need to change the 'Devices' setting if you have an iPhone Target and an iPad Target.
If you have a lot of resources, consider including them in folders with Folder References. Then you can specify target membership for the entire folder, without having to change individual files. This will change the path to those resources within your bundle, so plan accordingly.
Yes and no.
You can certainly set up different build targets (and schemes) for different products, targeting different device families, different architectures, even entirely different platforms (OS X vs. iOS). You can of course include different assets in each. I personally do this all the time, so if that's what you're looking to do, let me know and I'll try to provide further details.
But what you can't do is submit multiple IPAs for a single product to the App Store. If you are already distributing a Universal app through the App Store, your only recourse would be to pull it and create two new apps with new bundle identifiers, product names, etc. (I don't think, but I could be wrong on this point, that you can even downgrade a Universal app to a single-family app, but that's something you'd have to check in the developer/App Store documentation and agreements.)
If you went this route, you would force existing users to purchase the new app again at full price. This would likely be poorly received by customers. If I were you, I'd look at whether the size difference is really large enough to worry about and, if so, look at strategies for reusing assets across devices (for example, downscaling higher resolution images on #1x devices), though this introduces possible performance penalties.
I have an app on the Swedish App Store which I intend to adapt to some other markets. In this case, the most important part of the localization is to change some aspects of how the app works for different markets (countries), so this is not primarily about language adaptations.
Probably, I will not use the normal built-in mechanisms for localization. Instead I consider to build separate versions for different markets and release them as separate apps on App Store (with the same icon and similar names), with each one of them only available in one country.
My main arguments are,:
1) Since App Store supports fewer languages than iOS, there are several countries where Apple has defined the App Store language to be UK English (e.g. Denmark, Norway). Then I cannot create a good sales pitch in their own language, unless I release completely separate apps for these countries.
2) I think it will be faster for me to implement the localization, in this particular case, by inserting compiler directives in the source code and make different Xcode targets for different markets. (This may be caused by a not so smart architecture of the first version of my app, by nevertheless, this is the current state.)
NOW, MY QUESTION:
Are there any drawbacks of releasing separate apps for different markets, except the obvious one that there will be more administration? (e.g. less favourable for achieving good ranking on App Store, risk of rejection, etc...)
It is not possible to publish 2 apps with same name in the app store
Risk of Ban
App Store supports fewer languages than iOS Localization
iOS Localization is faster than creating multiple copies
Maintaining multiple copies, changes and updating all of them is a huge overhead
Less favourable for achieving good ranking on App Store
Risk of rejection
App Store Review Guidelines, one of them is that
developers should not "spam" the app store with multiple versions of
the same app with minor changes.
Apple are not a big fan of this approach generally. I heard somewhere that there was an unofficial limit of three copies of the same app for localisation reasons, but I don't know how concrete that is.
Would it not be possible to build this logic into the app? You can use the NSLocale to get the device locale (not just language, also country) at runtime, and then use runtime logic to switch out view controllers, nib files etc. If your app is not well structured, you could just branch at the MainWindow.nib level if necessary, and then have complete control to change any aspect of the app when it loads.
I think this is a better approach than releasing multiple app versions for the reasons you mention, as well as avoiding hassles getting your app approved. It doesn't solve the app store notes problem, but perhaps you can work around that another way, by focussing your marketing strategy on a web site or something external to the app store.
There has been a lot of talk around iPad-Apps / Approval / Store-related Questions. I've recently built an App which I'm just about to release / send to Apple for approval.
I'm thinking about developing a dedicated iPad-App as well.
Now, in order to not have two seperate Apps in the Store (one for the iPhone, one for the iPad) i want to create an universal-App for both platforms.
However, i couldn't figure out if it is possible to first send in my iPhone-only app and later publish an update that enables my app to run on both platforms.
Does anyone have an idea on that topic?
thanks in advance
sam
Yes, you can update an iPhone app to become a universal app.
Many apps are already doing that. Universal apps provide the better user experience, I think, as they reduce the number of "duplicates" in your iTunes library (and on your iPad).
Unfortunately, a great many developers are going the "two separate apps and make the iPad one really expensive" route instead, too.
The only downside to universal apps I can see is the increased size (all the iPad-only stuff that iPhone users do not need), which could be a factor for the more fancy applications. Does anyone know if iTunes is clever enough to strip this out when syncing?
Those of us with iPhone apps (released or unreleased) are able to send out limited beta builds using ad-hoc distribution. While the Apple docs for this have a few holes in them, there are a number of blogs, postings and other articles out there on "the net" that fill the gaps.
However, one thing I haven't seen anyone mention, and I was curious about: When you do a beta build do you use the same app id as your released (or to-be-released) app?
The argument for using a different id is that the beta could then still run alongside the released app. This is probably more important if you already have a released version in the field.
An argument against is that the beta would not have access to any data the released app may have generated, and vice -versa. This may or may not be what you want on a case-by-case basis.
Are there any issues with this approach? I only have one app id registered currently, but IIRC there are no obstacles to just creating more as necessary..?
Would be interested to hear what others are doing.
We use the same app ID, just for simplicity. There are enough headaches in ad-hoc distribution that we don't want to confuse anybody with "why are there two apps on my phone?" problems.
I use both different Bundle Identifiers to allow my testing team to have multiple versions of the app installed as well as different Bundle Display NAmes, so they can easily see that they are using a development or beta build and report that number back to me when issues are found.
I think it depends on how important the data in your app is. If the data is valuable I don't think beta testers would want it putting at risk, hence having a separate AppID would make sense. Of course, that also means that they won't test the application as fully either and any "upgrade" code won't get tested.
In my case (Yummy), the data is just a cache of delicious.com so a catastrophic bug in my code would mean, at worse, downloading all your bookmarks again. So I tend to use the same AppID for everything.