Projects / Slipway github.com/a7t-ai/slipway

  • [autopilot]
  • [architect]

Slipway

A self-publishing toolkit for iOS apps.

I ship four iOS apps in my off-hours. Slipway is the toolkit that handles everything between "feature merged to main" and "TestFlight build delivered with App Store metadata staged". The next feature gets my time; the release ritual doesn't.

fastlane/Fastfile.delivery.rb 
1
2
3
4
5
6
7
8
9
10
11
12

lane :deliver_to_testflight do |options|
  scheme = options[:scheme] || ENV["APP_NAME"]
  groups = (options[:groups] || "").split(",").map(&:strip)
  notes  = options[:release_notes]

  build_app(scheme: scheme)
  upload_to_testflight(
    groups: groups,
    changelog: notes,
  )
end
# the only delivery flow I trust on a cron
Slipway

I ship four iOS apps in my off-hours:

  • FareHawk: calm fare alerts. Pay once, track forever.
  • Kinderuntersuchungsheft: the yellow German pediatric booklet, digital. Every U-Untersuchung and STIKO vaccination on your phone.
  • Einbürgerung Pro: the clean, modern way to prepare for the German citizenship test. All 310 questions, 11 translation languages, simulations, spaced repetition.
  • Reellette: AI-powered movie and TV recommendations to help you decide what to watch tonight.

Slipway exists because of FareHawk and Reellette. They were the first two, they grew their own release pipelines in parallel, and the pipelines ended up 85% the same and 15% specifically the thing the other one was missing. Merging them into one toolkit was less work than fixing the same bug twice every other Friday. The other two apps now run on the same template.

Slipway is not a binary or a service. It is a set of GitHub Actions workflows, Fastlane lanes, and helper scripts you copy into your iOS project. The work moves from your Friday afternoon onto a runner that already has your code, and it gives you the time back.

What it actually does

A slipway is the ramp that drops a boat into the water. The toolkit does the same for an iOS build: it takes whatever just landed on main, version-bumps it, builds and notarizes it, uploads the metadata and the screenshots, delivers to TestFlight, assigns to beta groups, and writes the release notes. From git merge to “build available” is one Monday-morning workflow firing, with no Xcode session in between.

The pipeline lives entirely in GitHub Actions for orchestration and cron, Fastlane lanes for the App Store Connect work and the build and notarize steps, and a handful of Bash and Ruby helpers for the small chores: icon generation, screenshot composition, release-notes interpolation.

The release lifecycle

Three orchestrator workflows drive one week. Tuesday early morning, a submission chain bumps the version, fills in App Store metadata, generates release notes, builds and notarizes, uploads to TestFlight, and submits for review. An hour later, a second workflow tags the just-submitted version and bumps the marketing number so the new week’s commits land on a fresh version. The version sits in Apple’s review queue for three to five days. Friday lunchtime, a third workflow finds the now-approved build and flips it to a phased release.

Drag the scrubber or hit play.

What’s worth stealing

The App Store screenshot compositor. The hardest part of an App Store release isn’t the binary. It’s that App Store Connect wants nine different screen sizes, each with marketing text overlaid in the right spot, each one matched to the right device frame. Slipway’s compositor takes a folder of UI snapshots (generated by your XCUITest target) and produces the full nine-up matrix per locale. If you ship localized metadata, this saves a day per release.

The release-notes lane reads CHANGES_IN_VERSION.md, pulls the bullets above the ### Default Release Notes header, hands them to the copywriting persona for polish, and uploads. If the top section is empty after a long week, the fallback pool below the header is sampled at random so the App Store entry never ships with empty notes.

The version bumper uses calver: YY.MM.PATCH. Slipway derives the tag from the date, the patch number from the number of releases this month, and writes it back into the .xcconfig so the build matches.

What’s deliberately out of scope

macOS, tvOS, watchOS. Slipway is the iOS pipeline. The same shape works for the others, but the lanes are different enough that I haven’t pulled them into the merge.

Crash reporting and analytics integration. Those are app-level concerns, not release-pipeline concerns.

Beta tester management. Slipway assigns to existing TestFlight groups; it doesn’t manage who’s in them.

Where it came from

FareHawk contributed the App Store metadata pipeline, the icon generator, and the screenshot compositor: the pieces that touch App Store Connect.

Reellette contributed the UI-snapshot generation, the CI unit-test pipeline, and the version-bump convention.

Both apps now run on Slipway. Slipway is what they would have been if I’d started them on the same day with the same template.

Try it

Repo: https://github.com/a7t-ai/slipway. The README walks through the secrets you need (App Store Connect API key, Match certificates, and so on) and the Fastlane lanes you can map onto your existing app.

What I’d do for you

If you have an iOS app where releasing still feels like a manual ritual (opening Xcode, archiving, uploading, switching to App Store Connect, pasting release notes), Slipway can take 90% of that off the plate in a focused session. The hardest part is usually convincing the Apple side (certificates, API keys, App Store Connect roles); the toolkit handles the rest.