One of the most misleading UI bugs is the one that looks like a data problem but is actually a rendering problem.
We hit exactly that with SwiftUI Charts on iOS 26.
The symptom was simple:
the chart looked empty.
That usually sends people in the wrong direction. They start checking aggregation logic, query filters, date grouping, or whether the model layer returned anything at all.
In this case, that was the wrong tree.
The useful move was to split the symptom into separate layers:
- data pipeline
- rendering layer
- scale behavior
- visual contrast
Once we did that, the bug became much clearer.
The project notes already recorded multiple chart failures in May 2026 where charts rendered "empty" against realistic data. That alone mattered, because it told us this was not one weird chart implementation. It was a recurring bug class.
Then the code-level evidence made the root causes concrete.
One view documented that on iOS 26, SwiftUI Charts could silently drop BarMark rendering when the chart iterated over tuple data. The axes and labels still rendered, which made the chart feel alive while the actual bars were gone.
Another trap was domain compression. An unconditional RuleMark for a limit could silently pull the Y-axis high enough that the real series got squashed into the bottom slice of the card. The chart was not empty, but the user experience was almost indistinguishable from empty.
The third trap was visual, not structural: gradient styling on thin bars could become too subtle against warm card backgrounds. Again, the data existed. Visibility did not.
The fixes ended up being less about one magic patch and more about explicit chart discipline:
- use concrete
Identifiablechart items instead of fragile tuple-based iteration - use fixed bar widths when density is known
- pin
chartYScale(domain:)to the data, not to reference lines - make
RuleMarkconditional when the curve is nowhere near the threshold - prefer solid styles when thin bars need to stay legible
The most important conclusion from this case is not "SwiftUI Charts has quirks." That is too shallow.
The real lesson is:
when a chart looks empty, do not stop at verifying that the data exists.
You also need to ask:
- Is the mark rendering at all?
- Is the scale compressing the series?
- Is the styling too subtle to survive the background?
- Is this a visual-only bug that tests will never catch?
That last question matters a lot. The team eventually wrote down a standing rule that every non-SectorMark chart should use an explicit chartYScale(domain:) based on the actual data series, and that changes must be visually checked under stress-seed data before merging.
That is the right kind of rule.
Framework defaults are fine until they stop being fine. After that, the fix is not optimism. The fix is explicit configuration and visual verification.
If you want, the next step is to turn this into a reusable “UI looked empty but data was fine” case pattern for more frontend incidents.