Building KidSpark: CI/CD Pipeline and App Store Submission (Part 8 of 10)

The first time Linh tried to build KidSpark for both platforms on her local machine, I was on a call with Toan discussing our beta testing timeline. I could hear her across the office, and I mean that literally. Not yelling, but the kind of sustained, low-frequency muttering that signals a developer who’s been fighting the same toolchain for three hours and is losing the will to continue.

I walked over after my call. Her screen was split between four terminal windows — Xcode on one side throwing cryptic provisioning profile errors, a Gradle build failing because the wrong Java version was on her PATH, an Android keystore that she’d generated but couldn’t find because it was saved in a directory that no longer existed after a Flutter clean, and a sticky note on her monitor that read “SIGNING IDENTITY EXPIRED” in letters large enough to read from across the room.

“Four hours,” she said. “Four hours to produce two build artifacts. The iOS build failed three times because my distribution certificate expired yesterday and I didn’t notice. The Android build failed twice because of a keystore password mismatch. Then the Android build succeeded but I realized I’d built a debug APK instead of a release AAB. And I still haven’t uploaded either one to the stores.”

I pulled up a chair. “How much of this can we automate?”

“All of it,” she said immediately. “Every single step. And we need to, because if I get hit by a bus tomorrow, nobody else on this team can ship a build. The signing keys are on my machine. The process is in my head. This is a bus factor of one for our most critical workflow.”

She was right. And that conversation — born from frustration, not from strategic planning — became the catalyst for KidSpark’s CI/CD pipeline. What followed was two weeks of Linh building the most important infrastructure our project would ever have: the automated system that turns code into shipped product. This post is the story of that system, and everything that came after — the app store submissions, the rejections, the optimizations, and the lessons learned from getting a kids app through two of the most scrutinized review processes in software.

Mobile CI/CD Is Not Web CI/CD

If you’ve built a CI/CD pipeline for a web application, you might think mobile CI/CD is the same thing with different build commands. I thought that too, initially. I was wrong in ways that cost us time and money.

Let me walk through the differences, because understanding them is the prerequisite for building a pipeline that actually works.

Code signing is the biggest difference, and it’s not close. A web application’s build output is a bundle of HTML, CSS, and JavaScript. You deploy it to a server or CDN. Nobody asks you to cryptographically prove that you are who you say you are before users can access your website. Mobile is fundamentally different. Every iOS app must be signed with an Apple-issued certificate tied to your developer account. Every Android app must be signed with a keystore that you generate and guard with your life. If you lose your Android keystore, you cannot update your app — ever. You’d need to publish a new app with a new package name and lose all your ratings, reviews, and install count. Your iOS certificates expire and need renewal. Your provisioning profiles specify exactly which devices can run your app and which capabilities it can use. This is not a minor complication. This is the foundation on which the entire build process rests, and if you get it wrong, nothing else matters.

Binary artifacts change the deployment model entirely. Web CI/CD typically ends with uploading files to a server — a process measured in seconds. Mobile CI/CD produces binary artifacts — an Android App Bundle (AAB) weighing 30-80 MB and an iOS App Archive (IPA) weighing 50-150 MB. These artifacts must be uploaded to Google Play Console and App Store Connect respectively, through APIs that are slower, flakier, and more authentication-heavy than any web deployment target you’ve used.

Platform-specific build tools add complexity. Android builds require the Android SDK, a specific version of the JDK (we use Temurin 17), and Gradle with its own plugin ecosystem. iOS builds require Xcode, which only runs on macOS. This means your CI/CD pipeline needs macOS runners for iOS builds — and macOS runners on services like GitHub Actions cost roughly ten times more per minute than Linux runners. Your pipeline architecture must account for this cost differential.

Build times are measured in minutes, not seconds. A typical web build with Vite or Next.js takes 10-30 seconds. Our KidSpark Android build takes about 8 minutes. Our iOS build takes 12-15 minutes, and that’s with caching. Without caching, the iOS build can exceed 20 minutes because CocoaPods dependency resolution and Xcode compilation are not fast processes. This means your feedback loops are longer, your CI costs are higher, and your developers spend more time waiting.

Secret management is existentially important. Your Android keystore and your iOS signing certificates are the crown jewels of your mobile project. If they’re compromised, an attacker could sign malicious updates to your app. If they’re lost, your app’s identity is gone. These secrets cannot live in your repository. They cannot be passed around on Slack. They must be encrypted, access-controlled, and rotated according to a policy that you actually follow — not one that lives in a document nobody reads.

Device-specific testing adds a dimension web doesn’t have. Web CI/CD might include browser testing, but browsers are relatively standardized. Mobile devices are a fragmented landscape of screen sizes, OS versions, chipsets, and manufacturer-specific behaviors. Your pipeline needs to account for testing across multiple device configurations, which means either emulator farms or cloud-based device testing services.

When I laid all of this out for Toan in a brief document, his reaction was telling: “So it’s like web CI/CD, but harder in every way?” Yes. Exactly. And that’s why getting it right matters so much — because getting it wrong means manual, error-prone processes that will break at the worst possible times.

The KidSpark CI/CD Pipeline

KidSpark CI/CD Pipeline — from code push through quality gates to app store distribution

Linh spent two days researching CI/CD options before writing a single line of YAML. She evaluated GitHub Actions, Bitrise, Codemagic, and CircleCI. Her conclusion: GitHub Actions gave us the best balance of cost, flexibility, and integration with our existing GitHub workflow. Bitrise and Codemagic are excellent mobile-specific services, but they add another vendor relationship and another billing line item. Since our codebase was already on GitHub and our team was comfortable with Actions, keeping everything in one ecosystem reduced cognitive overhead.

Here’s the complete workflow she built. I’m going to show the full YAML first, then walk through each section in detail, because the details are where mobile CI/CD either works or falls apart.

The Complete GitHub Actions Workflow

name: KidSpark CI/CD

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  FLUTTER_VERSION: '3.24.0'
  JAVA_VERSION: '17'

