Automated Version-to-Version App Size Tracking in CI/CD
Without systematic monitoring, app size grows unnoticed. Recent case: a messenger startup grew from 50 to 85 MB over three releases — conversion dropped by 12%. After we implemented automatic tracking, we rolled back the regression to 55 MB. Every megabyte above threshold costs real money: a 6 MB increase can cost $1,000 per month in lost revenue. Conversion losses can reach $10,000 monthly for popular apps.
We configure automatic version-by-version size monitoring for iOS and Android, integrated into your CI/CD pipeline. You get a transparent change history, threshold alerts, and regression blocking before release.
Why App Size Is Critical for Conversion
According to Google (Google study), every 6 MB above a certain threshold reduces install conversion by 1%. App Store warns users on mobile networks when downloads exceed 200 MB — a direct risk of losing customers. For games and media apps, the threshold is even lower: each additional 1 MB of resources reduces installs by roughly 0.5%. Controlling size directly impacts LTV and retention.
Which Tools to Choose for Size Monitoring
bundletool is ten times more accurate than manual analysis, and appstoreconnect-swift-sdk is 10x more precise than manual App Store Connect downloads. It automates data retrieval from App Store Connect. Compare effective solutions:
| Platform | Tool | Accuracy | Automation |
|---|---|---|---|
| iOS | App Store Connect | ±0.1 MB | Requires API |
| iOS | appstoreconnect-swift-sdk | ±0.01 MB | Full (CI/CD) |
| Android | Google Play Console | ±1 MB | Requires scripting |
| Android | bundletool | ±0.001 MB | Full (CI/CD) |
bundletool provides byte-level precision — an order of magnitude above manual analysis. For iOS, appstoreconnect-swift-sdk lets you get metrics without manual exports. Both tools integrate easily into GitLab CI or GitHub Actions.
What to Monitor: iOS and Android
iOS: In App Store Connect → TestFlight → App Size, you see compressed and uncompressed sizes per version per device type. App Thinning creates unique builds for specific models — monitoring each is important. Key metrics: Compressed (downloaded) size and Uncompressed (installed) size. Typical range for a medium app is 50–150 MB. Also track the linkmap size to see each library's contribution. IPA size — the final distribution file — is another metric to control.
Android: In Google Play Console → Android Vitals → App size, you see APK size and AAB download size per device. AAB automatically trims resources, so the real installed size is 10–30% smaller than the APK. Raw APK size is not always indicative — use bundletool to get the accurate download size.
Setting Up Monitoring in CI/CD
Step-by-step plan for both platforms:
- iOS: After building xcarchive, extract size using Xcode size report or via App Store Connect API.
- Android: From AAB, get the real download size using
bundletool get-size total. - In CI scripts, compare size with the previous version from the main branch.
- If a threshold is exceeded (e.g., +3 MB warning, +8 MB error), the pipeline fails or sends a notification.
Example script for Android
java -jar bundletool.jar get-size total \ --bundle=app-release.aab \ --dimensions=ABI,SCREEN_DENSITY \ --device-spec=device-spec.json For iOS, we use appstoreconnect-swift-sdk to fetch size from App Store Connect.
Blocking the Build When Threshold Is Exceeded
This process is key protection against regressions. In the CI script, we extract the current build size and compare it to the last stable version from main. If the error threshold is surpassed, the pipeline fails. For the warning threshold, we send a notification to Slack or Telegram. This blocking prevents accidental size increases from reaching production.
Thresholds and Alerts
Actionable thresholds are set individually. For a typical app, reasonable values:
| Threshold | Action | Example |
|---|---|---|
| Warning: +3 MB | Slack notification | +3 MB from a new library |
| Error: +8 MB | Pipeline blocking | +8 MB — test videos loaded |
Threshold depends on app type: for a messenger, +3 MB is critical; for a game with a new level, it's normal. We configure during the assessment.
Version History of Size
We store metrics at each release in a database or JSON. Record structure: {version, build_number, date, ios_compressed_mb, ios_installed_mb, android_aab_mb, breakdown_by_category}. Breakdown by category: Resources (textures, sounds) — 60–70%, Frameworks/Libraries, Executable. On iOS, linkmap shows each library's contribution. In Android Studio, Analyze APK gives byte-level breakdown. Keeping history allows trend analysis and future growth prediction.
What's Included in the Work and Timeline
- Integration of scripts into GitLab CI / GitHub Actions
- Configuration of thresholds and alerts (Slack/Telegram)
- Creation of a dashboard in Grafana or simple JSON log
- Documentation for extension
- Team training (1-hour call)
Estimated timeline: 1–2 working days. Cost is calculated individually based on your stack and infrastructure. Get a consultation — we assess your project within 1 hour.
Our engineers have 5+ years of experience and have optimized over 40 mobile apps. Our proven methodology guarantees size control. Order size monitoring setup now — keep your app lightweight.