Soft launches, dark launches and canary releases all reduce the risk of shipping to everyone at once. A soft launch releases to a limited market, a dark launch ships features hidden behind flags, and a canary release rolls out to a small share of users first. Here's when to use each for mobile apps.
Soft launch
A soft launch is used to describe the quiet release of a new app or update to a limited number of users. This is done with limited or no PR and media fanfare in a market that is smaller than but very similar to the app’s main market.
You can use soft launches to validate your app with real end users and solicit their feedback for any changes or improvements needed. It will show you how users are going to interact with your app, how they will use it, and whether its features are easily discoverable. You will also get to discover issues you might have missed and test the readiness of your infrastructure.
Conversely, you can use them as a test run for your app to gauge the market’s reaction and test your marketing message and strategy. Soft launches are also a great opportunity to get started on app store optimization and test your app store listing.
Canada and Australia are two of the most popular soft launching destinations because of their similarity to the U.S. market. However, depending on your target audience, there might be many other countries that will be suitable.
Dark launch
Dark launching is the release of a major change or a new app feature to a subset of your users with or without highlighting it to them. It can be used to stress test your app and discover any issues or performance issues. But you can also use it to test the feature’s adoption, monitor its impact on your users, and validate your assumptions.
With the use of feature toggles, analytics, and feedback tools, you can quickly see if your users are gaining value from the new feature and get their feedback about it. This gives you the opportunity to tweak your app and make the necessary change if the need arises.
Canary release
A canary release is very similar to dark launches, except it is done for all releases of your app and not only for new features or major releases. The goal of canary releases is to make sure that any issues that slip into production have a minimal impact on your users by stopping the release before it reaches more users.
Whereas dark launches are used to test features before making them widely available, canary releases focus on minimizing the risk and impact of production issues.
Canary releasing is a very effective strategy and is now a best practice that both Apple and Google have baked into their platforms and recommend using them. Apple calls the feature “phased releases” and Google calls it “staged rollouts”.
Soft launching vs. beta testing
A common misconception is that soft launching and beta testing serve the same purpose and are interchangeable. While they might look similar, they both have very different goals.
A beta app is an app that is in the late stages of development but isn’t quite there yet. It has a higher tolerance for issues and a wider scope for changes that can be made. On the other hand, soft launching is done with an app that has completed the development lifecycle. The main focus for a soft launch is stress testing your app and infrastructure and testing the market reaction. The scope of changes to the app is very limited and only if absolutely necessary and most of the changes will be on the marketing side.
Dark launching vs. beta testing
Dark launching is closer to beta testing than soft launching but there still are a couple of key differences. The most obvious being that dark launches require you to have a sizable user-base, to begin with. It is not a tactic that can be used for a new app or one that does not have a lot of users.
Another key difference is that in a dark launch, features are not tagged as beta and users have not opted-in to the test. This makes your users less tolerant for issues and less likely to provide you with feedback. Features you release in a dark launch should have a high degree of polish if you don’t want to risk upsetting your users.
How do you know a rollout is safe to expand?
A canary at 5% of users is only valuable if someone is watching. And "someone watching a dashboard" is not a release strategy, it's a way to catch problems late and under pressure.The approach that works is automated halt rules defined before the rollout begins:
- Crash-free rate threshold. Define the acceptable drop from the previous release's baseline. A drop of 0.2 points at 5% rollout means roughly 2 additional crashes per 1,000 sessions in the new build. At 10 million monthly sessions, that's about 2,000 additional affected sessions in the first hour if the rollout expands. Set the halt at 0.1 to 0.2 points, depending on your app's risk tolerance.
- ANR rate threshold. Application Not Responding errors are often the first sign of a main-thread regression in a new build, and they appear before crash rate starts to climb. Include ANR rate as a second halt condition alongside crash-free rate.
- Expansion criteria. Define when the rollout is safe to expand, not just when to stop it. Holding at 5% for 2 hours with no signal breach, then expanding to 25%, then 100% after another 2 hours, gives you structured visibility at each stage without indefinite hand-wringing.
- No manual approval required to halt. The halt rule should trigger automatically. A release that requires a human to be awake and watching to catch a problem will eventually catch it too late.
The goal is not to make rollouts slower. It's to make the decision to expand data-driven so it can happen confidently and without a team standing by.
Know when a rollout is safe to expand
Luciq compares stability and performance between releases in real time, and Autopilot can halt a rollout automatically if it starts to degrade.