jobs:
  analyze-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ env.FLUTTER_VERSION }}
          cache: true
      - name: Install dependencies
        run: flutter pub get
      - name: Analyze
        run: flutter analyze --no-pub
      - name: Run tests
        run: flutter test --coverage
      - name: Check coverage threshold
        run: |
          COVERAGE=$(lcov --summary coverage/lcov.info 2>&1 | grep "lines" | grep -oP '[\d.]+%' | head -1)
          COVERAGE_NUM=${COVERAGE%\%}
          echo "Coverage: $COVERAGE"
          if (( $(echo "$COVERAGE_NUM < 80" | bc -l) )); then
            echo "::error::Test coverage $COVERAGE is below 80% threshold"
            exit 1
          fi

  build-android:
    needs: analyze-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: ${{ env.JAVA_VERSION }}
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ env.FLUTTER_VERSION }}
          cache: true
      - name: Decode keystore
        run: echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | base64 -d > android/app/keystore.jks
      - name: Create key.properties
        run: |
          echo "storeFile=keystore.jks" > android/key.properties
          echo "storePassword=${{ secrets.KEY_STORE_PASSWORD }}" >> android/key.properties
          echo "keyAlias=${{ secrets.KEY_ALIAS }}" >> android/key.properties
          echo "keyPassword=${{ secrets.KEY_PASSWORD }}" >> android/key.properties
      - name: Build AAB
        run: |
          flutter build appbundle \
            --release \
            --build-number=${{ github.run_number }} \
            --dart-define=API_URL=${{ secrets.API_URL }}
      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: android-release
          path: build/app/outputs/bundle/release/app-release.aab
      - name: Upload to Google Play Internal
        uses: r0adkll/upload-google-play@v1
        with:
          serviceAccountJsonPlainText: ${{ secrets.GOOGLE_PLAY_SERVICE_ACCOUNT }}
          packageName: com.kidspark.app
          releaseFiles: build/app/outputs/bundle/release/app-release.aab
          track: internal

  build-ios:
    needs: analyze-and-test
    runs-on: macos-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ env.FLUTTER_VERSION }}
          cache: true
      - name: Install CocoaPods
        run: cd ios && pod install
      - name: Setup iOS signing
        uses: apple-actions/import-codesign-certs@v2
        with:
          p12-file-base64: ${{ secrets.IOS_DISTRIBUTION_CERT_BASE64 }}
          p12-password: ${{ secrets.IOS_DISTRIBUTION_CERT_PASSWORD }}
      - name: Install provisioning profile
        run: |
          mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
          echo "${{ secrets.IOS_PROVISIONING_PROFILE_BASE64 }}" | \
            base64 -d > ~/Library/MobileDevice/Provisioning\ Profiles/kidspark.mobileprovision
      - name: Build IPA
        run: |
          flutter build ipa \
            --release \
            --build-number=${{ github.run_number }} \
            --export-options-plist=ios/ExportOptions.plist \
            --dart-define=API_URL=${{ secrets.API_URL }}
      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: ios-release
          path: build/ios/ipa/KidSpark.ipa
      - name: Upload to TestFlight
        uses: apple-actions/upload-testflight-build@v3
        with:
          app-path: build/ios/ipa/KidSpark.ipa
          issuer-id: ${{ secrets.APP_STORE_CONNECT_ISSUER_ID }}
          api-key-id: ${{ secrets.APP_STORE_CONNECT_KEY_ID }}
          api-private-key: ${{ secrets.APP_STORE_CONNECT_PRIVATE_KEY }}

Walking Through the Pipeline

Let me break down what’s happening and why each decision was made.

The trigger strategy uses push on main and develop, and pull_request targeting main. This means every PR gets the full analyze-and-test suite before it can merge, but the expensive platform builds only run when code actually lands on main. During development, we pushed to develop frequently — sometimes ten times a day — but actual builds that could reach the app stores only triggered from main. This saved us a significant amount of CI minutes. At GitHub Actions’ pricing for macOS runners, an unnecessary iOS build costs real money.

Pinning the Flutter version at the environment level is critical. Flutter’s “latest” version on any given day might introduce breaking changes. We learned this the hard way when a Flutter minor version bump changed the behavior of MaterialPageRoute transitions and broke three of our screen tests. By pinning to 3.24.0 in the workflow and updating it deliberately through a dedicated PR with full testing, we avoided surprise breakages.

The analyze-and-test job runs on ubuntu-latest because it doesn’t need platform-specific tooling. Flutter’s analyzer and test runner work identically on Linux, and Linux runners are cheap and fast. This job is our first quality gate — if static analysis finds issues or tests fail, neither platform build even starts. The --no-pub flag on flutter analyze skips redundant dependency resolution since we already ran flutter pub get.

The coverage check uses lcov to parse the coverage report and enforce our 80% line coverage threshold. If coverage drops below 80%, the build fails with a clear error message. This threshold was not arbitrary — Linh and I analyzed our codebase and determined that 80% was achievable for our business logic and widget tests while allowing reasonable exceptions for generated code and platform-specific integration points that are difficult to unit test.

The Android build decodes the keystore from a base64-encoded GitHub secret. This is a common pattern in mobile CI/CD: you take your binary keystore file, encode it as base64, store it as a secret, and decode it at build time. The key.properties file is generated dynamically from secrets so it never exists in the repository. The --build-number flag uses github.run_number to auto-increment build numbers — this ensures every build has a unique, monotonically increasing number that the app stores require. The --dart-define flag injects the API URL at compile time, which means the API endpoint is literally compiled into the binary rather than read from a config file at runtime. This is more secure for production builds.

The iOS build is where the complexity spikes. It runs on macos-latest because Xcode only runs on macOS. The code signing setup requires importing a distribution certificate (as a .p12 file, base64-encoded) and a provisioning profile (as a .mobileprovision file). The ExportOptions.plist file in our repository specifies the export method (app-store), the team ID, and the provisioning profile name. Getting this file right was a two-day debugging exercise for Linh — every field must match exactly, and the error messages when they don’t are spectacularly unhelpful.

The upload steps are the final stage. Android builds go to Google Play’s Internal Testing track via a service account JSON key. iOS builds go to TestFlight via App Store Connect API credentials (issuer ID, key ID, and private key). Both upload steps are idempotent — if they fail due to a network issue, re-running the workflow will retry the upload.

Code Signing Deep Dive

Code signing deserves its own section because it is, without exaggeration, the single most common source of CI/CD failures in mobile development. Linh spent more time debugging signing issues than any other part of the pipeline.

iOS signing is a nested hierarchy of trust. At the top is your Apple Developer account. Under that, you create certificates — specifically, a distribution certificate for App Store builds. The certificate has a private key that lives in your keychain (or in CI, gets imported from a secret). Under certificates, you have provisioning profiles, which link a certificate to a specific app ID and specify the distribution method (development, ad-hoc, or App Store). If any link in this chain is broken — expired certificate, mismatched bundle ID, wrong profile type — the build fails with errors that often don’t clearly indicate which link is broken.

