Where this is going.

Looking inside a Run, not only a Debug — a way back from the running application

The state view shows what every open window remembers while it runs — under Debug, where the application runs inside the IDE. Run deliberately does not: it starts the very bundle your customer would receive, in its own process, so that “it worked when I ran it” means something and a runaway script cannot take the IDE down with it. Nothing can look inside that.

Giving it the same would mean a request-and-answer channel living inside every application you build. That is a decision about your product rather than about our editor, which is why it is here and not done. It is not a licence check and never will be — but it is surface in something you ship, and that deserves to be decided rather than assumed.

One JavaScript context per session — on the server, and only there

A window remembers things (form.variable) and so does a session (application.variable). On a single-user application, on a client and in the IDE each user already has a context of their own, so those two words mean exactly what they say. A server does not: every desk shares one, which is where the session's variables would quietly become shared ones. This gives each connected client its own.

It buys isolation, not speed. The serial database lane stays serial on purpose — SQLite has one writer, and the order table events run in is your business logic — and our own load test says that lane is not the limit anyway: 0.6 ms of database work against 242 ms of waiting at 400 clients.

Measured before designing, as everything here is. A session's own context costs 446 KB and 2.6 ms — 174 MB at four hundred desks, three times cheaper than giving each one its own JavaScript heap. The same run found the thing that decides the shape: throwing a context away gives nothing back, and that is JavaScriptCore rather than us — bare contexts with none of our code in them behave identically. So the answer is a pool that hands the same contexts out again, which held flat at 183 MB across twelve hundred sessions.

What an application remembers for next time — one tick per variable, and the settings question is answered

A window's variables and a session's can be marked remembered, and they are there again the next morning: the search you had, the branch you work in, the report you print. It sounds small and it answers a whole family of wishes that every application of this kind ends up building by hand — a settings table with a key and a value, a form for it, a script to read and one to write.

Two kinds, not one, and that is the design. What is about this screen — column widths, window size — must not travel: a 13-inch laptop and a 27-inch display want different answers. What is about the work — a filter, a chosen branch — must. So the choice is don't remember · on this Mac · for this person.

And we will not invent a notion of “user” for it. Neuridion has none, deliberately. Your application usually does — it signed somebody in — so it tells us: application.remembersFor = person.id. Without that it falls back to the device. On a server the values live beside your database, never inside it: your data model stays yours.

An object bound to a variable — a search box with no script at all

An object on a form can be bound to a field of the record. It should be bindable to one of the window's variables too: search field to searched, a label to the count. Then the commonest small window in any application needs no code.

The hard part is not the binding, it is knowing when to redraw — a script changes a variable whenever it likes and nothing tells the window. The answer needs no machinery: a script can only change one while it runs, and the runtime already knows when an event ends. And this is where the declared type finally earns its keep — only a yes/no variable belongs on a checkbox.

Licensing your own customers — your keys, not ours

Neuridion puts nothing into what you build — no key, no expiry, no check. But some of you sell to your customers and need your own answer to that question, and writing one from nothing is a week of work and several ways to get it wrong.

So: the pieces, as ordinary commands — sign something, check a signature, read a key someone typed. Yours, in your application, under your rules. It changes nothing about ours: what we put into a built application stays nothing.

E-mail, as a class of its own — and not one setting for encoding

An application that keeps customers eventually has to write to them. So: mail.create() gives you a message with recipients, a subject, text, optionally HTML, and attachments — a stored file, a project asset, a report. An address is an object, never a hand-built “Name <address>” string, which is exactly where the comma in “Dr. Müller, Werft GmbH” breaks such strings today.

The interesting decision is an absence: there is no encoding option anywhere in it. Eight things go wrong with e-mail — umlauts in the subject, umlauts in an attachment’s name (a different rule), lines over 998 characters, a line holding a single full stop, CRLF, base64, punycode, plain and HTML together — and seven of them only show at the receiving end, which is the kind of fault a developer never sees and a customer’s customer always does. None of that is a matter of opinion, so none of it is a setting.

How it is sent: handed to the Mac’s own mail program, or through your Neuridion server. Not by speaking SMTP from the built application — that would put a password into every installation, and an application that needs no secrets is one of the things this tool is.

Keeping the Mac’s calendar in step — a sync, not an export

The calendar object draws your appointments; this is about the other calendar — the one on the Mac, on the phone, in the family. Not an export, which would leave the same appointment there forty times, but a sync: write once, and the second run changes what it wrote rather than adding to it.

Which turns out to be a field, not a command. Your table carries the identifier the system calendar hands back; empty means new, filled means update. So the recognising belongs to your data model and survives a backup, a move and a rebuild — where a hidden list beside the database would not.

Three colour schemes for the code editor — and a font size

The editor colours your tables and fields, the API, the language and your text. What it does not yet do is let you choose. Three ready-made schemes: the one it has now, a quiet one where only comments, text and your schema carry colour, and a strong one. Plus the font size, which is fixed today and is the other thing people genuinely want to change.

Deliberately not a colour picker per keyword. That is nine settings, most people touch two, and the result is a scheme where a table and a field are no longer distinguishable — at which point the colouring is worse than none. Three good answers beat nine open questions; a free-form scheme can come the day somebody asks for one.

Your translations, out to an agency and back — XLIFF, the one format every CAT tool takes

