September 2026
Updates released in September 2026.
App Builder now catches frozen previews automatically
September 7, 2026 — If an app preview stops responding in the App Builder, the editor notices and offers recovery options before the browser does
The App Builder now watches the live preview while it runs and detects when it becomes unresponsive. Instead of the whole tab locking up, you see a clear “Preview stopped responding” message with four choices:
- Wait — hide the notice and give the app a little more time; it keeps running in the background and may recover on its own.
- Restart preview — reload the app from scratch if waiting did not help.
- Turn Safe Mode on — disable the preview entirely so you can edit the code and chat with the Builder without the frozen app getting in the way.
- Ask the Builder to fix it — send the App Builder agent the freeze time and recent console output, so it knows exactly what went wrong and can suggest a fix.
The editor stays usable the whole time: you can still switch tabs, edit files, and continue the conversation while the notice is shown. Once a preview has frozen, the Builder will not embed it directly in the editor page again, so a runaway app cannot freeze the whole workspace.
App Builder pages and public apps
September 6, 2026 — Pro apps can now have multiple pages, including public pages that anyone can visit without signing in
Apps built with the App Builder are no longer limited to a single screen. You can now add extra pages, each with its own address and access mode, so the same app can host both internal ERP tools and public-facing content. This makes it practical to build anonymous-access websites such as landing pages, product catalogs, or registration forms directly inside Operator.
- Each page gets its own path — for example
/pricing,/docs, or/register. Sub-pages are organized as nested paths. - Public pages need no login — visitors can open and share the address without an Operator account or an ERP.net connection.
- Internal pages stay protected — pages that require an Operator user or an ERP.net internal user still ask for sign-in, so one app can mix public and private content safely.
- The Home page sets the default — you choose whether the app opens publicly or internally by default, and new pages inherit that choice unless you change it.
- Public pages use safe backend requests only — they can call backend web requests that you explicitly mark as public, but they cannot reach ERP.net data, app tables, files, or secrets directly.
To add a page, open an app in the App Builder and go to Backend → Pages. Public pages require a Pro app.
App Builder now runs big jobs as a step-by-step work plan
September 4, 2026 — Large app changes no longer restart from scratch when a build spans several turns
When you ask the App Builder for something substantial — a multi-file refactor, a performance analysis, or a complex new feature — it now breaks the work into an ordered plan and works through it one step at a time. You see the plan right inside the conversation as a compact Work plan strip.
- Progress you can read at a glance — the strip shows how many steps are done and which one is active, so you know exactly where the build stands.
- Each step finishes before the next begins — the Builder completes one focused piece of work, records what it found, and only then moves on.
- Pauses resume where they left off — if a long build is interrupted or needs a Continue, the next turn picks up the pending step instead of rediscovering everything from the start.
- Less wasted context — findings from completed steps are carried forward, so the same question does not get answered again and again.
- Big jobs become steadier — refactors, optimizations and large new screens are less likely to drift or lose momentum halfway through.
The work plan appears automatically whenever the App Builder decides a request is large enough to benefit from it. You do not need to manage the steps yourself; just describe what you want and watch the plan update as the Builder works through it.