CI/CD for Mobile and Native Apps

The plain-language idea

Everything in this track so far — build, test, gate, deploy — still applies to a mobile app. What's different is two extra steps that have no web equivalent:

• Code signing. A mobile build has to be cryptographically signed with a certificate and (on iOS) a provisioning profile before a device or store will run it. There's no web analogue to this — a website doesn't need a certificate to be served, a compiled app does to be installed.
• App store review as a deployment gate. Pushing a web deploy is instant and entirely under your control. Submitting to the App Store or Play Store hands control to a third party that can take anywhere from hours to days, and can reject a build for reasons that have nothing to do with whether your code works.

This isn't the track's focus — Praxis is a frontend/web platform — but knowing the shape of the difference is worth having for an interview.

See it in a real thing: a Fastlane lane

Fastlane is the tool most iOS/Android CI pipelines lean on to script the parts Xcode and Android Studio otherwise want a human clicking through. A Fastfile lane for a TestFlight beta looks like:

lane :beta do
  match(type: "appstore", readonly: true)   # pulls signing certs + provisioning
                                              # profiles from an encrypted, shared repo
  increment_build_number(xcodeproj: "App.xcodeproj")
  build_app(scheme: "App", export_method: "app-store")
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

A CI job then just calls bundle exec fastlane beta. match is doing the interesting part for this track: it's the mobile equivalent of a secrets manager, decrypting signing credentials from a private repo at build time instead of committing a .p12 certificate file into the app's own repository.

What people usually miss

Watch out

• "Continuous deployment" for mobile usually means TestFlight, not the App Store. Because store review is an uncontrollable, variable-length human gate, most mobile teams automate all the way to a beta/internal testing tier and keep the final store submission as a deliberate, manual step — that's continuous delivery, not deployment, even on a team that calls it "CD."
• Signing credentials are secrets, full stop. A leaked certificate or provisioning profile lets someone sign and distribute a build impersonating your app — treat it with exactly the access controls you'd give an API key, never a file committed to the app repo.
• A bad web deploy rolls back in seconds; a bad mobile release doesn't. Once a version is live in a store, it stays installed on users' devices until they update. Feature flags and staged/phased rollouts (releasing to 1% of users, then 10%, then 100%) matter even more here than on web, precisely because you can't take it back the way you can revert a container.

The genealogy: signing is a secrets problem wearing a certificate

Match's job — keeping a signing certificate encrypted and out of source control, decrypted only inside the CI job that needs it — is the exact same problem the secrets and environment variables lesson covers for API keys and tokens. The credential type changed; the discipline required to keep it out of a git history didn't.