package:webcrypto started life with packaging assumptions that fit Flutter better than Dart itself. With Dart build hooks stable and Flutter now recommending the package_ffi model, we re-architected webcrypto.dart into a single package that wraps window.crypto on the web and builds a BoringSSL-native backend through hooks and CMake everywhere else. In this talk, I’ll walk through the migration captured in issue #192 and PR #236 (https://github.com/google/webcrypto.dart/pull/236): why the old package boundary stopped scaling, how hook/build.dart, code_assets, and native_toolchain_cmake changed the architecture, what broke on mobile and CI, and why follow-on work like direct bindings and artifact distribution still matters. This is not a beginner FFI session. It is a talk about package boundaries, backend strategy, and how to ship native capabilities to both Flutter and Dart users without making consumers pay the complexity tax. I'll keep the demo's payoff simple: the same WebCrypto-style API call running in a browser, a Flutter app, and a standalone Dart CLI, each backed by different runtime and build paths. I'll keep the payoff deliberately simple in the demo: the same WebCrypto-style API call running in a browser, a Flutter app, and a standalone Dart CLI, backed by different runtime and build paths. What I really want to explore is the package architecture behind that result: where to draw package boundaries, how to choose and wire up backends, and how build hooks and native assets can support both Flutter and Dart users without making the package harder to use. Key takeaways: - How to recognize when a native-backed package has outgrown Flutter-plugin-shaped packaging. - How Dart build hooks, CMake, and native assets change the boundary between package author, app developer, and build system. - How to keep one public Dart API while routing work across browser and native backends. - How to structure `hook/build.dart`, CMake, bindings, and asset lookup so the same package serves Flutter apps and standalone Dart consumers. - What stayed hard after the migration: mobile packaging edge cases, CI fallout, symbol binding cleanup, and the still-open question of first-class prebuilt native asset distribution.