We adopted Fastlane Match for certificate management. Match stores certificates and provisioning profiles in a private Git repository (encrypted), and the fastlane match appstore command fetches and installs whatever the build needs. This solved the “Linh’s machine has the certs but nobody else does” problem. With Match, any developer or CI runner can install the correct signing identity in a single command. The private repository is encrypted with a passphrase stored in GitHub secrets, so even if someone gains access to the repo, the certificates are useless without the decryption key.

Here’s the Matchfile configuration:

# Matchfile
git_url("https://github.com/kidspark/certificates.git")
storage_mode("git")

type("appstore")
app_identifier("com.kidspark.app")
team_id("XXXXXXXXXX")

readonly(true)  # CI should never create new certs

The readonly(true) setting is crucial for CI. You don’t want your CI pipeline accidentally creating new certificates — that should only happen through deliberate human action.

Android signing is simpler but equally critical. You generate a keystore once with keytool:

keytool -genkey -v -keystore kidspark.jks \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -alias kidspark -storepass $STORE_PASSWORD \
  -keypass $KEY_PASSWORD \
  -dname "CN=KidSpark, OU=Mobile, O=KidSpark Pty Ltd, L=Sydney, S=NSW, C=AU"

That keystore file is your app’s permanent identity on Google Play. We store the original in an encrypted vault (we use 1Password’s team vault), and the base64-encoded version lives in GitHub secrets. The key.properties file that Gradle reads is generated at build time from secrets and never committed to the repository. We added key.properties and *.jks to .gitignore on day one.

Secrets management follows a simple policy: secrets are stored in exactly two places — the encrypted team vault (1Password) and GitHub Actions encrypted secrets. They exist nowhere else. Not on Slack. Not in emails. Not in shared documents. Not in environment files committed to the repository. When Linh rotates a secret, she updates both locations in the same session and verifies the CI build passes immediately afterward.

Build Variants

KidSpark has three build variants, each with different configurations.

Development builds use debug mode with hot reload enabled, point to our development API server, include verbose logging for all network requests, state changes, and navigation events, and skip code signing entirely (iOS simulator builds don’t require it). These are what Linh and I use daily on our development machines and emulators.

Staging builds use release mode for performance-accurate testing, point to our staging API server (which mirrors production data structures but uses synthetic data), enable crash reporting via Firebase Crashlytics, include moderate logging for diagnostics, and use ad-hoc signing (iOS) so they can be installed on registered test devices. These are what our beta testers receive.

Production builds use release mode with full optimizations, point to the production API, enable crash reporting with minimal breadcrumb logging, strip all debug logging, use App Store distribution signing, and include source map uploads to our crash reporting service for symbolicated stack traces.

We manage the API URL and other environment-specific values using --dart-define flags:

# Development
flutter run --dart-define=API_URL=https://dev-api.kidspark.com \
            --dart-define=ENV=development

# Staging
flutter build apk --release \
  --dart-define=API_URL=https://staging-api.kidspark.com \
  --dart-define=ENV=staging

# Production
flutter build appbundle --release \
  --dart-define=API_URL=https://api.kidspark.com \
  --dart-define=ENV=production

In the Dart code, these values are accessed at compile time:

class AppConfig {
  static const String apiUrl = String.fromEnvironment(
    'API_URL',
    defaultValue: 'https://dev-api.kidspark.com',
  );

  static const String environment = String.fromEnvironment(
    'ENV',
    defaultValue: 'development',
  );

  static bool get isProduction => environment == 'production';
  static bool get isDevelopment => environment == 'development';
}

The defaultValue ensures that running flutter run without any --dart-define flags gives you the development configuration. This was Linh’s design decision and it’s a good one — the most common case (local development) requires zero configuration.

Automated Quality Gates

The CI/CD pipeline doesn’t just build code. It enforces standards. Every merge to main must pass through a series of quality gates that we deliberately designed to be strict — because the cost of catching a problem in CI is minutes, while the cost of catching it after an app store submission is days.

Test coverage: 80% minimum. Our coverage threshold is enforced by the pipeline, not by developer discipline. When the lcov summary reports line coverage below 80%, the build fails. Period. No overrides, no exceptions, no “I’ll add tests in the next PR.” We chose 80% because it’s high enough to catch most regression paths but low enough to avoid the pathological behavior of writing pointless tests to hit an arbitrary number. Our actual coverage hovers around 85-87% because the team takes pride in it, not because the threshold forces them there.

Static analysis: zero warnings. Flutter’s analyzer is configured with a strict analysis_options.yaml that enables most lint rules. We treat warnings as errors in CI — a single analyzer warning fails the build. This might sound draconian, but it’s saved us from real bugs. Linh caught a potential null dereference that would have crashed the app on older Android devices because the analyzer flagged a missing null check. Without the zero-warnings policy, that warning would have been one of many and nobody would have noticed it.

# analysis_options.yaml
include: package:flutter_lints/flutter.yaml

analyzer:
  errors:
    missing_return: error
    dead_code: warning
    unused_import: warning
  exclude:
    - "**/*.g.dart"
    - "**/*.freezed.dart"

linter:
  rules:
    prefer_const_constructors: true
    prefer_const_declarations: true
    avoid_print: true
    require_trailing_commas: true
    always_declare_return_types: true

Accessibility checks are automated using our custom test harness. Every screen widget test includes assertions that verify semantic labels exist for interactive elements. If a button doesn’t have a semanticsLabel or an Icon doesn’t have a semanticLabel, the test fails. For a kids app where some users may have learning disabilities, visual impairments, or motor challenges, accessibility isn’t optional — it’s core functionality.

testWidgets('lesson card has proper semantic labels', (tester) async {
  await tester.pumpWidget(
    MaterialApp(home: LessonCard(lesson: mockLesson)),
  );

  // Verify semantic labels for screen readers
  expect(
    find.bySemanticsLabel(RegExp('Math lesson')),
    findsOneWidget,
  );

  // Verify tap targets meet minimum size (48x48)
  final buttonSize = tester.getSize(find.byType(ElevatedButton));
  expect(buttonSize.width, greaterThanOrEqualTo(48));
  expect(buttonSize.height, greaterThanOrEqualTo(48));
});

