Granite

Everything Granite-specific an iOS + macOS app needs, written from compact lines and shipped as a Granite agent package: a new Xcode project, Granite brought into an existing one, a kit of services, a service in the single-writer shape with its tests, a page laid out from what it shows and does, the app's navigation, and its modals. One call makes one of them and answers the files it wrote.

It is one of the Rao Craft Agents: independent packages that, tagged in prompts along the life of a project, build an app of Loom's quality. granite is the one every app starts from: models writes its value types, network its API clients, design and loom its look, platform its menus and entitlements, localize its languages.

How an app finds it

GraniteAgent is a GraniteAgentPackage (the type is GraniteAppAgent, since GraniteAgents already has a GraniteAgent), and it carries a record in its binary:

@used @section("__DATA_CONST,__granite")
let graniteRecord: GraniteRoster.Record = { GraniteRoster.record(GraniteAppAgent.self) }

In Craft, install it from the Agent Store or with craft agents add https://github.com/Rao-Craft-Agents/GraniteAgent.git, then say $granite in a request:

$granite start a recipe app, then a service that keeps the recipes (loaded a page at a time, kept between
launches) and a list page of them with pull to refresh and a favourite in each row's menu

The model writes one call per step; each shows on Craft's agent map as granite-1, granite-2…, and the files they name are built and tested with the turn. Calls run one at a time (lanes 1): several makes edit the project file and the root that holds the relays.

What a call takes and answers

The answer is a GraniteResult: every file written or edited (path, paths, absolute, the project file and the root included), the types written, and a sentence for each decision.

The lines

load(page Int) -> posts = LemmyAPI.posts(page: page) "loads one page"     an event: -> replaces a field
more(page Int) +> posts = LemmyAPI.posts(page: page)                       +> appends a page to a list
refresh() -> posts "the first page, newest first"                          no `= call`: the model writes it

items = feed.state.posts                  shows: a role (items, item, selection, query, sidebar, title, empty)
"Appearance/Theme" = config.state.appearance        or a row of a form, its control chosen by the field's type
refresh = try await feed.load(page: 1)    actions: refresh, more, open, submit and search do what they say
favor(post Post) "Favorite" star = …       an action on an item is in its row's menu and swipe; others are toolbar buttons
row(post Post, vote (Bool) -> Void) "title, author and score, with a vote"     views: a closure is filled by the action of its name
feed: Feed "Feed" house | PostDetail       destinations: the detail after a bar shows beside it in the split style

A line it cannot read, a field that does not exist, a relay that would loop, a page the project does not have: the call is refused with every reason at once, and nothing is written.

How the output is made

Everything is made from the lines. The host's model is asked only for what is the app's own: the body of work no = call says how to do, a subview's body its line describes, a blank page. Each answer is checked, parsed with swiftc -parse in its file, and asked again with what was wrong; its examples come from another app. Every file is staged and parsed, and the project file read by plutil, before any lands.

In Craft

An app that uses Swift packages, as every Granite app does, builds only by a scheme: xcodebuild with no scheme cannot resolve a package product. Craft's checks build an Xcode project with xcodebuild build unless the project says otherwise, so give Craft the project's own command in its settings for the project (or for one run with CRAFT_CONFIG_OVERLAY):

{"build": {"command": "xcodebuild -scheme Hearth-macOS -destination platform=macOS build",
           "testCommand": "xcodebuild -scheme Hearth-macOS -destination platform=macOS test"}}

With no team, the Mac app is signed to run locally (ad hoc) and is the project's first target, so it builds and runs on this Mac before a team is chosen. The UI tests are in the schemes but skipped until turned on, since they need an interactive session to drive the app.

Testing

swift test                     # the record, the schema, the lines, every make's files, the project file's edits
GRANITE_BUILD=1 swift test     # a recipe app made call by call, built and tested on macOS, built for the iOS
                               # simulator, its kit tested; a fresh Xcode project linked, built and tested

MIT licensed.