Happy to provide more details on this. In most cases, our server SDKs use a common WASM library to make all user bucketing and segmentation decisions locally. We have been impressed with the performance we've achieved with WASM. It allows us to share our most critical non-trivial amount of decision-making code, and it lets us share it between our Edge APIs and Server SDKs. So the same WASM code making decisions locally in our server SDKs is also making decisions at the edge for our APIs powering our client-side SDKs and public APIs.

We have stuck to the Bytecode alliance-supported Wasmtime runtimes that we highly recommend for anyone going down a similar path.

There have been cases with highly parallel environments where we needed to support micro-second level optimizations for our GO SDK, where we ended up building a native version of our bucketing logic. We hope that WASMs' upcoming threading and memory management improvements will make this use case supportable without needing native code. But for our higher-level language SDKs like NodeJS / Python / Ruby / PHP we've generally seen as good or better execution performance from WASM.

What desktop environment are you looking to support? We have customers using our iOS SDK in MacOS (we need to find a better name for our Apple platforms SDK that supports iOS / iPadOS / MacOS / WatchOS / tvOS). Our React SDK works with electron apps, and we have on our roadmap to investigate client SDK support for our .NET SDK.