Mobile Build and Release Engineering Questions

Overview — iOS vs Android signing

iOS: Apple issues development and distribution certificates (private key in your macOS Keychain). Provisioning profiles bind app identifiers, certificate(s), devices (for dev/ad-hoc), and entitlements. Team roles (Apple Developer Program) control who can create certs/profiles.

Android: Apps are signed with a keystore containing a private key (JKS/PKCS12). The key (alias + password) signs APK/AAB. Google Play accepts upload keys and app signing keys (Play Signing managed or self-managed).

Key components

• iOS: Certificate (public/private), Provisioning Profile, App ID (bundle id), Team membership/roles.
• Android: Keystore file, key alias, passwords, Play Console upload key vs app signing key.

CI automation best practices

• Store private keys/keystores in secure secrets manager (Vault, GitHub Secrets, Bitrise Secrets).
• Use fastlane match or GitHub Actions with encrypted secrets for iOS; use fastlane supply / gradle signingConfigs for Android.
• Limit access: short-lived tokens, least privilege service accounts.
• Automate renewal alerts for certs and provisioning profiles.

Common pitfalls

• Expired certificates/profiles → build/sign fail.
• Mismatched bundle/package name or entitlements vs profile/manifest.
• Lost private key (can't update app without key rotation via Play Signing).
• Incorrect key passwords or corrupted keystore.
• Multiple team members creating conflicting certs.

High-level CI/CD checklist

1. Centralize keys in encrypted secrets manager.
2. Use automation tooling (fastlane match / gradle signing + encrypted artifacts).
3. Provision a CI service account with minimal permissions.
4. Validate signing locally before CI.
5. Add monitoring/alerts for certificate expiry.
6. Backup enrollment keys securely and document recovery steps.
7. Test staged releases (internal track) before production.

Pipeline overview (stages)

• PR -> CI: lint, unit tests, build checks
• Merge to main -> CD: full builds, UI tests on device cloud, artifact storage, staged release
• Release gates: manual approval for production

Build matrix & parallelism

• Use GitHub Actions matrix strategy for OS/ABI/Flavors (android: API 29/31, iOS: 14/16) and variants (debug/release).
• Split heavy jobs (android build, ios build, android UI, ios UI) into parallel workflows; use job concurrency to limit device cloud slots.

Secrets & signing

• Store keystore, KEYSTORE_PASSWORD, FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD, Apple API key JSON, service account JSON in GitHub Secrets.
• Decrypt signing artifacts at runtime using actions/checkout + actions/upload-artifact for transient use; restrict secrets to protected branches and require approvals.
• For iOS, use Fastlane match (private git-backed certs) or Apple App Store Connect API keys; for Android, use Google Play service account JSON.

Testing on device clouds

• Integrate Firebase Test Lab (Android) and BrowserStack or Bitrise device cloud (iOS) via CLI; upload APK/IPA and run matrix of device+OS tests. Collect logs, screenshots, and video as artifacts.

Caching & dependency management

• Cache Gradle, .gradle/caches, ~/.m2, CocoaPods/Carthage/SwiftPM artifacts using actions/cache keyed by lockfile + OS + toolchain. Restore to speed builds.

Artifacts & storage

• Upload build outputs and test reports to GitHub artifacts or an S3 bucket. Tag artifacts with build number, git commit, branch.

Publishing

• Android: use Fastlane supply with service account to upload to internal, alpha, beta tracks; automate track promotion after approval.
• iOS: use Fastlane pilot / deliver with App Store Connect API key to upload dSYMs and IPA, submit to TestFlight, require manual review step for production release.

Observability & rollbacks

• Publish build status to Slack, include test summaries. Keep signed artifact snapshots for fast rollback and use staged rollouts (Play Store) and phased releases (App Store).

Overview (ProGuard vs R8)
R8 is Google’s successor to ProGuard: it combines shrinking, desugaring and whole-program optimization and produces smaller, faster APKs. ProGuard is older and only does shrinking/obfuscation. Modern Android Gradle uses R8 by default.

What they do

• Minification: remove unused code and rename symbols to shorter names to reduce size.
• Tree shaking (shrinking): analyze reachability to strip unused classes, methods, fields.
• Obfuscation: rename classes/members to unreadable names to hinder reverse‑engineering.

Keep rules for reflection
Use keep rules to prevent removal/renaming of classes/members accessed via reflection or JNI. Example:

-keep class com.example.myapp.models.** { *; }
-keepclassmembers class com.example.myapp.MyFactory {
    public java.lang.Object create(java.lang.String);
}

Use -keepnames to preserve names but allow shrinking.

Debugging incorrect rules

• Reproduce failing call (device logs / unit tests).
• Build with minifyEnabled false to verify issue disappears.
• Enable R8 verbose/proguard mapping and print usage to see what was removed:
  • In gradle: android { buildTypes { release { minifyEnabled true; proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } }
• Inspect R8 output (usage.txt, seeds.txt) and add targeted -keep rules or @Keep annotations.

Mapping file & crash reports
R8 outputs mapping.txt mapping original -> obfuscated names. Upload mapping.txt to crash reporting (Firebase Crashlytics, Sentry) so stack traces are deobfuscated for readable line/class names. Without it, crash reports show obfuscated symbols making debugging hard. Always archive the mapping per release.

Clarify requirements

• Multiple cross-platform apps in one monorepo, each with flavors (e.g., free/paid, staging/prod), environment-specific native libs, and distinct signing keys. CI must store credentials securely, allow key rotation, and run per-flavor pipelines with traceability and minimal duplication.

High-level approach

• Use flavor-aware build config (Android Gradle productFlavors, iOS xcconfigs + build schemes/targets).
• Store environment-native libs under flavor-specific dirs and expose via sourceSets (Android) / Build Phases or pods (iOS).
• Centralize signing metadata (keystore paths, provisioning profiles, key IDs) in a single build-metadata layer referenced by flavors.

Repo layout (example)

• /apps/{app}/android/{app}/src/{flavor}/...
• /apps/{app}/ios/{flavor}/...
• /ci/fastlane/{app}/Fastfile (shared lanes)
• /keys/ (not checked in; placeholders only)

Signing & native libs

• Android: use signingConfigs in Gradle that read key alias/password from environment variables; flavor -> signingConfig mapping.
• iOS: use xcconfig files per flavor with CODE_SIGN_IDENTITY and PROVISIONING_PROFILE_SPECIFIER; Fastlane match or Sigh to manage profiles/certs.
• Load native libs at build time from flavor dirs; guard with compilation flags.

Secure credential storage in CI

• Use cloud KMS + secret storage (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or GitHub Actions Secrets for smaller teams).
• Store encrypted artifacts (keystores, p12, provisioning profiles) in an artifact store accessible by CI after decryption with a short-lived key.
• CI jobs fetch secrets at runtime using IAM roles / short-lived tokens; never store plaintext in repo or logs.

Key rotation strategy

• Maintain versioned keys/certs in Vault or S3 encrypted; tag versions with metadata (created_by, expires_at).
• Automate rotation pipeline: generate new keypair -> upload encrypted -> update matching configs in staging -> run smoke-deploy -> promote and update production references.
• Use Fastlane match with git-backed certs or a secure backend and rotate by creating new certs and updating provisioning profiles; keep old keys for a rollback window.

Automating per-flavor pipelines

• Define a single templated pipeline with a flavor matrix (CI matrix builds flavors/platforms). Pipeline reads flavor metadata file (YAML) that maps:
  • flavor id -> signing secret name, native lib path, bundle id, app name
• Use reusable pipeline templates (GitHub Actions reusable workflows, GitLab includes) to avoid duplication.
• Fastlane: one Fastfile with parameterized lanes: lane(:build) { |options| build_flavor = options[:flavor]; ... }
• Cache common steps (dependency install, toolchain setup) and run flavor-specific steps in parallel.

Traceability & audit

• Produce signed build artifacts with metadata: flavor, git commit, build number, signing key version. Embed provenance in app metadata (CFBundle/Android manifest or a BUILD_INFO resource).
• Store build artifacts and logs in an immutable artifact repository (S3, Nexus) and log secret access via Vault audit logs and cloud IAM audit trails.

Example: CI flow (Android, flavor "staging")

1. CI matrix picks flavor=staging.
2. CI authenticates to Vault using workload identity.
3. Fetch encrypted keystore and decrypt to ephemeral path.
4. Run ./gradlew assembleStagingRelease using signingConfigs that read keystore path and env vars.
5. Run Fastlane supply or pilot deployment using short-lived API tokens.
6. Publish artifact with metadata and rotate/delete ephemeral secrets.

Trade-offs / best practices

• Favor centralized secret management and short-lived credentials.
• Keep pipelines declarative and parameterized to reduce duplication.
• Test rotation on non-prod first; keep rollback key material for a defined window.
• Log and monitor secret access; restrict who can update flavor metadata.

This approach balances security, auditability, and maintainability across many apps/flavors in a monorepo while enabling automated, traceable CI/CD.

Difference: Android App Bundle vs APK; IPA vs App Store distribution

• Android App Bundle (AAB): publishing artifact containing all compiled code/resources for every device/configuration. Google Play generates optimized APKs (split APKs / signed app bundles → Dynamic Delivery) per device. APK: a single installable package that may be universal or targeted; developer-built APKs can be larger and require more manual splits.
• iOS IPA vs App Store distribution: IPA is the packaged app binary (signed). For App Store distribution you upload an archive (IPA inside .xcarchive) to App Store Connect; Apple performs on-device thinning (slicing) and manages re-signing and distribution.

Benefits of bundles / app thinning

• Smaller download/install size (reduced network usage, faster installs)
• Device targeting: delivers only needed architectures, locales, screen assets, and modules
• Easier management of dynamic features (Android Dynamic Delivery) and on-demand resources (iOS)

How they affect size & targeting

• Reduce user-facing download by excluding unused ABIs, languages, and large assets
• Enable conditional delivery (Android) or on-demand resources (iOS) for feature modules

Basic steps to prepare & upload

Google Play:

1. Build AAB (./gradlew bundleRelease)
2. Ensure Play App Signing enabled, set versionCode/versionName, sign upload key
3. Test with internal test track; generate release notes
4. Upload to Play Console, configure device targeting, rollout percentage, submit

App Store Connect:

1. Archive in Xcode (Product → Archive), export for App Store distribution or use Transporter/Xcode upload
2. Increment CFBundleVersion/CFBundleShortVersionString, enable App Thinning/on-demand if used
3. Create app record, add screenshots/metadata, choose build in TestFlight for testing
4. Submit for review and release (manual or automatic)