I haven't been able to find relevant answer to this problem. Please redirect if you know it's a duplicate question.
Background:
I have this version 1.0 of an app on the App Store. It's basically a wrapper around a WebApp and the updated 2.0 version I am working on is a native implementation for iPhone.
Now the current version 1.0 of the app is Universal. So trying to submit our finished 2.0-native iPhone only app is refused by AppStore since it's considered a downgrade to no longer support iPad.
The roadmap ahead includes a future release of an iPad-version as well, and this needs to be taken into account. I believe there are good reasons for this iPad-app to be Universal. We need to keep the current AppName in some way.
Now I need advice on how to best handle the situation. These are the steps I consider:
Release v2.0 under new appName i.e. "MyApp 2"
Remove v1.0 app from sales, but keep it in iTunesConnect to save the name
Change WebAppContent of v1.0 to notify the current userbase of the native app (2.0)
When we are ready to release a Universal App we update the current 1.0 instead of 2.0 to reclaim the original name
Questions:
Is there a better way?
If we remove v1.0 from sales and release v2.0 under the name "MyApp 2", is there a way to change the later name back to "MyApp" when v1.0 is of the stores?
If we consider deleting v1.0 completely from iTunesConnect, can we, as the same company, then reclaim the name when it becomes publicly available again (or are we blacklisted for that name)?
Can you have different display names for an App on AppStore and on the devices home screen (how is this done)?
Warning: If you delete an app in iTunes Connect, that app's name is no longer available for use by that same Developer account ever again.
Bundle display names are independent of App store names. Many apps have shortened or abbreviated Bundle display names to fit under the icon, and a much longer app store name.
Related
I think this is not required, at my personal experience only new iOS specific features in my application will require a new release, but a personal client is asking me to confirm this.
With every new XCode release, do I have to rebuild and publish my application in order to make it available at the AppStore of new iOS Release?
If there is any official documentation that proves this will be appreciated!
You do not need to re-publish. Apps remain in the App Store until the developer pulls it (or very rarely, Apple pulls it due to policy violations).
There is likely not any documentation that explicitly states this, but consider a scenario where somebody gets the new iPhone 13 and opts to restore it from iCloud. Data is pulled from iCloud, but apps are restored by re-installing them from the App Store. If apps disappeared from the App Store because they haven't been re-compiled, then anybody who upgraded their phone would discover that a large number of their apps had disappeared.
Anecdotally, my company has apps in the App Store that haven't seen a new submission in over 2 years (since iOS 12). Those apps are still in the store.
You can test your iOS app using the new Xcode 13 and if you got some bug using the new iOS SDK, you can fix it and submit a new version to App Store using the new Xcode.
Its prudent to test your apps on each new OS (preferably before the public release) but in most cases no new release is necessary. Over time you may want to update your app to take advantage of new features or to better support new devices. No app will never last forever but you will likely be able to go some time before having to update.
I want all users off my app to stay above a minimum threshold version. Is there a way I can configure it either in the code or app store that invalidates the users on a certain version and redirects them to the app store?
I assume you have already an application that in the production and installed to devices.
In this case, unfortunately you can't put version limit on them. The only way is, deprecating v1 APIs and creating v2 APIs. The older version app owners will get a warning (If you well made the error handling.).
Otherwise, you can add a new feature like checking the version on the startup of the application. And If it is older, you can show a message like "Please update the application." and put a button that redirects to the AppStore.
(The image is from a Medium blog post named "Mandatory Update for your apps".
I don't recommend forcibly redirecting users to AppStore. It is not a great UX practice. You can block the screen of the application with the warning but at least leave the basic functionalities open.
I wonder if there is any way to distribute different versions of same app (same means same bundle id, same account) in Apple Appstore.
Lets say, I want to distribute, MyApp (com.stackoverflow.myapp) version v1.2 but there is already a version v1.1 open to public. Is it possible to keep both version open for public. And fixing issues and release different sub version like, v1.1.2 and v1.2.2.
As far as I know with single bundle its not possible. But still I am curious if there is any workaround.
When you release a new version on to the app store, you can now select an option for a "phased release", where the update is shown to current users incrementally over a 7 day period, but at the end of that seven day period the updated version is available to everyone. Also, new users will get the latest release when they install from the App Store.
You cannot maintain two "active" releases on the store.
If you want to test a new version or new features with a limited set of users then TestFlight may be an appropriate tool.
You can use whatever versioning system you want (such as semantic versioning), but you can't distribute multiple versions of an app at a time without uploading them to the App Store as 2 entirely different apps
What does the following message supposed to mean? I added those new localizations to the app and I'm now submitting the app for review.
Does that mean App 4.1 version (I'm releasing now) will not have those localizations available in the app store until I release another version? (V 4.2 for example) I'm a little bit confused because some of the previous localizations didn't appear immediately in the store after releasing.
Yes, you must upload a new version if you want the new information in the App Store.
Always remember to save your changes before submit.
This is the expected behaviour as the "App Name" field is not tied to a specific version in iTunes Connect in contrast to description, keywords etc.
Its displayed a little bit "awkward" in iTunes Connect by the yellow circle and the highlighted app name.
The popup basically "confirms" that the changes you made to the app name don't go live immediately for your current version (I assume 4.0 in your example), but only for the approved version 4.1
Now I have a major feature to release and I want to see the impact of it on a specific app store. The question is, if I submitted the app to the store and approved it.
Would it kill all other instances on all stores and my app would be available on that one specific AppStore?
It's not possible to "soft launch" an update by itself via iTunes Connect (only new apps by choosing the available territories for sale).
If you change the availability of your app to one country, users would not be able to download/purchase/update your app anywhere else, which I guess is something you don't want.
But it's definitely something you can hard-code. (Question is, if you really want this/it makes sense)
I don't think so , since when releasing a new version it automatically remove the previous ones from the store , so the new and only version is valid for the territories you select.