ReviewOS

craft-native/craft

No supported way to customise generated native sources: the only options are a silent-reverting hand-patch or a post-build string patch

#388
Closed glennmichael123 opened this 8 days ago ·
8 days ago

Anything about the generated native UI that Craft doesn't expose as an option can only be changed by editing storage/framework/mobile/ios/, which is gitignored and rewritten wholesale by the next buddy build:ios. There's no supported way to keep such a change.

That leaves three options, and all three are bad:

  1. Edit the generated source by hand. It survives until the next build and then reverts silently — the fix disappears and nothing says so. This is the worst of the three, and it's the one that looks easiest.
  2. Patch after generation with your own script. Works, but it's string-matching against generated code you don't control, so an upstream refactor breaks it — ideally loudly, if you remember to make it assert.
  3. Fork.

The concrete case

craft-native/craft#386: the tab bar's selected-item highlight is a hardcoded Capsule(). A tab in config/mobile.ts is { id, title, symbol, badge } with no styling, and there are no tab-bar appearance options, so there is nowhere to express "square those corners".

We ended up at (2) — a script wired into build:ios that rewrites

Capsule()
    .fill(Color.primary.opacity(0.09))
    .matchedGeometryEffect(id: "selection", in: selection)

to a RoundedRectangle, matching on the fill and the matchedGeometryEffect rather than on the bare Capsule() it shares with the bar itself and the badge. It throws if it can't find that shape, so the build fails rather than quietly shipping the old look.

That's a reasonable amount of machinery for a corner radius, and it's a maintenance liability we're carrying only because there's no alternative.

What would help

A supported extension point, roughly in order of how much we'd want it:

  • Appearance options in config/mobile.ts for the things apps routinely restyle — tab bar selection shape and colour first, since that's the one we hit. This covers the common case without anyone touching Swift.
  • A documented "user sources" directory that generation never overwrites, where an app can add or override Swift. Expensive, but it ends the whole class.
  • A post-generate hook Craft invokes after writing the project, so patches are at least a declared part of the build rather than something each app bolts on. Cheap, and it makes the patching approach legitimate instead of a workaround.

Even the first alone would have removed the need for the script.

Happy to send a PR for the appearance-options version if that's the direction you'd want.

Sign in to comment on this issue.