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:

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 and Go Mobile binding model.