Allow static linking by removing explicit type: .dynamic

[tadg-paul]

Body

Hi - first of all I wanted to thank you for MisakiSwift and KokoroSwift.

I feel strongly about TTS as a technology that gives a real meaningful benefit to people with disability (I may have a selfish interest, as one of those people myself), but I also feel strongly about such technologies being open source and not behind commercial licenses or paywalls. Your work has been a huge contribution to the ecosystem, and I really appreciate it.

In that spirit, MisakiSwift and KokoroSwift have been invaluable - MisakiSwift as a dependency, and KokoroSwift as an architectural reference for building my own inference pipeline. I hope you'll take the latter as the compliment it's intended as, rather than any attempt to compete - the goal is to build on your work, not to duplicate it.

I'm building yapper, a CLI tool and embeddable Swift library for Kokoro TTS on Apple Silicon. Yapper uses MisakiSwift for G2P and implements its own inference pipeline on MLX Swift (referenced from KokoroSwift's architecture).

The issue

MisakiSwift's Package.swift declares type: .dynamic:

.library(
    name: "MisakiSwift",
    type: .dynamic,
    targets: ["MisakiSwift"]
),

This forces all downstream consumers to link MisakiSwift as a dynamic framework. For iOS apps (like KokoroTestApp) this works fine. For CLI tools distributed via Homebrew, it creates significant packaging challenges:

• The binary can't run standalone - it needs the framework and its resource bundle at a discoverable path
• macOS SIP strips DYLD_FRAMEWORK_PATH from signed binaries, preventing environment-variable workarounds
• The only packaging options become embedding frameworks (~118MB) or building as an .app bundle

The proposed change

Remove the explicit type declaration, letting SPM decide based on the downstream consumer's needs:

.library(
    name: "MisakiSwift",
    targets: ["MisakiSwift"]
),

When type is omitted, SPM automatically chooses static or dynamic linking based on what works best for the consuming package. Apps that need dynamic linking still get it; CLI tools that need static linking get that instead.

Impact

• No functional change for existing consumers - SPM defaults to the linking strategy that matches the consumer's needs
• KokoroTestApp would continue to work (SPM would choose dynamic for the app target)
• CLI tools like yapper could link statically, producing a single self-contained binary

Note on resources

MisakiSwift bundles resource files (lexicon dictionaries, BART model weights). SPM handles resource bundles correctly for both static and dynamic libraries - the Bundle.module accessor works in both cases. This is well-supported since Swift 5.3.

Thank you for considering this. Happy to discuss or adjust the approach.