How it works
Four steps, and you write code in none of them.
A visual tool that makes you drop into a scripting language for the interesting half has not saved you anything — it has moved the work. So there is no scripting language here at all. What there is instead is about forty verbs, an ordered list of them per event, and three ways of looking at that one list.
Drag controls onto an iPhone on the canvas. The canvas is the layout the real device draws, at any of thirteen iPhone sizes — and a Sizes check answers the one question a phone asks that a Mac never does: does this still fit on the small one?
Pull a cable out of an event and drop it: a catalogue opens where you dropped it, with the likely steps for that event on top. Or type a sentence — “save the contact, buzz, close the sheet” — and it becomes cards.
One click puts it on a Simulator or a cabled iPhone. Then Live: every edit you make lands in your hand within a second or two, and you stay on the screen you were on, with the half-filled form still half-filled.
A standalone Xcode project: SwiftUI views, methods, structs, a README that describes every flow in sentences. No Neuridion code travels with it. This is the way out, and it is meant to be used.
One meaning, three views
The same flow, drawn, listed and read out.
Add a step on the board and the sentence under the card changes. Change the sentence's subject in the list and the cable on the board moves. There is no synchronising to do, because there is only one thing there.
The object on the left with one pin per event, the steps running to the right as nodes, thick grey cables for “then” and thin green ones for a value. Drop a cable on empty ground and the catalogue opens there.
Each step as a card in its family's colour, with the gaps it still has as rows you fill in — and, after Try, what it actually did when the flow was run.
“Save what is on the screen into Contacts, then go back.” Read-only, generated from the steps, in the flow's own words — under each card, in the step trace on the phone, and in the exported README.
Where the data comes from
Drop a file in. That is the whole import.
Every table in a demo starts as five short rows somebody typed in. Real data is already in a spreadsheet on the other screen — so drop it into the Data window and it becomes a table, with its column types guessed, shown, and changeable before anything happens.
The separator is worked out and quotes are honoured — so one comma inside “Meier, Hans GmbH” does not silently shift every column after it.
Every sheet, and dates read as dates — a workbook is a zip of XML, and the only place that says the number 46,000 in a cell is a day is the styles part.
Every table and every view, with the types the schema declares. Read-only, and there is deliberately nowhere to type SQL.
The first array of objects, wherever it sits. Column names may be dot paths, so nested data needs no reshaping.
The loop you actually spend the day in
Live: the app changes while you design it.
A run used to be an act — click, copy, relaunch, look, find your way back to where you were. Half a minute and a decision, so most changes were never seen on real hardware at all. That is the wrong shape for a program whose whole claim is that the design is the app.
Go Live and every edit is written into the folder the phone is already reading, and the phone is told to read it again. No reinstall. No relaunch. And you stay where you are — the screen you were on, the sheet that was up, the row you had picked, the note you were half way through typing.
