The gap
iOS renders SVG natively. Android does not render it at all.
| SVG in the native host | |
|---|---|
packages/ios/templates/CraftNativeScreen.swift | CraftNativeSvgView — an Svg node with shapes beneath it, path geometry, SvgText on the SVG baseline, styles inherited down the tree, dark: classes resolved, and a redraw when any shape changes |
packages/android/templates/MainActivityNative.kt.template | nothing — zero references |
The only SVG on the Android side is in MainActivity.kt.template, which is the WebView path, not the native one.
Why this is the largest of the native gaps
It is not one screen, it is every chart.
HQ.training's native Progress screen draws its performance-management chart with <svg viewBox="0 0 320 180"> and a ring via ringArc(), and it renders correctly on an iOS simulator today. The same screen on Android would lose the chart silently — the node is simply not handled.
Charts are also the reason a training app has screens worth making native in the first place. Lists and forms are pleasant natively; a chart that draws in a few hundred milliseconds instead of waiting for a web view is the part people notice.
What makes it invisible
Two things, and both are fixable independently of the renderer work:
The contract tests do not cover it. scripts/native-renderer-contract.test.ts exists so that, in its own words, a platform cannot silently lose a native primitive. Its 78 cases cover Button, FlatList, Image, Modal, Picker, Slider, Switch, Text and View. It contains no reference to Svg, G or SvgText. So the one primitive that is genuinely missing on a platform is the one primitive the parity net does not check.
The documentation does not mention it. docs/guides/native-stx.md has a "Current component contract" table listing fifteen primitives and their host mappings. SVG appears nowhere in the document — not in the table, not in prose. Someone reading the docs would conclude SVG is unsupported on both platforms; someone reading ios.swift would conclude it is supported everywhere. Neither is correct.
Adding Svg/G/SvgText to the contract test would turn this from something found by reading source into a failing build, and is worth doing whether or not the Android renderer lands soon.
Scope
Separate from craft-native/craft#338, which is about SVG arriving as a string with no DOM to inject it into. This one is about SVG authored as stx nodes, which already works on iOS.
Related to craft-native/craft#334 only in that it is the same cost: a capability landed on one host and not the other, and nothing announced it.