#Rust.
글
/ 총 8편Why a daily puzzle ID needs a generator version
A daily board is made from the date. If the generator changes, one date can give two boards, and a date-only ID cannot tell them apart. Design and proposal.
Rust shared core, part 7: splitting tests and CI by layer
Passing Rust tests still leaves iOS linking, Android release ABIs, and Wasm loading in web builds to break. Test the domain in Rust and build fresh in CI.
Rust shared core, part 6: using it on the web as a Wasm package
To use the Rust rules from mobile on the web, compile them to WebAssembly and ship a package. Roles, where to initialize in Next.js, and the call contract.
Rust shared core, part 5: what to check when shipping a .so on Android
Generating Kotlin bindings does not finish Android integration. Per-ABI .so placement, wiring Rust into Gradle, the 16 KB page rule, and release checks.
Rust shared core, part 4: delivering it to iOS as an XCFramework
Passing Rust tests does not mean an iOS app links. Bundle device and simulator static libraries into an XCFramework, ship it as a Swift package, and align CI.
Rust shared core, part 3: keep UniFFI generated code behind an adapter
UniFFI generates Swift and Kotlin calling code from Rust. What to expose and how far generated types spread is up to the app. An adapter keeps them contained.
Rust shared core, part 2: keep the API across the boundary coarse
Types that suit a Rust engine differ from types that are easy to use from Swift, Kotlin, and TypeScript. Expose coarse action-level functions under a contract.
Rust shared core, part 1: what to share and where to draw the line
Building for iOS, Android, and the web means writing the same rules three times. Narrow what Rust shares to rules that must give the same result, in 3 layers.