nomos_flutter 0.63.13

Drive the real Nomos GitHolon from a Flutter app — a local-first domain runtime. Apple runs the release-pinned native kernel; Android and web acquire and retain the release-pinned WASM runtime. Write [...]

nomos_flutter

nomos_flutter runs a generated Nomos business client locally inside a Flutter app. Reads and writes happen against the local holon; cloud custody provides synchronization between devices.

Use it

dependencies:
  nomos_flutter: ^0.62.3

import 'package:nomos_flutter/nomos_flutter.dart';
import 'package:co2_nomos_domain_client/co2_nomos_domain_client.dart';

NomosScope.home(
  cloud: 'https://nomos.captainapp.co.uk',
  application: 'co2-platform',
  authToken: firebaseIdToken,
  builder: (context, nomos) {
    final app = Co2Client(nomos.bridge, actor: nomos.actor);
    return Co2Home(app);
  },
)

The public inputs are the application and its signed-in identity token. The client derives the subject from the token, discovers the active application contract, and durably owns first use, later-device recovery, local persistence, synchronization, and runtime compatibility. It invokes builder only after the person's home is ready and verified.

If the application is absent, errorBuilder receives NomosApplicationUnavailable; deploy it once with:

githolon deploy co2-platform

Then use the generated client in business language:

final estate = await app.birth(CreateEstate(name: 'Team Alpha'));
app.watchEstates().listen(render);

Platform setup

• Android and web: no app configuration.
• iOS: device deployment target 13 or later (Apple-silicon simulators require iOS 14 or later).
• macOS on Apple silicon: deployment target 11 or later; sandboxed apps also add com.apple.security.network.client to DebugProfile and Release entitlements.

The package contains the client, host runner and one pinned kernel identity, not the executable kernel. On Android and web the host fetches that immutable wasm by its digest on first use, verifies it, and keeps it in framework-owned local storage for offline restarts. A first-ever start needs a connection; an app that has started successfully can restart offline.

Apple does not permit an app to download executable code after installation. During pod install, the same pinned release therefore fetches and verifies its native XCFramework; Xcode links it into the app binary. The kernel stays out of the pub package while every platform remains bound to the same release identity. A missing, unavailable or mismatched artifact fails the build/start explicitly instead of selecting another engine.