PyCon Cameroon 2026: Python, Dart & Flutter — Native Performance with FFI

The talk starts with a common problem: you have two worlds. Flutter handles UI and UX across mobile, desktop and web, while Python owns AI, ML, data and scientific tooling. The obvious way to connect them is to build an API, and it works, until your calculator needs a backend. Every call becomes serialize, HTTP, network, process, serialize, network, with latency, deployment and failure points along the way. For local work like image and audio processing, local AI, cryptography or computer vision, there is a more direct path: Flutter to native code to result.

Enter FFI, the Foreign Function Interface. The key word is function: you are not sending messages, you are calling one. The session walks through the simplest possible Dart FFI call into C, then explains the ABI, the machine-level contract underneath it. The API tells you what to call; the ABI tells the machine how to call it. An important correction follows: FFI doesn't speak C, it speaks a C-compatible ABI, which is why the same approach works with Go and Rust through extern "C".

Then the interesting part: Python. Dart can't call a Python function directly through dart:ffi, because a Python function is a runtime object, not a native symbol. The bridge is CPython's C API. By embedding the interpreter, native code can import a module, look up a function, build arguments and call it, giving the full chain Flutter to Dart to FFI to a native layer to CPython to Python. A C bridge isn't required by FFI, but it is a sensible architectural choice that keeps pointers, reference counting and error handling behind a simple signature Dart can call.

The last section is about cost. Crossing the boundary means owning memory, errors, threads, runtime initialisation, packaging and platform support. Strings aren't strings until you convert them, and chatty calls across the boundary undo the benefit, so cross it deliberately. The talk covers where FFI shines (heavy computation, local AI, image and audio processing, hardware, existing native libraries), when an API is still the right answer, how to measure HTTP against FFI honestly, and modern Flutter tooling with the package_ffi template and ffigen.

It closes on the bigger picture: FFI isn't really about Python, it's about interoperability. Three things to remember are that FFI is a native function boundary, the ABI is the contract underneath, and performance comes with responsibility. Don't use FFI because you can. Use it because the problem demands it.