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
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.
We have a browser application and this application is using by different clients. Each client is using separate database and service. Regularly(quarterly) we are releasing the upgrade with enhanced features. But some of the clients may not upgrade to the latest. So different clients are using different versions of our product. There is no issue with this because each clients are using their own Database and service. Recently we build up a iOS app for the same application. In app store we can upload only the latest version of our app, how the clients in lower version can install respective version of their app? Latest version app may not work with lower version of service and Database
Different clients needs to install different versions of same app from app store.
In App Store Connect (where you manage your apps in the App Store), you can choose which versions you want to remain in the App Store after you release a new version. The purpose of this is to allow an older version to be downloaded in case the user have an older device or iOS version that don't support the new app version. - So I guess this feature is not really helping in your case.
I would suggest you make the same version for everyone, and then within the App (I assume your clients have a login) based on their user selects what you want to present them. - Connecting to their old database and deactivating the new features as an example. This will also give you the opportunity to showcase that there is new features which they may want to opt-in on.
You can release a completely new app for each version. Ex. YourApp 1.0, YourApp 2.0 (This is not uncommon, but it's usually more if the same app is radically changed/improved, and you want the old version to remain for some time until you retire it completely).
Hope this clarifies a bit :)
I've just published an app on Apple's store and I'm wondering about having multiple versions of the same app for testing on TestFlight. Of course dev doesn't stop when publishing... from now on I'll have to update the app store version (v1.0.0) with bug fixes (v1.0.1, v1.0.2, ...) and before doing so I'd like to check them in test flight to ensure the fix was appropriate.
My problem is that I'm already starting to develop the next version with further functionalities of the app which will become v1.1
So ideally I'd like to have my app available both for my bug fixes, for instance v1.0.2 and also my next version v1.1.0 (this will include all bug fixes made to the store version and also many new features, refactors, redesign, etc)
I know that if I build and upload to the apple store connect a build with v1.1.0 (next version) I won't be able to upload one for a built with a bug fix on the current app store version (v1.0.2) since this version would be lower than the one I uploaded (next version)
Is there a way to accomplish this? I've read this article https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app which solution is to create extra applications in iTunes with different app ids and bind them to different certificates. But what will happen when the next release is ready to be in the store? I would have to release it and then disable the previous one? How may this affect my users? Will they have to re-install a new app rather than updating it?
I really need to start testing and checking the next release of my app in TestFlight and also support the current one with updates if something pops up. Thanks in advance!
I am able to upload multiple versions of the app to TestFlight. Each upload requires a higher version/build number, but you can switch the TestFlight test version between them as need be for testing.
Once I submit a particular build for release, however, I seem to lose the TestFlight access to the old builds.
In short, you can have many builds available in TestFlight, but once you submit the app for release, you have to start over making builds for TestFlight.
You keep talking about numbers like v1.0.1. That looks like a public-facing version string, with a major, minor, and patch number.
But that is not what TestFlight cares about. Well, it cares to some extent. But all TestFlight really cares about is that every new build you upload has a new build number. This is just an integer which you simply increment every time you submit a new build.
So you could have v1.0.1(23) on the App Store, and then on TestFlight you could upload v1.0.2(24) which starts moving forward toward version 1.0.2, but also upload v1.0.2(25) which is actually an attempt at a prospective version 1.1. TestFlight doesn't know or care what these different builds signify. They can all exist simultaneously on TestFlight. Keeping them all straight and on their individual trajectories is up to you.
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.
I submitted my Full and Lite version of my iOS App to the Apple App Store for an incremental release (1.2) - both Apps are already For Sale. I added In-App purchases to my Lite version.
My Full version was approved, but my Lite version was not. In discussing with Apple, they have provided a screen shot showing that they can't access the In-App functionality in the Lite version, but the screenshot is from my Full version, which doesn't have that functionality.
I'm appealing, and am hopeful that they will address.
This is the first time any App I've had was rejected, and I have several questions that I would appreciate any suggestions from developers who have gone through this.
Is there a way for me to run the exact code that I submitted from the Organizer/Archive so that I can verify that my Lite version is indeed the Lite version and not the Full version? I can see them in on the local file system, and there are 2 different, distinct files that have different sizes.
If I have to rebuild my App and resubmit can I do that from the same archive that is in Organizer?
If I have to rebuild, I think I'm in a bit of trouble, because I've been heads down on the next release for the past week and a half. Is there a way to access the version that was used to build the archive?
thanks.
You can resign the released version to be an adhoc version and run it on your device.
If it requires a new build it won't let you submit with the same version number which will probably stop you from using the same archive unfortunately.
It has been my practice to make a snapshot for every release for this case. If you don't have a saved snapshot or if you aren't using source control then you may be out of luck on that one.