Why I Prefer the "Two Small Steps, One Big Step" Strategy When Releasing Major Updates for Apple Products

First, let me introduce the concept. "Two small steps, one big step" is a strategy I use when releasing iOS product updates. It involves submitting two minor version updates with secondary features first, followed by a major update with the primary feature based on the situation. This approach can also be called "two minor, one major."

To break it down further in terms of product progress management: when planning a medium-sized major feature update, I split it into two smaller, lower-effort incremental updates for the initial stages. Then, in the third step, I complete the entire feature in one go.

This isn’t something I came up with on a whim. It’s a habit I developed after encountering various pitfalls and issues in past product submissions.

The First Issue: Difficulty in Troubleshooting Review Problems

When a product undergoes a so-called "major update" with comprehensive changes to code, resources, and metadata, getting hit with a 2.3.1 or 4.3 error from Apple can leave you scrambling.

Submitting too much code at once makes it hard to pinpoint hidden 2.3.1 errors or locate resource-related 4.3 issues. This can be a nightmare to resolve.

By breaking down the code and resources for a major update across multiple smaller updates, it becomes easier to identify problems in a specific update and trace them back to the offending code or resources.

The Second Issue: Inability to Release Important Updates at the Ideal Time

To explain this, I need to introduce an Apple review "mystery." Here’s the mystery: If a product submits two updates in a cycle that get approved quickly, the third update is also highly likely to receive lenient treatment.

I call it a "mystery" because this pattern isn’t officially acknowledged by Apple. However, in my extensive practice, it has proven effective most of the time. When I’ve shared this approach with other developers, their experiences have largely aligned with mine. So, we can treat this mystery like traditional Chinese medicine: don’t worry about why it works—just focus on whether it’s consistently effective. If it is, trust it for now.

A standard major update can’t fully leverage this "mystery." When releasing a major version, you’re at the mercy of Apple’s unpredictable review cycles. For example, during periods when Apple’s review process is particularly harsh (due to internal performance pressures, crackdowns on certain categories, etc.), your major version might face brutal scrutiny and fail.

Given the importance of major updates compared to minor ones, we’re reluctant to take such risks. So, when submitting a major update, we want the product to have a relative advantage in the review weighting. By first submitting two smaller, split-up versions, these act like "scout heroes" in Heroes of Might and Magic III—they carry minimal troops to explore the path and solidify risk assessment.

If these two minor versions run into issues (e.g., encountering strict reviews), you can address the problems for the minor updates without jeopardizing the major version. Once the minor versions are resolved, you can submit two more to continue probing. To extend the Heroes of Might and Magic analogy: if the two scout heroes die during exploration, you now know what’s on that path and can send two more heroes to explore alternative routes.

Ultimately, the goal is to ensure that two consecutive minor versions pass review smoothly. Once that’s confirmed, you can confidently release the major update with much greater certainty.