Bakeshot

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

https://github.com/user-attachments/assets/6a902e87-bb5d-467f-8c55-96d89f550ac3

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 git+https://github.com/Ryoheihoriuchi0000/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.

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

Everything above is free: every screen, every state, every language, every device size.

The version you paid for keeps working forever; renewing buys the next year of updates. Xcode breaks this kind of tool roughly once a year — that is what the renewal pays for.

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.)
• Screens that need network, keychain or a live account crash while rendering. 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.

License

MIT