# Share Go logic with a native companion

Use Go Mobile when the app already has useful Go logic to share. Keep the
binding surface in a small package independent of HTTP handlers, the server
bootstrap and UI. The app's normal Go module owns its engine and tool pins;
Rastrillo Native does not make Go a dependency of Swift-only consumers.

Install `gomobile` and `gobind` from the same reviewed `golang.org/x/mobile`
revision, record that revision in the app's build configuration, and run
`gomobile init`. Keep that module in the engine's dependency graph as well.
Do not silently update a binding tool during a release build.

From the engine module, with its exported binding package at `./mobile`:

```sh
gomobile bind -target=ios,iossimulator,macos -o AppEngine.xcframework ./mobile
gomobile bind -target=android -o appengine.aar ./mobile
```

Apple builds need macOS and Xcode. Android builds need the Java toolchain,
Android SDK and NDK. Use `gomobile help bind` from the pinned toolchain for
its supported targets and flags. Import the XCFramework in the Apple app
and the AAR in the Android app; UI and lifecycle remain platform code.

These are integration recipes, not outputs validated by this package's CI.
Before adopting a bridge, compile it for each supported target and exercise
it through Swift/Kotlin, including errors, callbacks and cancellation.

Only a subset of Go types can cross bindings. Prefer a small API carrying
strings, numbers and byte slices; keep complex internal types behind it.
Specify who owns callback lifetimes and which thread receives them, avoid
blocking the UI thread, and batch work where repeated crossings are costly.
Browser clients can keep a WebCrypto or JavaScript implementation pinned by
the same test vectors. Neither a Swift package nor a mobile binding makes
the web client use the Go engine automatically.

Source: [Go Mobile command documentation](https://pkg.go.dev/golang.org/x/mobile/cmd/gomobile)
and [Go Mobile binding model](https://go.dev/wiki/Mobile).