From Chris Breuer, setting the goal for every Stacks app:
in hq.training, we have quite a bit of swift code, and i think a good goal is to create abstractions that stacks projects are always 0 swift (it's okay if some swift shells have to be shared/distributed but they can live in node_modules and be published into there then IMO)
bc everything should be abstracted nicely into craft/stx
Where hq.training stands. storage/framework/mobile/ios/ is generated — the Xcode project, the bundled native-screen runtime, stacks-mobile.json — and it is regenerated on every release, so it is build output rather than maintained source. That part is already the right shape.
What the goal asks for is that it stay true as apps need more of the platform: the moment an app needs something Craft does not expose, the only way forward today is to put Swift in the app repo, and then it is there forever. Several open issues here are exactly that pressure — no Map primitive (#340), no SVG in the Android host (#339), no audio in the native runtime (#337), no way to upload a picked photo (#341). Each one is an app one capability away from writing its own Swift.
What would make the goal hold:
- every platform capability reachable from TypeScript, so an app never needs a bridge of its own
- when an app genuinely needs its own native code, a supported way to ship it as a package — a Swift shell published to npm and resolved from
node_modules, not pasted into the app repo - a way to check it: a Stacks app should be able to assert that it contains no
.swiftof its own and have that fail loudly when one appears
Filing it as the umbrella the individual capability gaps hang under, so the goal is written down somewhere rather than living in a Discord message.