Files
calctext/_bmad-output/implementation-artifacts/7-2-rust-ffi-bridge.md
2026-03-16 19:54:53 -04:00

43 lines
1.8 KiB
Markdown

---
epic: 7
story: 7.2
title: "Rust FFI Bridge"
status: draft
---
## Epic 7 — macOS App (Swift/SwiftUI)
**Goal:** A beautiful, native macOS app that feels like it belongs on the platform.
### Story 7.2: Rust FFI Bridge
As a **macOS developer** integrating CalcPad,
I want a Swift package that wraps the Rust engine's C FFI into idiomatic Swift types,
So that the macOS app can call the engine safely and efficiently without manual pointer management.
**Acceptance Criteria:**
**Given** the Rust engine is compiled as a C-compatible dynamic library
**When** the Swift package is imported
**Then** a `CalcPadEngine` class is available with methods `evaluateLine(_ line: String) -> LineResult` and `evaluateSheet(_ text: String) -> SheetResult`
**Given** the Swift app calls `evaluateLine("2 + 2")`
**When** the FFI bridge processes the call
**Then** the result is returned as a Swift `LineResult` struct (not a raw pointer)
**And** all memory allocated by Rust is properly freed (no leaks)
**Given** the Swift app calls `evaluateSheet` with a multi-line string
**When** the FFI bridge processes the call
**Then** an array of `LineResult` values is returned, one per line, in order
**Given** the Rust engine returns an error for a malformed expression
**When** the Swift bridge receives the error
**Then** it is converted to a Swift `Error` type or an error variant in `LineResult` (not a crash or nil)
**Given** the app is profiled with Instruments (Leaks tool)
**When** `evaluateLine` and `evaluateSheet` are called repeatedly over many cycles
**Then** no memory leaks are detected from the FFI boundary
**Given** the bridge is used on a background thread
**When** multiple calls are made concurrently
**Then** the bridge handles thread safety correctly (either by being thread-safe or by documenting single-threaded use with appropriate assertions)