Bakeshot

Capture the same UI your users see — without a simulator or a device.

bakeshot.vercel.app · 日本語

Without Bakeshot

Getting the screens you want means installing the app, opening the right screen, getting it into the right state, placing the widget, configuring it, getting real data into it — and only then taking the shot.

And you do all of it again next release.

With Bakeshot

You describe the state in code; Bakeshot builds your app, runs it on your Mac as a real iOS binary, and draws the view.

shotBoth("home") { HomeView().environmentObject(thirtyDaysOfHistory()) }
shot("paywall", dark: true) { PlusSheet().environmentObject(PlusStore(active: true)) }

Nothing is simulated or mocked up: these are your real views, your real fonts and assets, rendered by iOS. The app never has to reach the state — the state is handed to it.

It does not decorate. Backgrounds, captions and device frames are somebody else's job (try app-store-screenshots). Bakeshot does the part nobody has automated: the real UI, in the state that sells it.

Use it

pip install bakeshot
cd MyApp
bakeshot init

Then tell your coding agent:

Bakeshot を使って App Store Connect 用のプロモーション画像を作成して — or, in English, "use Bakeshot to create the promotional images for App Store Connect"

init installs a skill into .claude/skills/bakeshot/, so the agent reads your models and views, writes the scene script, runs the render, fixes whatever crashed, and tells you where the images are. You do not have to learn the flags, or the file, or any of this README.

PNGs land in Bakeshot/out/<locale>/, at real store dimensions. Every language is baked in a single Xcode run — the build happens once, not once per language.

The scene script

Bakeshot/Scenes.swift is where you say what to shoot and in what state. It is plain Swift against your own types, which is why an agent can write it:

enum BakeshotScenes {
    @MainActor static var scenes: [BakeshotScene] {
        [
            shotBoth("home_busy") { HomeView().environmentObject(busyStore()) },
            shot("paywall", dark: true) { PlusSheet().environmentObject(PlusStore()) },
            shotBoth("widget", size: .widgetMedium) { MyWidgetView(entry: demoEntry()) },
        ].flatMap { $0 }
    }
}

@MainActor private func busyStore() -> AppStore {
    let s = AppStore()
    s.tags = [Tag(name: "Study"), Tag(name: "Workout"), Tag(name: "Work")]
    s.logs = (0..<20).map { LogEntry(minutes: 30 + $0 * 5) }
    return s
}

An empty app makes a worthless screenshot. The state is the product.

Does it touch my project?

No. Bakeshot never edits your files, your .xcodeproj, or your git history.

To render your views it needs one test target hosted by your app. Rather than add that to your project, it works on a hidden throwaway copy of the .xcodeproj, and deletes it when the run ends — including when the run fails. Nothing is left behind.

Requirements

• Apple silicon Mac with Xcode
• gem install --user-install xcodeproj
• Your app must be signable with your own team — the setup you already build with

bakeshot init checks all of this and tells you what is missing.

Price

Free, all of it. Every screen, every state, every language, every device size, widgets included. MIT.

Known limits

• Xcode is driven while baking, so you cannot use Xcode during a run. (xcodebuild test cannot launch an iOS-on-Mac test host; the IDE can.)
• A view crashes while rendering if something it demands is missing — nearly always an environment object, occasionally a force-unwrapped value that isn't there offline. Bakeshot reports the reason and carries on with the rest. Network calls do not crash a render; they simply don't finish, so the screen comes out in its loading state. Bakeshot names them and bakes the rest — give them fakes in the scene script.
• Widget sources are compiled into the test bundle, so a widget that depends on the extension's own asset catalog may render without those images.

Your data

The throwaway copy is built without the app's entitlements. That is deliberate: with them in place the copy opens the real App Group, and a scene script that happens to run a save or a sync path would write your live data — and, if the app syncs, push it to your other devices. Screenshots do not need the real store; the scene hands the views their state instead.

If an app truly cannot launch without its entitlements, --keep-entitlements puts them back. Do that only when the scene script touches nothing that persists.

License

MIT