How the phased rollout of App Store Connect works in detail? The official Apple documentation is very poor and doesn't mention a lot of things that matter. Let me formulate some questions.
The situation
The current version of my app is 1.0 and is released to everyone in the App Store. The version I want to release is 2.0 (Build number: 100) and is a major update with breaking changes
I start a phased release for version 2.0
After 2 days the update has reached 2% of my users (randomly selected) with automatic updates turned on. I decide to pause the release because I found a critical bug
I create a version 2.0.1 (Build number: 101) with the bugfix to 2.0
I create a version 1.0.1 (Build number: 102) with intent to rollback to 1.0 in case the major update it's not going well
Questions
How does the release of an update work during a phased release? Will version 2.0.1 be released only to the same 2% of the users that already received version 2.0? Or it will be delivered to a completely new 2% of my users?
In case it's a new 2% of users:
2.1 what happens to the 2% of users that are on 2.0 and to the remaining 98% that is still on 1.0?
2.2. is it true that is completely new 2%? Because if they are randomly selected, potentially there could be an intersection between the old 2% and the new 2%.
In case I don't want to proceed with the release of the bugfix 2.0.1 (e.g. I realize that the major update 2.x is not behaving well), what is the strategy to rollback to version 1.x? How can I push 1.0.1 to everyone? Should I cancel the phased released of 2.0 and just submit 1.0.1?
Thanks in advance for the help! I have read tons of Stackoverflow posts and I have tried to look everywhere on the web, but I didn't find any clear answer about the topic above.
It will be a different random selection of users
2.1 Nothing special. They stay on their current version until they update (either automatically or manually).
2.2 As it is a random selection, there could be some overlap
You can't. Version numbers always increase. You could take your version 1.0 code base and release it as version 2.0.2 or something, but you can't release a new "1.0.x"
To clarify this answer, it is perhaps a bit misleading to use the word "selection". This implies that when you activate a staged rollout, the App Store somehow chooses the devices that will get the update each day, in advance and the update is "pushed" to those devices.
This is not what happens.
iOS devices periodically check with the App Store to see if updates are available for their installed apps and pull them if auto updates are enabled.
For a given app:
If a non-staged update is available then the answer is "yes"
If a staged update is available then the answer is randomly "yes" or "no" with an increasing probability of "yes" during the rollout period, with that probability reaching 100% by the end.
Either way, if the answer is "yes", it is the most recent version of the app that is installed.
Related
I currently have my app available on the store with version 1.5.0, and my idea is to release 2.0.0, but in case something goes wrong with that version I would like to run in parallel fallback version of 2.0.1 that is going to replace risky feature with another one more stable. Is there any option to achieve this in parallel? ItunesConnect doesn't allow me to create 2 versions at the same time.
I've found here that it's not possible to revert to previous app version once new one is out, so there is only this option of releasing a fallback version right after the first one is out.
Let’s imagine I have an iOS app. In version 2.0, I added a bunch of new features, but to implement them, I had to drop support for an older iOS version which is still in heavy use (remember, it’s a hypothetical scenario).
Later, I discovered a super critical bug in version 1.0 of my app that needs to be patched.
What are my options in terms of distribution?
It seems that it’s not possible to release version 1.0.1 if version 2.0 is already on the App Store. Adding back support for the older iOS version and fixing the bug in 2.0.1 is not feasible because that would require removal of the new features.
The problem here is that I can’t think of a way you could submit a version that updates version 1 without letting your version 2 users download it. So if you want to update version 1 you will just have to bite the bullet and meld your versions together. Use availability so that the new features are not present for your version 1 users.
I am running gitlab-ce in docker containers. I am currently using version 10.5.4. I want to update because of a few bugs with kubernetes in this old version.
Reading the documentation Here the advice is to "first upgrade to the latest available minor version within your major version."
But reading other docs Here says I should update through each minor version. Is that just to avoid downtime?
What is the simplest Upgrade path for me to 11.8, if we're not too worried about downtime?
For anyone else reading it, the quote from the first link is:
We recommend that you first upgrade to the latest available minor version within your major version. By doing this, you can address any deprecation messages that could change behavior in the next major release.
Based on the table below that, the GitLab upgrade path would be 10.5.4 -> 10.8.(latest), fix the deprecations, then 10.8 -> 11.8. The page makes clear that one can (probably) jump between any patch/minor versions without going through the intermediate steps:
It is considered safe to jump between patch versions and minor versions within one major version.
The second source is presumably the Upgrading without Downtime section immediately below the one linked in the question.
Starting with GitLab 9.1.0 it’s possible to upgrade to a newer major, minor, or patch version of GitLab without having to take your GitLab instance offline. However, for this to work there are the following requirements:
You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to 9.3.
It then provides details on background processes required for migrations. These are substantial, so it makes sense that jumping multiple minor versions could be a bit much is not recommended. One minor version at a time for upgrading without downtime. Useful once you are up-to-date, but may be worth skipping with so many minor versions to get through.
I know Apple and iTunesConnect are very strict about version numbers always incrementing (which has certainly caused problems for us in the past), so I am naturally hesitant at introducing a four-segment version for a one-off app update with the intent of going back to three segments for the next release.
For example, the current version is 1.0.7. We need to push an update out for an app that is not on the normal release cadence (minor update, just some graphics changed). Rather than have to bump all future versions, I was thinking to release this patch as 1.0.7.1, such that the next version can resume at 1.0.8.
However my worry is that if I introduce a four-segmented version of 1.0.7.1, Apple won't let me go back to three segments for 1.0.8.
I obviously can't just try it out to see given that Apple won't let you delete versions.
No problem about that. If version number increments, then there won't be any problem.
Let's just base this on real data :) ...
Notice the change from version 7.0.3 to 7.1.
I get the "BASE SDK Missing" when re-opeing projects. (I got the latest build of xcode, and latest SDK installed.)
It seems to be happening when I quit a project, (not exiting xcode), and re-open the project after a while. I have tried both, with and without my iPhone plugged in. I have tried to fix the problem like described here, but it does not help for me. - It just makes it even worse! (unrecognizable SDK)
The only way I have managed to get it back to normal, is to do a manual re-boot of my mac, plugged in my phone, waited until it has checked my iPhone, and then, opened xcode. Time consuming and annoying!
Why does it happen and what is the trick to fix this?
Your recent upgrade of Xcode likely removed the earlier SDK that your project was set to use. There are a couple of solutions for the problem. The most simple solution is to always select the "Latest" SDK in your project's settings and not select a specific option. You may be uncomfortable with the idea and want to run your app on an older device but it's important you understand that all of the newer SDKs can generate code that works on older versions of iOS. There's a separate hard to remember option for setting the deploy target. (It took me a while to learn how/why to use this but it's well worth it.)
The second option is to actually find a version of the SDK that your project is set to and attempt to reinstall it. I suggest going this route only if necessary as it's not guaranteed to work in each case. Older SDKs may or may not work in later versions of Xcode (Eg. SDK 3.0 might not work in Xcode 4.3.2) due to major changes in the toolchains. Tools like gcc/gdb are deprecated in favor of llvm/lldb. Still, you may have a valid reason for using an older SDK. You may have to fix a bug that is present only when using the older toolchain or you may need to reproduce a problem that only happens with builds generated from your build server. In many of these cases it might be easier to upgrade where the problem occurs (Eg. upgrade the tools on the build server) or downgrade your dev environment. (Install an older version of Xcode.)
The reasoning behind the frustration is that Apple highly encourages rapid adoption of it's latest tools and technologies. It creates a better product as the dev community is forced to stay current and competitive while the users are forced to maintain upgrades to ensure apps continue to work. This is in contrast with the traditional model of backward compatibility allowing developers to support revision -n of a product/platform. It is also great for business since rapid adoption of the latest often encourages purchase of newer hardware and products to get the best experience. The rapid adoption ensures the more robust software along with bug fixes, enhancements make it to the majority of consumers overall increasing their penetration in the market.
You have to set your target and project's base SDK to "Latest" and not an explicit option. If you choose one explicitly it seems to break if you update xcode versions.