Manual · The book

Interpreted and compiled at once — the three compilers you never run, and the measured numbers.

“Nothing is compiled” — which is half true, and the whole truth is better

Press Build and there is no compile step: a finished application is a precompiled shell — the same binary for everyone, built and signed by us once — with your project beside it as an encrypted payload. Building copies, encrypts and signs; seconds, not minutes. And a bug we fix in the runtime is fixed in every application you rebuild afterwards.

But nothing of yours runs interpreted where it matters, either. Three compilers work for you at run time — you just never sit in front of any of them:

1 · Your scripts: JavaScriptCore compiles the hot code

Scripts run in JavaScriptCore — the engine inside Safari. It starts interpreting, watches which code is actually hot, and compiles that to native machine instructions while your application runs. Measured by the shipped Benchmark project on an ordinary Apple-silicon Mac:

• The first pass through fresh code: 2.3 million operations per second — 800 separate functions, each called once.
• Code that runs often — the same work, the loop kept warm: 48 million operations per second.

21× faster, and nobody did anything. That is the honest answer to “is it interpreted?”: it starts interpreted and stops being interpreted where it matters. The rule that fires once on a button click is in the first row and nobody can tell; the loop over four thousand invoice lines is in the second. Reading a property runs at ~74 million a second, calling one of your own functions at ~68 million — your helpers cost nothing worth measuring. (This is also why every built application carries the allow-jit entitlement.)

2 · The bridge: built once, crossed a million times a second

The expensive place in every scripting product is the border between the language and the data. Neuridion builds the record prototypes once, allocates records in Swift, and never calls back into JavaScript to hand one out. Measured: ~1,036,000 field reads and ~851,000 field writes per second across the bridge — the number that decides whether a fully synchronous API can work at all. It can: your script reads top to bottom, and the answer is on the next line.

3 · Your queries: compiled to SQL, run by SQLite

A query chain is not a loop over records — it compiles to one SQL statement, and SQLite's planner (with your indexes) does what forty years of database engineering are for. count(), sums, grouping for charts, the list's footer: computed in the database, no rows travel. A relationship stays a query until something treats it as a list. Money is integer cents end to end, so totals are exact and fast.

What that adds up to — measured

• ~18,000 rows per second written through the session — the stress-test project inserts 790,000 rows in 44 s.
• A project with 160 tables and a million rows opens in the IDE in 0.11 s; its built application is 12 MB and cold-launches in under 2 s.
• A list over 300 records carrying 5-MB scans reads in 0.002 s, encrypted — documents stay on disk until somebody actually asks.
• Client/Server on the wire (localhost): ping 0.09 ms, one record 0.13 ms, a 500-row list in one trip 5.8 ms, create-and-save 0.17 ms. The API batches — a list is one trip, never five hundred.

Measure it yourself

The shipped Benchmark project produced every number above: each measurement three times, the median kept (the honest small print: the first pass through a loop is the slow one, so timing cold against warm measures nothing), history outside the project, and a window that answers the only question that matters — what changed against the last build. Open it, press Run, and your Mac tells you its own numbers.