Holiday Release Freeze for Flutter Apps on Google Play: A 5-Step Plan (2026)
When should a Flutter app stop shipping before the holidays?
Stop shipping features about two weeks before the holidays and send your last release for review at least a week before you want it live. Google says Play review can take up to seven days or longer in exceptional cases, so a one-week buffer is the sensible minimum. For 2026 that means this plan: feature cut-off on Thursday 3 December, last release sent for review on Thursday 10 December, publish on Thursday 17 December, and a freeze from Friday 18 December to Monday 4 January. This guide gives the plan as a named 5-step method I use for my own Flutter apps, with the dates, what to do if something breaks during the freeze, and how to restart in January.
Google's pages and your account's review times can change. I checked the Play Console Help pages below on 2026-11-05 and could not find a Google notice about different holiday review times for 2026, so the plan uses Google's general guidance. Check Play Console for any notice on your own account.
The Freeze, Buffer, Stage method: 5 steps for the holiday release
- Set the freeze dates. Pick the day after your last planned release and the day you will ship again. Mine is Friday 18 December to Monday 4 January. Write both in your release notes file so you do not decide at 11pm.
- Send the last release a week early. Work backwards from the day you want it live. If that is Thursday 17 December, send it for review by Thursday 10 December. Do not add new changes while it is in review, because a change submitted while others are in review can push your app to the back of the review queue (see the review-times guide below).
- Turn on managed publishing. Google reviews the update as usual, then holds it under "Changes ready to publish" until you click Publish changes. Approval no longer decides the go-live day, you do.
- Stage the rollout, with halt rules. Publish to a small percentage first and write your halt conditions before you press the button. Raise the percentage once the first days are quiet. Our staged rollout rules cover the percentages and the halt criteria.
- Freeze, with one hotfix path. During the freeze, ship only what fixes a crash, a broken payment or a policy rejection. Everything else waits for January.
The method uses only features Google documents: managed publishing, staged rollouts and the review window. The names are mine, and the point is to decide the dates once, in advance.
The 2026 holiday release calendar
| Date | What to do |
|---|---|
| Thu 3 December | Feature cut-off. After this, only fixes and store-listing text |
| Thu 10 December | Send the last release for review. Turn managed publishing on |
| Thu 17 December | Approved? Publish and start the staged rollout (for example 10%) |
| Fri 18 December | Freeze starts. Watch Crashlytics and reviews each day |
| Mon 21 December | Quiet? Raise the rollout toward 100% |
| Fri 25 December to Fri 1 January | Hotfix only. Keep the previous bundle ready |
| Mon 4 January | Freeze ends. Send the first January release for review |
| Thu 7 January | Earliest realistic go-live of that release, with a week's buffer |
The dates are a template, not a rule. If your last release is in review longer than expected, keep it ready under managed publishing and publish it on 4 January instead of rushing into Christmas week. The longer wait is cheaper than a bad release you cannot watch.
Why the one-week buffer
Google's publishing page says review times can be up to seven days or longer in exceptional cases for certain developer accounts. Most reviews are much faster, but a freeze plan should work for the slow case, so I plan around the seven days. For the full picture, read how long Google Play review takes in 2026. It explains the statuses and the one habit that makes review longer: sending a second change while the first is in review.
Managed publishing: the part that protects the freeze
Managed publishing separates review from release. Google's Help says that when it is on, your changes are reviewed as usual and then wait for you to publish them, which is useful for pushing an update live at a specific time. Two limits to know from the same page: your app must already be published, because you cannot use it for a first release, and you need a permission such as Release to production, or Admin, to turn it on or off.
For the holidays it removes a risk. Without it, an update approved on Christmas Eve goes live on Christmas Eve, whether you are around or not. With it, approval just means the release is ready. If you want to know how I use it day to day, the review-times guide above has the steps. If the update is still waiting on 17 December, you can also move changes back to "Changes not yet sent for review", which Google's Help describes, though it warns removed changes may still be reviewed again.
Staging, halting and the kill switch
A staged rollout delivers the new build to a share of users, so a bad crash hits a few people and not all of them. If metrics go wrong, you halt the rollout. A feature flag gives a second option for server-side behaviour: a Remote Config kill switch can turn a feature off without a new release, and during a freeze that can be the difference between waiting for review and acting at once. Firebase's Remote Config documentation describes how parameters are fetched and applied.
Write your halt rules now, while it is calm: a crash-free threshold, an email subject you will treat as urgent and a review keyword that means stop. A rule you wrote in November is easier to follow on 27 December.
What counts as a freeze hotfix
- Ship it: a crash on launch, a broken purchase or login, a data-loss bug or a policy rejection that threatens the listing.
- Wait for January: new screens, copy tweaks, library upgrades, anything that is "while we're at it".
When you do ship a hotfix, send it once. If other changes are already in review, a second submission can reset the wait, so batch the fix into a single, carefully tested release. Run the same Flutter and Firebase release checklist you use for any release; a freeze is the worst time to skip a check.
Restarting in January
On Monday 4 January, send the first release of the year for review, with managed publishing still on. Expect it live around Thursday 7 January if review takes the typical few days, and plan for the slow case. Before you send it, read the Publishing overview page for any change saved for later or waiting for review. Changes you saved in December stay in "Changes not yet sent for review" until you send them, so a forgotten listing edit will not go out by accident.
FAQ
Does Google Play have a holiday freeze for app updates?
I could not find a Google notice about different holiday review times for 2026 when I checked on 2026-11-05. Google's general guidance is that review can take up to seven days or longer in exceptional cases, so plan a week's buffer and check your Play Console notices.
When should I submit my last Android release before Christmas?
At least a week before the day you want it live. For a release live on Thursday 17 December 2026, that means sending it for review by Thursday 10 December.
What does managed publishing do?
It lets Google review your update as usual and then holds it until you click Publish changes. It works only for apps that are already published, and you need the right permission to turn it on.
Can I still ship a fix during the freeze?
Yes. Keep the freeze for features and ship only fixes for crashes, broken payments or policy rejections. Send a hotfix once and test it first, because a second submission while another is in review can reset the wait.
Sources
- Play Console Help: Publish your app (statuses, review times) (checked 2026-11-05)
- Play Console Help: Control when app changes are reviewed and published (managed publishing) (checked 2026-11-05)
- Firebase Remote Config documentation (checked 2026-11-05)