.github/workflows/binary-check.yml
TL;DR
Most mobile teams treat App Store review as a gate to endure, not something they can actually use to grow. That’s a mistake. Submission frequency, binary size deltas, and metadata update velocity all send signals that correlate with improved organic discovery on both the App Store and Play Store. In apps I’ve worked on, teams that ship weekly with disciplined binary management consistently outperform those shipping monthly. The features aren’t necessarily better. The pipeline itself becomes a discovery advantage. I’ll walk through the observed patterns, the operational mechanics, and a concrete CI/CD strategy to exploit this. A caveat upfront: store algorithms are opaque, and correlation is not causation. I’ll address that directly.
Your release pipeline is your ASO strategy
Here’s what most teams get wrong about App Store Optimization: they pour effort into screenshots, keywords, and descriptions while ignoring the behavioral signals their release pipeline sends to store algorithms. In my experience building production mobile apps, the single most underexplored correlation in ASO is between release velocity and organic discovery. Your operational cadence is not overhead. It is a ranking input.
How store algorithms likely read your submission pattern
Both Apple and Google use language like “keeping your app up to date” in their developer guidelines, and Google’s Play Console documentation explicitly notes that app freshness factors into search relevance. Neither company has published the precise weighting of these signals, but the following patterns are consistent with what I’ve observed across multiple production apps and what third-party ASO tools like Sensor Tower and AppTweak report in their research:
| Signal | What the algorithm likely sees | Observed correlation |
|---|---|---|
| Submission frequency | Active development, ongoing investment | Consistent updates correlate with higher search rank |
| Binary size delta | Optimization discipline vs. bloat trajectory | Shrinking binaries correlate with improved quality scores |
| Metadata update cadence | Keyword freshness, seasonal relevance | More frequent updates correlate with faster keyword indexing |
| Review rejection rate | Code quality, guideline adherence | Unclear, no public confirmation this affects visibility |
| Time between approval and release | Release confidence, staged rollout maturity | Staged rollouts correlate with lower negative review rates |
In apps I’ve worked on, weekly updates on the Play Store correlated with roughly 3-4x faster indexing of new keyword combinations compared to monthly update cycles. On iOS, each approved submission triggers a re-crawl of your metadata. More submissions means more opportunities for the algorithm to re-evaluate your keyword relevance. These are observed patterns, not confirmed mechanics.
Binary size: the signal nobody optimizes
Binary size is not just a user experience metric. A consistent upward trend may signal technical debt accumulation, and both stores surface download size prominently to users, directly affecting conversion rates. Apps that hold steady or shrink their binary while adding features demonstrate something different: engineering maturity that the stores can see too.
Here’s a practical CI check I add to every mobile pipeline:
# .github/workflows/binary-check.yml
- name: Check binary size delta
run: |
CURRENT=$(stat -f%z build/App.ipa 2>/dev/null || stat -c%s build/App.ipa)
# Pull baseline from CI artifact storage rather than a local file
# that gets overwritten each run — prevents masking gradual bloat
BASELINE=$(curl -sf "$ARTIFACT_URL/binary-baseline.txt" || echo 0)
DELTA=$(( CURRENT - BASELINE ))
PERCENT=$(( DELTA * 100 / (BASELINE + 1) ))
if [ "$PERCENT" -gt 5 ]; then
echo "::warning::Binary grew by ${PERCENT}% vs. committed baseline — review before submission"
fi
# Upload new size as artifact but do NOT auto-update baseline
# Baseline should only be updated intentionally via a dedicated workflow
echo "$CURRENT" > binary-size-current.txtThe key detail: store your baseline in CI artifacts, a dedicated branch, or a checked-in file that requires explicit PR approval to update. If you overwrite the baseline on every build, you only compare against the previous run, and gradual bloat across dozens of releases goes undetected. An intentional baseline reset, say quarterly or after a major optimization pass, keeps the comparison meaningful.
This takes five minutes to set up. I wish I’d done it years earlier on every project.
Metadata velocity: the compounding keyword strategy
Most teams update their App Store keywords at launch and then forget about them. The teams I’ve seen grow from 50 to 5,000 daily installs treat metadata as a living system:
- Rotate low-performing keyword slots weekly (anything ranked 80+)
- Time localized metadata updates to each region’s peak search periods
- Align subtitle and promotional text changes with your submission cadence
Here’s what matters: you don’t need a new binary to update promotional text on iOS or short descriptions on the Play Store. But pairing metadata changes with binary submissions appears to amplify indexing priority based on the patterns I’ve observed.
The optimal release cadence
Based on patterns across multiple production apps, here’s the cadence that maximizes the correlation with algorithmic benefit:
| Action | Frequency | Rationale |
|---|---|---|
| Binary submission | Weekly | Maintains “active” signal, triggers re-indexing |
| Keyword/metadata update | Every submission | Compounds keyword discovery |
| Binary size audit | Every submission | Prevents bloat signal, tracked against fixed baseline |
| Staged rollout (Play Store) | Always on | Reduces negative review impact, signals maturity |
| Phased release (App Store) | For major versions | Limits negative review impact on ranking |
This cadence requires a mature CI/CD pipeline. If your team can’t ship weekly, fix that first. No keyword strategy will compensate.
The correlation-causation problem
I want to be direct about something this analysis can’t fully untangle: teams with the discipline to ship weekly also tend to have better code quality, stronger testing practices, and sharper product thinking. These factors independently improve app quality, ratings, retention, and rankings. It’s genuinely difficult to isolate what release cadence alone contributes versus the broader engineering maturity that enables it.
That said, I think the operational benefits are real regardless of the causal mechanism. Weekly releases force smaller changesets. They reduce risk per deployment. They accelerate feedback loops and create more indexing opportunities. Even if the ranking lift comes partly from the better engineering practices that weekly shipping demands rather than the submission frequency itself, the outcome is the same: build the discipline, and the metrics follow.
Caveats
Store algorithms are opaque and change frequently. Neither Apple nor Google publishes ranking formulas, and what works today may shift tomorrow. The recommendations in this post are best-practice hypotheses grounded in observed patterns across production apps and corroborated by third-party ASO research. They are not confirmed mechanics. Test these strategies against your own data. Measure keyword rank movement, impression volume, and install conversion before and after changing your release cadence. Let your numbers confirm or challenge these patterns.
What to do with this
Ship weekly, even for small changes. Every approved submission creates a re-indexing opportunity. Frequency compounds into discovery advantage. Set up your CI/CD pipeline to make weekly releases trivial, not heroic. And recognize that the engineering discipline this demands is itself worth building, independent of any ranking effect.
Add a binary size gate to your CI pipeline with a stable baseline. Track deltas against a committed or artifact-stored reference point, not the previous build. Flag growth over 5%. Binary bloat is both a conversion risk and a potential ranking signal.
Treat metadata as code. Version it, rotate it, measure it. Update keywords with every submission. A/B test subtitles. Pair metadata changes with binary releases for maximum indexing impact. Track rank changes per keyword per release cycle.
The teams that win organic discovery aren’t the ones with the best keywords. They’re the ones whose operational discipline sends the right signals, at the right frequency, to algorithms that reward exactly that behavior. Build the pipeline first. Measure relentlessly. I’ve watched this work too many times to chalk it up to coincidence.