Performance benchmarks catch regressions before they reach users. We run Flutter integration tests that measure app startup time and key screen transition times. If startup time exceeds 3 seconds on our benchmark configuration (a mid-range Android emulator), the build fails. If the lesson-to-quiz transition exceeds 300 milliseconds, the build fails. These thresholds were established by measuring baseline performance and adding a 20% buffer — tight enough to catch real regressions, loose enough to avoid flaky failures.

Bundle size monitoring tracks the size of our release artifacts. Android AAB files and iOS IPA files are measured after each build, and if they exceed our thresholds (50 MB for Android, 80 MB for iOS), the build emits a warning. We haven’t made this a hard failure yet — size tends to grow as we add content — but the visibility has already caught two instances where an accidentally included debug asset inflated the bundle by 15 MB.

Dependency vulnerability scanning runs flutter pub audit as part of the pipeline to check for known vulnerabilities in our dependency tree. Dart’s pub audit isn’t as mature as npm audit, but it catches the critical ones. We supplement it with Dependabot alerts on GitHub, which monitors our pubspec.lock for packages with published CVEs.

If any of these gates fails, the build stops. No artifact is produced. No upload happens. The developer who pushed the code gets a clear notification explaining exactly which gate failed and why. This strictness was controversial when Linh first implemented it — Toan argued that it slowed down iteration speed. But after the third time a quality gate caught a bug that would have been embarrassing in production, he stopped complaining.

Beta Testing Distribution

Before any KidSpark build reaches the public App Store or Google Play, it goes through our beta testing program. We run three tester groups with different cadences and purposes, distributed through different channels depending on the platform.

TestFlight for iOS

Apple’s TestFlight is the standard for iOS beta distribution, and for good reason — it’s tightly integrated with App Store Connect, handles provisioning automatically for testers, and provides a clean feedback mechanism.

Our TestFlight setup has two tester groups. Internal testers are the four of us on the KidSpark team plus two QA contractors. Internal testing builds are available immediately after upload — no review required. This is our daily build channel. Every merge to main produces a TestFlight build that internal testers can install within minutes.

External testers are our beta group of 45 parents and 12 teachers who volunteered through our web platform’s community. External TestFlight builds require a brief Apple review — usually 24-48 hours, though we’ve seen it take up to four days during busy periods. We push external builds weekly, typically on Wednesdays, which gives us Monday and Tuesday to stabilize after any weekend code merges.

TestFlight has a 90-day expiry on builds. This is a hard limit imposed by Apple — after 90 days, the beta build stops working and testers must update. We set a calendar reminder at the 75-day mark to ensure we always have a fresh build available. Letting a beta build expire and leaving testers with a non-functional app is a fast way to lose volunteer testers.

The feedback mechanism in TestFlight is surprisingly useful. Testers can take screenshots within the app, annotate them, and submit feedback directly to App Store Connect. Hana reviews every piece of TestFlight feedback personally. She’s identified three UX issues from parent testers that we never caught internally — including a parental gate flow that was confusing on iPad because the button layout shifted in landscape mode.

Google Play Testing Tracks

Google Play offers a more nuanced testing distribution system than TestFlight, with three tracks that serve different purposes.

Internal testing is the fastest path. Builds uploaded to the internal track are available to internal testers immediately — no review, no delay. We use this for daily builds, same as TestFlight internal. The internal track supports up to 100 testers, which is more than enough for our team.

Closed testing is our external beta channel. It requires a brief Google review (usually under a few hours, much faster than Apple’s external TestFlight review), and we can organize testers into named groups. We have a “Parents Beta” group and a “Teachers Beta” group, each receiving the same builds but allowing us to segment feedback.

Open testing is something we haven’t used yet but plan to for our public beta before full launch. Open testing makes the app available to anyone who follows a link — no invitation required. Google reviews open testing builds, and the turnaround is typically 24-48 hours. This is ideal for gathering wider feedback before the public launch.

We also evaluated Firebase App Distribution as an alternative, especially for early development when our app store accounts weren’t set up yet. Firebase App Distribution is platform-agnostic — it can distribute both Android APKs and iOS IPAs — and the setup is simpler than configuring app store testing tracks. The tradeoff is that it’s less polished than TestFlight or Google Play testing, and it doesn’t provide the same feedback tools. We used it for the first two months of development and then migrated to the native platform tools.

Managing Tester Groups

Our beta testing cadence is deliberate:

Internal team (4 people + 2 QA): daily builds, every merge to main
Parent testers (45 people): weekly builds, Wednesday releases, accompanied by a brief changelog email
Teacher testers (12 people): bi-weekly builds, aligned with our sprint cycle, with a more detailed release note that includes instructions for new features to evaluate

Toan manages the relationship with external testers like a community manager — which, for a small team, is exactly what a PM should be doing during beta. He sends personal follow-up emails when testers provide feedback, thanks them in our release notes, and occasionally ships them KidSpark-branded stickers. It sounds trivial, but our tester retention over six months was 89%, which is exceptional for a volunteer beta program. People stay engaged when they feel heard.

Apple App Store Submission

The first time we submitted KidSpark to the Apple App Store, I naively assumed the process would take a couple of days. Set up the listing, upload the build, wait for review, go live. Toan, who had submitted apps before, looked at me with the expression of a veteran trying not to laugh at a recruit who just asked if boot camp would be easy.

“It’ll take three weeks,” he said. “Minimum. And that’s if nothing gets rejected.”

He was almost exactly right. It took 19 days from our first submission attempt to the app going live. Here’s everything we navigated.

App Store Connect Setup

Creating the app record is the first step. You need your bundle ID (com.kidspark.app), a SKU (we used kidspark-ios-001), and your primary language. The bundle ID must match what’s in your Xcode project exactly — a mismatch here means your uploaded build won’t associate with your app record.

Screenshots are required in specific sizes and aspect ratios, and Apple is strict about this. For iPhone, you need screenshots for 6.7-inch (iPhone 15 Pro Max class), 6.5-inch (iPhone 11 Pro Max class), and 5.5-inch (iPhone 8 Plus class) displays. For iPad, you need 12.9-inch (iPad Pro) and 11-inch formats. Each size requires between 1 and 10 screenshots. Hana designed our screenshots to tell a story: the first shows the child’s home screen, the second shows an active lesson, the third shows the celebration animation after completing a quiz, the fourth shows the parent dashboard, and the fifth shows offline mode in action. We used a tool called Fastlane Snapshot combined with manual touch-ups in Figma to produce all required sizes from a single set of base designs.

