Shipker | Mobile Deployment Automation

new project intake

Connect repo. Apply template. Ship to stores.

Private beta

Shipker turns a mobile repository into a repeatable release pipeline. It connects the repo and store accounts, creates signing material for new apps, then asks only for metadata and release details that cannot be inferred safely.

Template files

9

Fastlane + Actions

Store connects

2

Fetch app metadata

User signing prompts

0

New apps only

generated plan

repo: github.com/acme/mobile
stack: flutter
platforms: iOS + Android
stores: App Store Connect + Google Play Console
generated signing: iOS + Android
patch: 9 template files
runner:
  1. GitHub Actions macOS
  2. Azure macOS
  3. Local macc
next: open setup pull request

template application

Files Shipker will patch

.github/workflows/ci-ios.yml

Builds signed IPA artifacts and can upload to TestFlight.

.github/workflows/android-deploy.yml

Builds signed AAB artifacts and can upload to Google Play.

ios/fastlane/Fastfile

Runs iOS signing, archive, export, and TestFlight upload lanes.

ios/fastlane/Matchfile

Points fastlane match at the private signing repository.

ios/fastlane/Appfile

Reads the iOS bundle id and Apple team from environment secrets.

android/fastlane/Fastfile

Uploads AAB files to the requested Play Console track.

android/app/build.gradle.kts

Uses environment secrets for Android signing configuration.

ios/Runner/Info.plist

Keeps iOS app metadata compatible with automated builds.

ios/Runner.xcodeproj/project.pbxproj

Applies stable iOS project signing and bundle settings.

connect first

Store accounts

App Store Connect

iOS

API key with least-privilege app access

Apple Developer Team ID

iOS Bundle ID

App Store app selection

TestFlight upload target

Google Play Console

Android

Play Developer API access through an approved service account

Android package name

Release tracks

Draft/internal/beta/production target

Current Play release state

new apps first

No signing files to upload

For this beta Shipker starts with new App Store and Google Play apps. After the store accounts are connected, Shipker creates the iOS signing repo, Apple distribution certificate, provisioning profile, and Android upload key behind the scenes.

No manual signing-file upload step

No certificate or profile setup screen

Private signing values stay in encrypted repo or CI secrets

Existing app migrations will come later because Android and some Apple capability edge cases need a separate recovery flow.

release sequence

The first automation loop

01

Use the GitHub session and selected repository from sign-in.

02

Connect App Store Connect and Google Play Console where those platforms are enabled.

03

Detect stack, platforms, package identifiers, new app store targets, and existing CI files.

04

Create a setup branch that applies the deployment template safely.

05

Generate new-app signing material automatically for iOS and Android.

06

Prompt only for app metadata, release track, and compliance details that cannot be inferred safely.

07

Write generated signing values to GitHub Actions or encrypted signing storage.

08

Open a pull request with the generated deployment plan.

09

Run Android and iOS dry builds, then enable store uploads when green.

ios runner policy

Cloud first, local Mac fallback

01

GitHub Actions macOS

Default iOS build and signing runner

Customer repo can use hosted macOS minutes and normal App Store signing.

Queue time and hosted-minute cost can vary by plan.

02

Azure macOS

Secondary cloud macOS runner

GitHub macOS limits, pricing, or availability block the release.

Needs separate pool setup and careful secret mirroring.

03

Local macc

Controlled fallback for iOS signing

Cloud macOS cannot access signing safely or a customer needs hands-on runner debugging.

Must be isolated, monitored, and treated as a privileged signing machine.