What happens
The native tab bar is not a tab bar. CraftTabBarView (CraftApp.swift:1181,
content at :1192, body at :1204) is an HStack of Buttons that draws
its own chrome:
HStack(spacing: 8) {
bar
if let accessory = chrome.tabAccessory {
Button { CraftHybrid.shared.open(accessory.id) } label: {
surface { Image(systemName: accessory.symbol) ... }
}
}
}Selection is a tinted circle drawn by hand
(Circle().fill(selectedColor.opacity(0.14)).padding(4)), the badge is
Capsule().fill(Color.red) with its own minimum size, and the hit target is a
contentShape(Rectangle()).
There is no UITabBarController, no UITab, and no SwiftUI TabView
anywhere in the iOS templates.
To be clear about one thing, because it is the obvious first guess and it is
wrong: the material is already correct. surface (:1276) uses the real
iOS 26 API — GlassEffectContainer with
.glassEffect(.regular.interactive(), in: .capsule) — and falls back to
.ultraThinMaterial below 26. Nothing here needs glass applied to it. What is
missing is the control, not the finish.
Why this bites
A recreation only has the behaviours someone wrote. The ones iOS 26 gives a real tab bar for free, and which do not appear anywhere in the templates:
tabBarMinimizeBehavior— the bar shrinking as content scrolls, which is what the system apps do. No reference in the repo.- scroll edge effects — no
scrollEdgeEffect. - the interactive morph between the bar and its accessory.
- selection animation and the haptic that goes with it; ours is a static tinted circle that swaps instantly.
- the system badge, with its own metrics and Dynamic Type behaviour.
Put the app's tab bar beside the Phone app's on the same device and the difference reads immediately, before any individual detail is nameable. That is the cost: it is close enough to look intended and wrong enough to feel off.
This is also the root the tab-bar issues keep growing from. #386 — the
selected-item highlight being a hardcoded Capsule with no way to change its
shape — is not a styling oversight; it is what happens when a highlight is
drawn by hand instead of being a UITab's. #347 and #359 are the same shape
of problem for swiping. Each has been fixed as its own symptom.
What would help
Build the bar from UITabBarController (or SwiftUI TabView with UITab)
and let the system own selection, the accessory, the badge, the morph and the
minimize behaviour. The chrome contract would not have to change: tabs already
arrive as a list of id/title/symbol with an optional accessory and badge,
which maps onto UITab and the iOS 26 bottom accessory directly.
That is a large change and it would subsume several already-closed issues rather than adding another one beside them. If it is not the direction, the alternative worth stating out loud is that the bar is a deliberate custom control and the system behaviours above will keep being reimplemented one at a time as they are noticed.
Found on iOS 26 against a four-tab bar with an accessory pill.