Context
Apple ships an on-device language model with its own session lifecycle, capability checks and failure modes. From Flutter that surface is only reachable through platform channels, and hand-written channel code drifts the moment there are more than a few methods, because the Dart side, the serialisation and the Swift side all have to change together with nothing checking that they agree.
Decisions
Generate the bridge from one declaration instead of writing it three times. A runtime package holds the interface and a generator package produces the channel plumbing, so a disagreement between Dart and Swift is a build failure rather than a crash on one platform.
Treat "the model is not available" as a normal result, not an exception. The device may be too old, the model may not be downloaded, the user may have turned the feature off. The interface reports capability explicitly so a caller branches once, high up, and the rest of the code assumes a working model.
Consequences
A working plugin, published, with a clean interface. Adoption is small and I would rather say that than imply otherwise; its value on this page is the boundary judgement and the generator, carried through to something that runs.
What I would do differently
Build the consuming app first. The interface was designed from the platform API upward, and one real caller would have pushed on cancellation, streaming partial output and model eviction mid session much earlier.