The editor and the on-device fill cover the developer. A translation agency works in its own tools, and those speak XLIFF — so an export writes one file per language pair and an import brings the work back. Our model maps onto it almost one to one: the key is the unit id, the base text is source, the translation is target, and the states line up.

The context sentence is what makes it worth doing. Every unit already carries one — “Title of the button ‘save’ on form ‘Invoice’” — and it goes out as the unit’s note. Most software hands a translator a list of strings with no idea where they stand; that is exactly why machine-translated software reads the way it does.

The decision that makes it two days rather than half a one: what comes back is a human’s work, so it lands as yours and the machine never touches it again — and it may not silently overwrite what you translated yourself in the weeks it was away. So the import is a comparison list: so many new, so many unchanged, and the handful that stand against your own words, with both versions side by side and a choice per row. Read-before-write, the same rule as everywhere else here.

Waiting on purpose: it pays off the day a real customer briefs an agency, and that customer will tell us things we would otherwise be guessing — whether the agency wants one archive or one file at a time, XLIFF 2.0 or 1.2, partial deliveries or not. A file format with no users is the easiest thing in the world to design wrong.

Japanese, Chinese and Korean — the three biggest Mac markets we do not speak yet

Nine languages become twelve-plus: Japanese first (Japan is one of the largest markets in the world for tools of this kind), then Simplified Chinese and Korean, with Traditional Chinese almost free once Simplified exists. All of them are languages Apple Translation speaks, so filling your own captions works from day one.

Undo — the price of “nothing is saved, because everything already is”

Neuridion has no Save button: leaving a field writes it. That is right, and it costs exactly one thing — there is no way back from a mistake. Until it exists, the nets are the ones already built: automatic backups, the read-before-write rule on everything destructive, and the revision counter that refuses silent overwrites.

Hard, and honestly so: an undo that only covers the last field is a lie, and one that covers everything has to know what a transaction was. Moved from 1.0 on 22 August 2026 — done right rather than done rushed.

An App Store build for the applications you make

A second kind of build, sandboxed to Apple's rules, so an application you made with Neuridion can be sold in the Mac App Store under your own name.

The honest part: a sandboxed application cannot write wherever your scripts say. That has to be found out by building one and clicking through everything, not by reading the rules — and the build sheet will say plainly what such a build cannot do, rather than flattering it.

More of a window reachable from a script — objects, not just their values

A script can already read and set what an object shows: its value, its text, whether it is visible, enabled or required, which style it wears, what is selected in a list. What it cannot do is treat the window as a thing in its own right — ask which objects are on it, move or resize one, put the cursor somewhere, or reach the parts that only one kind has.

From 2.0 that surface grows. The rule it grows by is the one every group here follows: a command joins the group it belongs to and is spelt out in full, so form.total.moveTo(x, y) reads like the rest of the API and not like a framework leaking through.

Why it waits for 2.0 rather than arriving quietly: API names are free before 1.0 and permanent after it. A surface this size is worth getting right once, against real projects, instead of growing a command at a time — and everything a form needs to be built is already there.

Over the open internet, or not — an open question, not a plan

Today a Client reaches its Server over a VPN — Tailscale, WireGuard, or whatever your network already has. That is what we build, what we test and what the manual describes.

Whether a direct road over the internet is ever added is genuinely open, and it is listed here as a question rather than a promise. The encryption would not be the obstacle: pairing pins the server's own key, which is stronger than the certificate chain a browser trusts. The obstacles are the pairing code, being reachable at all, and latency. What is not open: a relay of ours — a service in the middle that your application could not live without. As things stand we will not build one.

A security page on the server — what is open, and to whom

The server window has pages for clients, devices, locks and backups. What it has no page for is the question somebody's IT department asks: which port is open, which devices are paired, what is encrypted and what is not.

It waits on the question above, because what such a page needs to say depends on whether there is ever a road other than a VPN.

Forms that scroll — so a long record is not capped at one screen

Today a form is exactly as tall as its window. From 2.0 a form can be taller than the window it opens in and scroll: the window keeps its size, the content moves beneath it, so a record with many fields is no longer limited to what fits on a laptop screen.

The point is the person filling it in. A soft fade at the bottom edge and a visible scrollbar say there is more below, so nobody misses the last fields; the designer shows a line marking the window's edge while you build. One rule keeps it honest — one scroller per form, the form or a large list inside it, never both fighting the wheel.

Remote debugging

Breakpoints in the code that is actually running on the server, from the IDE on your desk. Same debugger, one hop further away.

Moved here from 2.0 on 27 August 2026 — nothing before the browser needs it: the server moves the data, and the scripts a debugger stops are still running on the desk in front of you.

The Mac's own abilities, as commands — what a Mac application can do that a database cannot

Neuridion already uses what the Mac brings where it earns its place: the on-device model detects a language and translates on the customer's own machine, printing goes through the system, files and permissions are the system's. Beyond that lies a whole shelf of things a Mac application may do and a database tool usually cannot — notifications, calendars and contacts, the share sheet, Shortcuts, Quick Look — and each of them would be a handful of commands in a group of its own.

Two conditions, and they are the reason this is 3.0 and not 1.1. Nothing may become mandatory: an application that needs a permission it never uses is worse than one that cannot do the trick. And each of these asks the person a question the first time — so every one needs an honest answer to what the applications you build have to declare, which is a decision about your customers' installers, not about our API.