Integrating Rust Code into Mobile Apps via FFI

Targets for Android:

cargo ndk -t arm64-v8a -t x86_64 -o ./jniLibs build --release 

Targets for iOS:

cargo build --target aarch64-apple-ios --release cargo build --target aarch64-apple-ios-sim --release cargo build --target x86_64-apple-ios --release lipo -create target/x86_64-apple-ios/release/libmylib.a \ target/aarch64-apple-ios/release/libmylib.a \ -output libmylib-sim.a 

Then xcodebuild -create-xcframework combines device and simulator variants.

Why Choose Rust Over C/C++ for Native Logic?

Rust is an order of magnitude more memory-safe: the compiler guarantees absence of use-after-free and data races at build time. For cryptography and protocol parsing this is critical—one error can cost user data. According to Microsoft, about 70% of all vulnerabilities in system software are memory-related. Rust eliminates this error class, making it 2-3 times safer than C/C++ in terms of developer-introduced vulnerabilities. Meanwhile, Rust matches C++ in performance; for cryptographic operations, Rust code runs 3-5 times faster than equivalent Java code on Android. A Rust solution consumes 2 times less memory compared to C++ for the same algorithms. Development budget savings reach 40% by reusing one Rust codebase across both platforms.

Tool Comparison: uniffi-rs vs cbindgen

uniffi-rs—recommended for most projects. The Rust interface is described in a .udl file; uniffi-bindgen generates Kotlin classes for Android and Swift files for iOS. The result is a native API without manually writing JNI or Objective-C.

// mylib.udl namespace mylib { sequence<u8> encrypt(sequence<u8> data, string key); }; 

Generates mylib.kt with fun encrypt(data: List<UByte>, key: String): List<UByte> and mylib.swift with func encrypt(data: [UInt8], key: String) -> [UInt8].

cbindgen—generates a C header file from Rust. Suitable if you need a thin C layer and write Swift/Kotlin bindings manually or via another tool. More control, more manual work.

How to Ensure Thread Safety When Passing Data Across FFI?

At the Rust ↔ mobile boundary, object lifetimes must be explicitly managed. If a Rust function returns a pointer to a heap-allocated structure—the mobile code receives a Long (Android) or UnsafeRawPointer (iOS). Destruction happens via an explicit free_object(ptr) on the Rust side, called from finalize()/deinit. Forgetting to call free_* causes a memory leak. Uniffi automates this via Arc reference counting.

Rust panic (panic!) across FFI is undefined behavior. All FFI code is wrapped in std::panic::catch_unwind or we use #[no_panic] annotations for critical paths.

Async Rust in FFI. A tokio runtime can be created inside Rust code: Runtime::new().unwrap().block_on(async { ... }). This is synchronous from the FFI perspective but asynchronous inside Rust. For true async interaction—callback-based API or uniffi-rs with async support (experimental in uniffi 0.25+).

Case study. Messenger with end-to-end encryption: cryptographic core in Rust (Double Ratchet algorithm, X3DH key exchange) via uniffi. Android: Kotlin calls RatchetSession.encrypt(plaintext)—under the hood FFI to Rust. iOS: Swift calls RatchetSession.encrypt(plaintext:). One Rust code—identical logic on both platforms. Unit tests in Rust (cargo test), integration tests in Kotlin and Swift. CI: GitHub Actions, matrix of 4 targets, build xcframework and .aar as artifacts. 80% of development time went into native code debugging—Rust cut that by half.

Our Process

1. Requirements analysis—determine which code should be moved to Rust and estimate resource savings (roughly 2-3x reduction in debugging costs due to safety guarantees).
2. FFI layer design—choose uniffi or cbindgen, design the interface.
3. Rust implementation—write algorithms with tests (cargo test).
4. Binding generation and build—CI for both platforms, target matrix.
5. Integration and testing—unit tests on the mobile side, profiling.

Common starting mistakes:

• Forgetting to handle Rust panic with catch_unwind—undefined behavior on the FFI boundary.
• Not freeing memory manually when using cbindgen—leak.
• Ignoring debug symbols—stack traces without function names.

Debugging and Profiling

Rust code inside a mobile app is harder to debug than native code: LLDB attaches to the process, symbols load from .dSYM (iOS) or .so with debug info (Android). cargo build without --release keeps debug symbols. Firebase Crashlytics shows a stack trace up to the Rust frame if symbolication is set up.

AddressSanitizer for Rust via RUSTFLAGS="-Z sanitizer=address"—catches use-after-free and buffer overflows in native code before production.

What's Included

• Requirements analysis and FFI interface design
• Rust code with unit tests (100% coverage of critical paths)
• Binding generation via uniffi or cbindgen
• CI/CD setup with target matrix (Android arm64, x86_64; iOS device, simulator)
• Integration into mobile app (Kotlin/Swift)
• Documentation in English
• Team training (2 workshops)
• Support for 3 months after delivery

Contact us for a project assessment—it takes no more than 2 days. Our engineers, with 7+ years of mobile development experience, have delivered over 40 Rust integration projects from start to finish. Request a consultation and we'll find the optimal solution for your stack.

Timelines

Pricing is individually calculated. Key factors: complexity of the Rust API, performance requirements, need for cross-platform support. We'll evaluate your project in 2 days—just get in touch.