App Preview videos are optional but we created one anyway. For a kids app, video is powerful — parents want to see what their child will experience before installing. Our preview is 27 seconds: a child navigating to a math lesson, answering a question correctly, seeing the celebration animation, and then the camera pulling back to show the parent dashboard with the progress chart updating. Hana directed it. Linh made sure the screen recording was 60fps with no dropped frames. It took us two full days to produce 27 seconds of video. Worth every minute.

Privacy Nutrition Labels require you to declare every piece of data your app collects, stores, or shares. Apple introduced these labels to give users transparency, and they audit them during review. For KidSpark, we declare: usage data (which lessons are completed, which quiz answers are given), diagnostics (crash logs, performance metrics), and contact info (parent email for account creation). We explicitly do not collect any data from children — all personal information is associated with the parent account. Our privacy label declarations took three revisions to get right, because Apple’s categories don’t always map cleanly to what your app actually does.

The age rating questionnaire uses the IARC (International Age Rating Coalition) system. You answer questions about your app’s content — violence, sexual content, gambling, substance use, user-generated content, and more. KidSpark scored the lowest possible rating: 4+. But here’s the critical part for kids apps: you must also select the Kids Category and specify an age band (5 and Under, 6-8, or 9-11). We selected 6-8 as our primary band. Selecting a Kids Category triggers additional review scrutiny and additional rules about what your app can and cannot do — third-party SDKs, external links, data collection practices, and advertising are all more restricted.

The Review Process

Apple’s app review for kids apps is a different experience than for general apps. General apps typically receive a review decision within 24-48 hours. Our kids app submissions averaged 4-5 days, and our longest was 7 days. Apple assigns kids apps to specialized reviewers who are trained to evaluate compliance with the Kids Category guidelines, which are a superset of the general App Store Review Guidelines.

Our first submission was rejected. The reason: we had integrated Firebase Analytics, and the Firebase SDK was transmitting device identifiers that Apple classified as tracking. For a kids app in the Kids Category, any form of tracking requires explicit disclosure and must comply with Apple’s enhanced privacy requirements for children. The rejection was specific and fair: “Your app includes SDKs that collect data from users in ways that are not consistent with the Kids Category requirements.”

Linh spent a day configuring Firebase to disable analytics collection for child profiles and only enable it for parent-facing screens. We resubmitted with detailed reviewer notes explaining the change. That submission was approved.

Common rejection reasons specific to kids apps, based on our experience and conversations with other kids app developers:

Third-party SDK detected that isn’t kids-safe. This is the most common one. Ad SDKs, analytics SDKs, and social media SDKs often collect device identifiers or behavioral data that violates kids’ privacy rules. Audit every SDK in your dependency tree. Run flutter pub deps and check each package. If an SDK collects any data, you need to verify it’s compliant with COPPA and Apple’s Kids Category rules.
External links without parental gates. If your app has any link that opens Safari or any other app, it must be behind a parental gate. This includes “Visit our website” links, “Contact support” links, and even “Rate this app” prompts. Our parental gate uses a math problem (like “What is 7 times 4?”) that a child is unlikely to solve. Apple has seen every parental gate design, so don’t try to be clever — just be effective.
Missing or inaccurate privacy labels. If your privacy label says “no data collected” but your crash reporting SDK transmits device information, Apple will catch it. They audit the actual network traffic from your app during review.
In-app purchases accessible without parental verification. If a child can stumble into a purchase flow without a parent intervening, that’s a rejection. Our subscription is only accessible from the parent dashboard, which requires parental authentication to access.
Login wall before value demonstration. Apple’s guidelines require that apps provide some value before requiring account creation. For KidSpark, we offer three free trial lessons that work without any account. The signup prompt appears after the third lesson, when the parent has seen enough to make an informed decision.

Pro Tips for Apple Submission

Based on our experience, here’s what I’d tell anyone submitting a kids app to the App Store:

Submit on Tuesday or Wednesday. Apple’s review team works weekdays, and submissions made on Friday often sit until Monday. Submitting early in the week maximizes the chance of a quick turnaround and gives you weekdays to respond if there’s a rejection.

Write detailed reviewer notes. The “Notes for Review” field in App Store Connect is your chance to communicate directly with the reviewer. We include: a demo parent account (email and password), step-by-step instructions for reaching the parental gate, an explanation of how we handle child data, and screenshots annotated with arrows showing where parental controls live. Reviewer notes don’t affect the public listing — they’re only visible to Apple’s review team.

Provide a demo account. For any app that requires sign-in, this is essential. Our demo account has pre-populated child profiles with lesson progress, so the reviewer can see both the child experience and the parent dashboard without going through the full onboarding flow.

Screenshot your parental gates. Take screenshots of every parental gate in your app — the math problem gate, the settings access gate, the purchase flow gate — and include them in your reviewer notes with captions. Make the reviewer’s job easy, and they’ll make your life easy.

Google Play Submission

Google Play’s submission process is different from Apple’s in ways both obvious and subtle. The obvious difference is that Google Play reviews are generally faster and less opinionated about design decisions. The subtle difference is that Google Play’s requirements for kids apps, through the Families Policy, are equally strict as Apple’s — they just enforce them differently.

Google Play Console Setup

The app listing requires a title (up to 30 characters), a short description (up to 80 characters), a full description (up to 4,000 characters), and a feature graphic (1024x500 pixels). The feature graphic is prominently displayed on your store listing and in search results — it’s prime real estate. Hana designed ours to show a child’s hand holding a phone with KidSpark on screen, with colorful learning icons floating around it. Bright, friendly, and instantly communicative about what the app does.

The content rating questionnaire is similar to Apple’s IARC system but administered through Google’s own interface. You answer questions about content categories and receive a rating. KidSpark received an “Everyone” rating, which is the equivalent of Apple’s 4+ rating.

The Target Audience and Content declaration is where Google Play gets serious about kids apps. You must declare your app’s target age group, and if that includes children under 13, your app is subject to Google’s Families Policy. This is not optional — if Google determines that your app targets children (based on the app’s content, marketing, and user behavior, regardless of what you declare), they’ll apply the Families Policy anyway. We declared our target audience as ages 6-12 and opted into the Families Program.

The Families Policy declaration requires attestation that your app complies with all requirements: no behavioral advertising, no third-party SDKs that aren’t certified for use with children, a visible and accessible privacy policy, compliance with COPPA, and content appropriate for children. Google maintains a list of certified ad SDKs and analytics SDKs that are approved for use in Families apps. If your app uses an SDK that isn’t on that list, it will be rejected.

