Real-time audio in a browser, and on a phone.
The same processing that runs in a plugin can run in a browser tab or on a phone. Getting there means compiling the DSP to WebAssembly, driving it from an audio worklet, and keeping the buffer sizes honest on hardware you do not control.
On mobile we use React Native with native audio underneath, so the interface is shared while the real-time path stays in C++.
Your existing C++ processing compiled to WebAssembly and run in an AudioWorklet, with SIMD where the browser allows it. Demos, trials, and full products all run from the same core.
iOS and Android, with the audio engine shared with the desktop build. AUv3 where the product belongs inside a mobile host.
Layouts that hold up when the screen changes shape mid-session. Fold, unfold, and split-screen states are tested rather than assumed.
A browser demo of a paid plugin removes the largest step in the buying process. We build these as a thin wrapper over the same engine, so the demo cannot drift from the product.
Usually yes. Threading, file access and denormal handling are the parts that need work. We check those first and report before committing to a build.
It depends on the browser and the device. We measure on the targets you care about and give you the numbers before design decisions depend on them.
Yes, including signing, provisioning and the listing itself.