On iOS, ordinary CSS font-weight can leave a variable font at the file's default weight. With SN Pro (weight range 200–900, default 200), a normal label should select 400 and font-weight: 600 should select 600, but both resolve to 200. TextField and TextView have the same problem. This was reproduced with NativeScript core 9.1.3 on an iOS 27 simulator by inspecting the native UIFont's CoreText variation coordinates. Current main still only applies variation coordinates when fontVariationSettings is explicit.

Reproduction: bundle SNPro[wght].ttf as fonts/SNPro.ttf and apply:

<StackLayout>
  <Label fontFamily="SN Pro" text="Expected normal weight 400" />
  <Label fontFamily="SN Pro" fontWeight="600" text="Expected weight 600" />
  <TextField fontFamily="SN Pro" fontWeight="500" text="Expected weight 500" />
  <TextView fontFamily="SN Pro" fontWeight="500" text="Expected weight 500" />
</StackLayout>

Explicit font-variation-settings: 'wght' 550 selects the correct coordinate, but callers should not need to duplicate the weight in low-level variation settings. The resolver should derive the supported wght coordinate from the computed CSS weight, use 400 for normal, preserve explicit-axis precedence, clamp to the font's range, and leave static fonts on their existing selection path.

Downstream reproduction and fix: octane-xplat/octane-xplat#156. The Android counterpart is tracked separately in #11513 / #11514.