The Data Safety section is Google’s equivalent of Apple’s Privacy Nutrition Labels, and it’s equally important to get right. You must declare all data collected (account info, device identifiers, app activity), whether data is shared with third parties, whether data is encrypted in transit, whether users can request data deletion, and whether your app follows Google’s Families Policy for data practices. Inaccuracies in the Data Safety section are a common rejection reason, and Google cross-references your declarations against the actual behavior of your app.

Teacher Approved Badge

Google Play offers a Teacher Approved badge for educational apps that pass an additional review by a panel of education experts and child development specialists. The badge is optional but extremely valuable for discoverability — apps with the Teacher Approved badge appear in a dedicated section of Google Play and receive a visible trust signal on their listing.

Applying for Teacher Approved requires submitting additional materials: a description of your app’s educational methodology, evidence of curriculum alignment, information about the credentials of your content creators, and a demonstration of how the app adapts to different learning levels. Hana prepared our submission, drawing on her teaching background to articulate KidSpark’s pedagogical approach in terms that education reviewers would recognize and respect.

The initial review took about three weeks. We received feedback requesting more detail about our adaptive difficulty algorithm — specifically, how it determines a child’s zone of proximal development and adjusts content accordingly. Linh wrote a technical explanation, Hana translated it into educational terminology, and we resubmitted. The badge was approved two weeks later.

The impact was measurable: in the first month after receiving the Teacher Approved badge, our organic search impressions increased by 34%. Parents searching for educational apps see the badge and it signals “this app was vetted by teachers,” which is a powerful trust indicator.

Common Google Play Issues

Data Safety section inaccuracies are the single most common rejection we’ve seen reported in developer forums. Google’s automated systems analyze your app’s network traffic and compare it against your Data Safety declarations. If your app transmits data you didn’t declare — even if it’s a third-party SDK doing it without your explicit knowledge — your submission will be flagged. The solution is to audit your dependency tree ruthlessly. Run your app through a network proxy like Charles or mitmproxy and catalog every outbound request. Then map each request to a Data Safety category.

Families Policy non-compliance typically manifests as issues with third-party SDKs. Google’s certified SDK list is more restrictive than you’d expect. Some popular analytics and crash reporting SDKs are not certified for Families apps. We had to verify that every dependency in our pubspec.yaml — and every transitive dependency — was either on Google’s certified list or did not collect any user data.

Missing privacy policy sounds basic, but your privacy policy must be accessible both from within the app and from a URL linked in your Google Play listing. The URL must be active and the policy must be current. We host ours at https://kidspark.com/privacy and link to it from the app’s settings screen and from the Play Store listing.

Content rating mismatch occurs when Google’s reviewers determine that your app’s content doesn’t match the rating you claimed. For a kids app, this could be triggered by something as subtle as a third-party web view that could potentially display inappropriate content. We avoided this by ensuring that KidSpark never opens external web content — everything is rendered natively within the app.

App Store Optimization (ASO)

Getting approved on both app stores is only half the battle. The other half is making sure parents can actually find your app. App Store Optimization is the discipline of maximizing your app’s visibility in store search results, and for a kids app, it’s the primary channel for organic user acquisition.

Keyword Research

Keyword research for a kids educational app starts with understanding how parents search. They don’t search for “adaptive learning platform with spaced repetition algorithms.” They search for “math app for kids,” “reading practice for 6 year olds,” “learning games for kindergarten.” The language is simple, specific, and problem-oriented.

We used a combination of tools — App Annie (now data.ai), Sensor Tower, and manual store searches — to identify our primary keywords. The high-value keywords in our category include “kids learning app,” “math for kids,” “reading for kids,” “educational games,” and “learning app for children.” Competition for these keywords is fierce — ABCmouse, Khan Academy Kids, and Duolingo ABC dominate the top positions. Our strategy was to target long-tail keywords where we could realistically rank: “offline learning app for kids,” “adaptive math for 6 year olds,” “kids education app with parent dashboard.”

Title and Subtitle Optimization

On iOS, the app title supports up to 30 characters and the subtitle supports an additional 30 characters. Every character matters. Our title is “KidSpark: Kids Learning App” — it includes our brand name and our primary keyword. Our subtitle is “Math, Reading & Science for Ages 4-12” — it communicates the breadth of content and the target age range, both of which are common search qualifiers.

On Google Play, the title supports 30 characters and the short description supports 80 characters. Our Play Store title matches iOS for brand consistency. Our short description is “Adaptive math, reading & science lessons for kids 4-12. Works offline. Parent dashboard included.” — we pack the maximum amount of relevant information into 80 characters: the adaptive nature (our differentiator), the subject areas, the age range, offline capability, and the parent dashboard.

Description Optimization

The full description on both stores is up to 4,000 characters, but the first 1-3 lines are the most important because they’re visible without tapping “Read More.” Our opening line is: “KidSpark makes learning fun with adaptive lessons that grow with your child.” This communicates the value proposition immediately.

The rest of the description follows a pattern: feature bullets (scannable), a brief explanation of the adaptive learning engine (our differentiator), a list of curriculum areas covered, a mention of offline support, a description of the parent dashboard, and a closing line about privacy and safety. We naturally include keywords throughout — not stuffed awkwardly, but woven into descriptions of actual features. “Your child can practice math offline during car rides” includes both “math” and “offline” as keywords while describing a real use case.

Screenshot Strategy

Screenshots are your app’s storefront. Most parents decide whether to install based on screenshots alone — they never read the description. Our screenshot strategy was designed by Hana with input from Toan’s market research.

Show the child experience first. The first three screenshots depict what a child sees: the colorful home screen with their avatar, an active math lesson with the adaptive difficulty indicator, and the celebration animation after a correct answer. These screenshots answer the parent’s first question: “Will my child enjoy this?”

Show the parent experience second. Screenshots four and five show the parent dashboard: a progress chart with clear labels (“Mia completed 14 math lessons this week, up from 9 last week”) and the screen time controls with the daily limit slider. These answer the parent’s second question: “Will I know if it’s working?”

Show the differentiator last. The final screenshot shows the offline mode indicator with the message “12 lessons downloaded and ready — no internet needed.” This answers the question that separates KidSpark from competitors: “Does this work when we don’t have Wi-Fi?”

