Pin CI to Xcode 26.3

.github/workflows/build-and-test.yml

@@ -86,13 +86,25 @@ jobs:
             echo 'func RenderPngV2(data []byte, size int) ([]byte, error) { return RenderPng(data, size) }' >> goidenticons/render_v2_ci_shim.go
           fi
 
-      # 16.4 is the macos-15 default and the series this project was written
-      # for (pbxproj objectVersion 77 / LastUpgradeVersion 1620). Pinned so a
-      # runner-image default bump cannot silently move the toolchain to
-      # Xcode 26 and with it the iOS SDK the app is compiled against.
-      - name: Select Xcode 16.4
+      # Pinned to an exact path, not to the image default (16.4) and not to
+      # "latest": a runner-image bump must never move the toolchain, and with
+      # it the SDK the app is compiled against, without a commit saying so.
+      #
+      # 26.3 rather than 16.4 because the gap had become the problem. 16.4
+      # compiles against the iOS 18 SDK while the app runs on iOS 26 devices,
+      # so anything that only exists -- or only misbehaves -- on the current
+      # SDK is invisible here. Two examples from one week: app code that needs
+      # a newer SDK symbol built fine in CI and failed on a developer machine,
+      # and `ControlCenter` is absent from the macOS 15 SDK 16.4 uses, which is
+      # the sole reason WidgetRefresh.reloadControl is walled off behind
+      # `#if os(iOS)`.
+      #
+      # This does NOT make CI able to catch runtime faults: the job builds and
+      # runs unit tests, it never launches the app. A rendering fault that only
+      # appears on a current SDK still gets through.
+      - name: Select Xcode 26.3
         run: |
-          sudo xcode-select -s /Applications/Xcode_16.4.app
+          sudo xcode-select -s /Applications/Xcode_26.3.app
           xcodebuild -version
           xcrun simctl list runtimes | grep -i ios
 

QUICKCONNECT.md

@@ -176,8 +176,9 @@ reconciler (the shared tunnel intent, section 3). The July draft in
   else, so `widgets/Assets.xcassets/gen_connector_symbols.py` rebuilds the
   connector mark analytically (a 128-unit square whose corners are five
   quarter-circle arcs of radius 8, alternating convex/concave) and emits two
-  Template v6 symbol SVGs (SF Symbols 6 / Xcode 16 -- CI pins Xcode 16.4 and
-  its actool rejects a newer template outright) with the interpolation
+  Template v6 symbol SVGs (SF Symbols 6 -- the floor every toolchain reads; a
+  7.0 export is rejected outright by an Xcode 16 series actool) with the
+  interpolation
   sources Ultralight-S, Regular-S, Black-S and Regular-M. The outline
   variant is a true filled ring
   (lines inset by w, convex arcs shrunk to 8−w, concave arcs grown to 8+w),

app/widgets/Assets.xcassets/gen_connector_symbols.py

@@ -14,11 +14,15 @@
 16) with the interpolation sources Ultralight-S, Regular-S, Black-S plus
 Regular-M.
 
-The version has to stay at 6.0: CI pins Xcode 16.4, and its actool rejects a
-newer template outright -- "Template format 7.0 is newer than the version that
-this software supports (6.0)" -- before it reads any of the artwork. The SF
-Symbols app on a current machine exports 7.0, so if you re-export from it,
-re-apply the 6.0 changes here rather than committing its output.
+The version stays at 6.0. It is the floor every toolchain we build with can
+read, and nothing is gained by raising it: a 6.0 template renders identically
+on a newer actool, while a 7.0 one is rejected outright by an older -- "Template
+format 7.0 is newer than the version that this software supports (6.0)" --
+before it reads any of the artwork. CI has since moved to Xcode 26.3, whose
+actool WOULD accept 7.0, so that error is no longer what enforces this; the
+reason is now compatibility with anyone still building on an Xcode 16 series.
+The SF Symbols app on a current machine exports 7.0, so if you re-export from
+it, re-apply the 6.0 changes here rather than committing its output.
 
 TWO CATALOGS carry these symbols and both are subject to that rule: