This document is a preserved implementation-phase log and may reference older ticket sequencing or branch state.
Build the SonicFlow app as a monorepo with three shared core beat engines first, then platform implementations that import those cores.
SF-1Shared JS beat engineSF-2Swift beat engine packageSF-3Kotlin/Android beat engine moduleSF-4toSF-6Safari web extensionSF-7Safari Web ExtensionSF-8toSF-9iOS appSF-10toSF-11macOS appSF-12toSF-13Android appSF-14parity pass, root README, Makefile
SF-8iOS audio engineSF-11macOS menu bar UI is on branchsf/SF-11-menu-bar-app-uiand currently in review on PR #11
SF-7Safari conversionSF-9iOS UISF-10macOS system audioSF-12Android app/serviceSF-13Android UISF-14parity, docs, Makefile
sonicflow_app/
core-js/
core-swift/
core-android/
safari-web-extension/
safari-extension/
ios-app/
android-app/
- The JS core is the first source of truth and the quickest path to a testable Chrome first win.
- The Swift and Kotlin cores must match the same mode constants, envelope, and AM synthesis formula.
- Platform work stays intentionally light until the core APIs are verified.
- Active agent split:
SF-1local implementation incore-jsSF-2worker agent incore-swiftSF-3worker agent incore-android- GitHub pipeline is being established in parallel so each issue can land as its own branch and PR.
SF-4now provides the first Safari web extension skeleton with MV3 wiring, content-script messaging, placeholder popup, and icon assets.SF-5layers in the interactive popup: mode cards, beat volume slider, storage persistence, and tab messaging hooks.SF-6moves the extension onto the shared JS core and bundles the content script throughesbuild, with chunk scheduling for continuous playback.SF-7wraps the Safari web extension in a Safari Xcode project and aligns the shared JS tobrowser/chromecompatible messaging.SF-8now has an iOS SwiftUI/Xcode project generated withxcodegen, wired to the localSonicFlowCorepackage and building for the iOS simulator.