Every screenshot includes a device frame and a short caption at the top. The captions are benefit-oriented, not feature-oriented: “Lessons that adapt to your child’s level” rather than “Adaptive difficulty algorithm.” Parents don’t care about algorithms. They care about whether their child will learn effectively.

On iOS, App Preview videos autoplay (muted) in the store listing. Our 27-second preview shows a continuous flow: child opens the app, selects a math lesson, answers a question, sees the celebration, and then the view transitions to the parent dashboard. No voiceover — just on-screen text captions and the app’s sound effects.

On Google Play, promo videos are YouTube links displayed at the top of the listing. We repurposed the same footage but extended it to 45 seconds with a brief intro card (“Meet KidSpark”) and an outro card with a call to action. YouTube promo videos have broader reach because they can be shared outside the store listing.

Localization

KidSpark launched in English but our store listings are localized for three key markets: English (Australia), English (United States), and Vietnamese. The Vietnamese localization of the store listing was completed by Toan, who is a native speaker and knows how Vietnamese parents discuss educational technology. This is important — machine translation of store listings produces grammatically correct but culturally tone-deaf results. “Adaptive learning” translates literally, but the way a Vietnamese parent thinks about educational technology differs from an Australian parent, and the listing should reflect that difference.

Google Play supports A/B testing of store listings through Store Listing Experiments. We ran an experiment testing two different feature graphics — one showing a child using the app, the other showing an abstract illustration of learning icons. The child photo outperformed the illustration by 23% in conversion rate. Real children using your app in a natural setting is more compelling than any designed graphic. Apple doesn’t offer equivalent A/B testing natively, but you can test different screenshots by submitting updates and monitoring conversion rates through App Store Connect analytics.

Review and Rating Management

We respond to every review, positive or negative. For positive reviews, a brief thank-you acknowledging their specific feedback. For negative reviews, a genuine response addressing their concern and, if applicable, mentioning that a fix is coming in the next update.

Negative reviews that mention bugs are prioritized in our sprint planning. A one-star review that says “app crashes when I open the parent dashboard on my Samsung A13” is actionable — we can reproduce it, fix it, respond to the review saying it’s been fixed, and the reviewer often updates their rating. We’ve turned six one-star reviews into four-star reviews through this process. It’s time-consuming, but each review affects your overall rating, and your overall rating affects your search ranking, which affects your install rate. The math justifies the effort.

Versioning and Release Strategy

Versioning sounds like a boring topic until you realize that a bad versioning strategy can prevent you from shipping urgent fixes, confuse your users, and break your CI/CD pipeline. Our approach was designed before we wrote the first line of pipeline code, because versioning decisions propagate everywhere.

Semantic Versioning

KidSpark follows semantic versioning: MAJOR.MINOR.PATCH.

MAJOR (the first number) increments for breaking changes that require user action — like a forced migration of offline data or a redesigned onboarding flow. We’re currently on major version 1 and don’t anticipate incrementing it soon.
MINOR (the second number) increments for new features — a new subject area, the gamification system, the teacher portal. These are the updates that justify a “What’s New” entry in the store listing.
PATCH (the third number) increments for bug fixes and performance improvements — crash fixes, layout corrections, accessibility improvements. Users don’t need to know the details; they just need to know we’re maintaining the app actively.

Build numbers are separate from version numbers and are auto-incremented by the CI/CD pipeline using github.run_number. Both app stores require build numbers to be monotonically increasing. The version number might stay at 1.2.0 across multiple builds while we’re iterating on the release candidate, but each build has a unique, increasing build number.

In pubspec.yaml:

version: 1.2.0+${BUILD_NUMBER}

The + syntax is Flutter’s convention for version+buildNumber. The CI pipeline substitutes the build number at build time using the --build-number flag.

Staged Rollouts

Both app stores support gradual rollouts, and we use them for every release.

Google Play staged rollouts let you release to a percentage of users and increase that percentage over time. Our standard rollout cadence is: 1% on day one, 10% on day two (if no spike in crash rate), 25% on day three, 50% on day four, and 100% on day five to seven. If at any point the crash rate for the new version exceeds 0.5% (compared to the previous version’s baseline), we halt the rollout and investigate. Google Play Console provides real-time crash rate comparisons between the rolling-out version and the previous version, which makes this decision data-driven rather than gut-driven.

Apple’s phased release works similarly but with less granular control. You can enable phased release, which distributes the update over 7 days in increasing percentages (1%, 2%, 5%, 10%, 20%, 50%, 100%). You can pause a phased release if issues emerge, but you can’t set custom percentages. We use phased release for every update and monitor Crashlytics during the rollout period.

Forced Updates

For critical security or compliance fixes, we have a forced update mechanism. The app checks a remote configuration endpoint at startup that returns the minimum supported version. If the installed version is below the minimum, the app displays a full-screen message explaining that an update is required, with a button that opens the appropriate app store page.

class VersionChecker {
  Future<bool> isUpdateRequired() async {
    final remoteConfig = await fetchRemoteConfig();
    final minimumVersion = Version.parse(remoteConfig.minimumAppVersion);
    final currentVersion = Version.parse(AppConfig.appVersion);

    return currentVersion < minimumVersion;
  }
}

We’ve used the forced update mechanism once — when we discovered a data synchronization bug that could cause a child’s progress to be overwritten. The fix was in version 1.1.3, so we set the minimum supported version to 1.1.3. Within 48 hours, 94% of users had updated. The remaining 6% updated within a week, prompted by the forced update screen the next time they opened the app.

Backward API Compatibility

Our backend API supports the current app version and N-1 (the previous minor version). This means when we release version 1.3.0, the API continues to support both 1.3.x and 1.2.x requests. When version 1.4.0 ships, we deprecate 1.2.x support. This gives users a reasonable window to update without their app suddenly breaking.

API versioning is implemented through request headers:

X-App-Version: 1.2.0
X-Platform: ios
X-Build-Number: 147

The backend reads these headers and routes requests to the appropriate handler version. Deprecated version requests receive a response header X-Update-Available: true that the app interprets as a soft nudge to update (showing a non-blocking banner rather than the forced update screen).

Feature Flags

For gradual feature rollout independent of app updates, we use Firebase Remote Config as a feature flag system. This lets us deploy code for a new feature in a release but keep it hidden behind a flag, then enable it for specific user segments or percentages without shipping a new build.

class FeatureFlags {
  static Future<bool> isGamificationEnabled() async {
    final remoteConfig = FirebaseRemoteConfig.instance;
    await remoteConfig.fetchAndActivate();
    return remoteConfig.getBool('gamification_enabled');
  }

  static Future<bool> isNewQuizUIEnabled() async {
    final remoteConfig = FirebaseRemoteConfig.instance;
    await remoteConfig.fetchAndActivate();
    return remoteConfig.getBool('new_quiz_ui_enabled');
  }
}

We used feature flags to roll out the gamification system to 10% of users first, monitored engagement metrics for two weeks, confirmed that badge collection increased session length by 18% without decreasing lesson completion rates, and then rolled it out to 100%. This approach decouples deployment from release — you can deploy code safely and activate it when you’re confident it works in the real world.

The Complete App Store Submission Checklist

After shipping KidSpark through both stores — and helping three other teams do the same — I’ve consolidated everything into a single checklist. This is the checklist Toan prints out and tapes to the wall before every major release. If you’re building a kids app, bookmark this section.

Technical Readiness

Apple App Store Specific

Google Play Specific

Content and Legal

Privacy policy is written in plain language, specifically addresses children’s data, includes contact information, and is versioned
Terms of service accessible from store listing and within the app (behind parental gate)
COPPA compliance verified — verifiable parental consent, data minimization, retention limits, parental access and control
GDPR-K compliance verified — consent for under-16 EU users, DPIA completed, right to erasure implemented, data portability available
Content is age-appropriate for declared age band — no violence, mature themes, or complex vocabulary outside the target range
All text reviewed for age-appropriateness — error messages, loading states, empty states, and system prompts
No external links accessible without parental gate — includes help, support, privacy policy (in-app), social media, and website links

Post-Submission

Monitor review status daily — respond to reviewer questions within 24 hours
If rejected, read the specific guideline cited, make the minimum required change, resubmit with detailed explanation in reviewer notes
After approval, verify the live listing looks correct — screenshots, descriptions, privacy labels all displaying as expected
Monitor crash rates during staged rollout — halt at 0.5% crash rate threshold
Respond to early reviews — especially negative ones, within 48 hours
Verify forced update mechanism works if a critical fix is needed post-launch

This checklist is long because the requirements are extensive. But every item exists because someone — us or a team we talked to — got burned by missing it. Print it out. Tape it to the wall. Check every box before you click “Submit for Review.”

The Bottom Line

Mobile CI/CD is more complex than web CI/CD. There’s no getting around that. Code signing, binary artifacts, platform-specific build tools, expensive macOS runners, and app store upload APIs add layers of complexity that don’t exist in web deployment. But here’s what I’ve learned: the complexity is front-loaded. The first two weeks of building the pipeline are painful. After that, the pipeline saves time every single day.

Before Linh built our pipeline, a release took four hours of manual work and was bottlenecked on a single person. After the pipeline, a release takes zero manual work — a merge to main triggers the entire flow automatically. Over six months, that’s roughly 200 hours of developer time saved. More importantly, it eliminated the bus factor risk. Any member of our team can ship a release by merging a PR. Nobody needs to remember which certificate goes where or which keystore password to use.

The app store submission process is its own skill — especially for kids apps where review scrutiny is higher and the rules are stricter. My advice: plan for rejection on your first submission. Not because your app is bad, but because the requirements for kids apps are genuinely nuanced and it’s nearly impossible to get everything right the first time. Read the guidelines thoroughly, but understand that some requirements only become clear when a reviewer points them out. Respond to rejections professionally, make the requested changes promptly, and provide detailed reviewer notes that demonstrate you take compliance seriously.

App Store Optimization is the discipline that turns a technically excellent app into a discoverable one. The best kids app in the world is worthless if parents can’t find it. Invest in keyword research, screenshot design, and review management with the same seriousness you invest in code quality.

And finally: versioning, staged rollouts, and feature flags are not optional infrastructure for a kids app. When your users include children and their parents, the cost of a bad release is not just a spike in crash rates — it’s a parent uninstalling your app and telling other parents to avoid it at school pickup. Roll out gradually, monitor aggressively, and always have a path to roll back.

In the next post, we’ll cover what happens after launch: production analytics, crash reporting, monitoring, and the iteration cycle that turns a launched product into a sustainable one. The pipeline we built here is the foundation for everything that follows.

This is Part 8 of a 10-part series: Building KidSpark — From Idea to App Store.

Series outline:

Why Mobile, Why Now — Market opportunity, team intro, and unique challenges of kids apps (Part 1)
Product Design & Features — Feature prioritization, user journeys, and MVP scope (Part 2)
UX for Children — Age-appropriate design, accessibility, and testing with kids (Part 3)
Tech Stack Selection — Flutter vs React Native vs Native, architecture decisions (Part 4)
Core Features — Lessons, quizzes, gamification, offline mode, parental controls (Part 5)
Child Safety & Compliance — COPPA, GDPR-K, and app store rules for kids (Part 6)
Testing Strategy — Unit, widget, integration, accessibility, and device testing (Part 7)
CI/CD & App Store — Build pipelines, code signing, submission, and ASO (this post)
Production — Analytics, crash reporting, monitoring, and iteration (Part 9)
Monetization & Growth — Ethical monetization, growth strategies, and lessons learned (Part 10)

Export for reading

Building KidSpark: CI/CD Pipeline and App Store Submission (Part 8 of 10)

Mobile CI/CD Is Not Web CI/CD

The KidSpark CI/CD Pipeline

The Complete GitHub Actions Workflow

Walking Through the Pipeline

Code Signing Deep Dive

Build Variants

Automated Quality Gates

Beta Testing Distribution

TestFlight for iOS

Google Play Testing Tracks

Managing Tester Groups

Apple App Store Submission

App Store Connect Setup

The Review Process

Pro Tips for Apple Submission

Google Play Submission

Google Play Console Setup

Teacher Approved Badge

Common Google Play Issues

App Store Optimization (ASO)

Keyword Research

Title and Subtitle Optimization

Description Optimization

Screenshot Strategy

App Preview and Promo Video

Localization

Review and Rating Management

Versioning and Release Strategy

Semantic Versioning

Staged Rollouts

Forced Updates

Backward API Compatibility

Feature Flags

The Complete App Store Submission Checklist

Technical Readiness

Apple App Store Specific

Google Play Specific

Content and Legal

Post-Submission

The Bottom Line

Comments

Building KidSpark: CI/CD Pipeline and App Store Submission (Part 8 of 10)