[kyleparisi]

applySettings: is the one selector in VirtualDisplay.Runtime.privateAPISurface that returns BOOL, and its expected encoding was the literal "B@:@". That is what the Objective-C runtime reports only where OBJC_BOOL_IS_BOOL holds, which is arm64. On x86_64 macOS BOOL is signed char, so the runtime reports "c@:@", Runtime.method throws Failure.changedSignature, and the virtual display is given up on even though CGVirtualDisplay is present and working normally.

The fix takes the encoding per architecture. No behaviour change on arm64 — the encoding there is the "B@:@" it has always been.

I appreciate this is a file that deliberately refuses to guess about private API, which is exactly why the wrong expectation is worth correcting: the guard is doing its job, it is just checking against a spelling that only one architecture uses.

How it shows up

swift run -c release SillHost --virtual-display-selftest on an Intel Mac, before:

Virtual display self-test (macOS Version 15.7.3 (Build 24G419))
  Screen Recording preflight: true, Accessibility trusted: false [informational]
  FAIL CGVirtualDisplay applySettings: changed signature: expected B@:@, found c@:@

After:

  private API: all 17 selectors present
  created id 4128835 in 14 ms; online at requested mode: true after 1832 ms
  bounds (0.0, 0.0, 1000.0, 700.0), backing 2000×1400 px
  cursor reach: warp to (500.0, 350.0) → (500.0, 350.0) (on display: true)
  CGGetOnlineDisplayList contains it: true; CGDisplayIsActive true
  SCShareableContent lists it after 88 ms
  destroyed: gone from CGGetOnlineDisplayList after 54 ms: true

In a running host the symptom is quieter: every --virtual-display pick logs the Virtual display fallback … line and streams the real window, so it reads as "the private API moved" rather than "this Mac spells BOOL differently."

Environment

Hardware	Mac mini (2018), Macmini8,1 — 6-core Intel Core i5-8500B @ 3.0 GHz, Apple T2, Intel UHD 630
macOS	15.7.3 (24G419)
Toolchain	Command Line Tools 16.4, Apple Swift 6.1.2 (swiftlang-6.1.2.1.2 clang-1700.0.13.5), macOS 15.5 SDK
Base commit	985a733 (main)
Device	iPhone (iPhone17,5), Sill 0.5.1 (4) from the App Store

Note this is not the documented toolchain (Xcode 27 on macOS 26/27), because Xcode 27 cannot be installed on macOS 15. Built with swift build -c release and Scripts/make-app.sh under Command Line Tools only.

Context: what else an Intel build needs

Not part of this PR, recorded in case it is useful to anyone else arriving here. The repository is otherwise architecture-clean — no #if arch(...) anywhere in Sources/ or iOSClient/, and no ARCHS pinning in the Mac build scripts. The arm64-only binary is a consequence of swift build defaulting to the host architecture, exactly as Scripts/release.sh's own comment anticipates ("The site says Apple silicon: change that if this ever lists x86_64"). The encoding above was the single genuine architecture dependency I found, and it is invisible to a grep because it lives in a string literal.

One further change is needed to compile on macOS 15, which I am deliberately not proposing: StreamProtocol/RemoteIdentity.swift calls SecIdentityCreate, which is declared in Security/SecIdentity.h in the macOS 26 SDK and no earlier one (macOS 15.5's header has only SecIdentityCreateWithCertificate). The symbol itself has shipped in Security.framework for years — dlsym finds it on macOS 15.7.3 — so a local @_silgen_name declaration returning Unmanaged<SecIdentity>? (CF Create rule) is enough to build. That is me compiling against an SDK the project does not claim to support, so it belongs in my tree, not yours.

Performance on this hardware, for the record

The virtual display works, but Apple silicon's encoder is doing much more of the work than an Intel/T2 machine can. Posting the numbers because the README's Apple silicon requirement is well justified on throughput grounds, and anyone finding this issue should know what to expect rather than assume a misconfiguration:

	This Mac mini (T2)	Repo's figures (Apple silicon)
Frame age (encode → device)	55–61 ms (max 123–136)	8–10 ms
rtt, same LAN	4–6 ms	6–9 ms
Hardware HEVC, 3024×1898	cap.complete 60 → enc.out 37, enc.mailboxDrop 23	57–60 fps after a session refresh
Sustained synthetic stream	36.3 fps, 0 network drops	~60 fps

The network is not the constraint; the encoder is, at roughly 27 ms/frame where Apple silicon manages 9. Glass-to-glass lands near 80–110 ms rather than the 40–60 ms the brief targets. Dropping Resolution to Standard helps considerably more here than it would on Apple silicon.

Two T2-specific notes that may interest you independent of Intel:

• The T2's AVE encoder is single-instance. A second concurrent session fails in the kernel with Cannot open AVE instance, there appears to be another instance already open! → err = -12915. The slow-state session replacement in HEVCEncoder (replacesSlowSessions, on by default) opens a new session alongside the live one, which cannot succeed on this hardware. In practice it never fired during real use — SILL_TEST_ENCODER_RECYCLE=0 is the escape hatch — but the "two sessions share one engine" assumption documented in CLAUDE.md is arm64-specific.
• --encoder-selftest fails on this machine for the same reason: its 256×256 launch probe still holds the engine when the stream-sized session opens. Normal host startup is unaffected, since the probe is released before streaming begins.

Tested

• Tests/checks/run-all.sh — 39 of 40 pass. The exception is duo, which fails for a reason unrelated to this change and would fail the same way on an unmodified main with this toolchain: on Swift 6.1.2 the type checker gives up on a literal CGFloat sum in the check's own source.

  Tests/checks/duo/main.swift:115:5: error: the compiler is unable to type-check
  this expression in reasonable time; try breaking up the expression into
  distinct sub-expressions
  115 | let controls: CGFloat = 12 + 78 + 2 * 10 + 48 + 22
  

  That check compiles only iOSClient/DuoPosture.swift and its own main.swift, neither of which this PR touches. Swift 6.3 under Xcode 27 evidently handles the expression; annotating the literals (or splitting the sum) would make the check build on older toolchains too, if that is worth anything to you.

• swift build -c release, and Scripts/make-app.sh (ad hoc signed; actool is unavailable without Xcode, so the icon is generic)

• --virtual-display-selftest before and after, output above

• Sill.app 0.5.1 running as the host: paired with the App Store iPhone app via QR over the TLS home door, streamed the whole desktop at 4096×2304 and individual windows (Chrome, iTerm2), switching sources live

• No encoder fallback, hang, or slow-state replacement in the log across the session

Not tested: anything on arm64 — I have no Apple silicon Mac, so the unchanged "B@:@" path is reasoned about rather than run. The iOS app was not built (it needs the iOS 27.1 SDK, unreachable on macOS 15); the App Store build was used instead. If a reproducer uses a shallow clone, note that make-app.sh derives CFBundleVersion from git rev-list --count HEAD and will report a wrong build number.

On Intel support generally

I am not asking you to support Intel Macs, and closing this is a perfectly reasonable call — the throughput numbers above make the case for the Apple silicon requirement better than any argument would. The encoding fix stands on its own though: it is two lines, changes nothing on arm64, and makes the private-API guard check what the platform actually reports instead of rejecting a working method.

[Saffsanity]

From a pass over all the open pull requests (nothing is decided yet): this pairs with #88, which makes Sill.app universal, and with both as they are the x86_64 slice would refuse the virtual display on macOS 26 Intel Macs, because the tester in #62 ran an x86_64 build on macOS 26.7.1 that passed the self-test with B@:@. Accepting both B@:@ and c@:@ on any architecture (with the return typed as ObjCBool) would let the two ship together and let CI's arm64 build compile the check; the comment near the call also says Failure.changedSignature where the case is signatureChanged.

[Saffsanity]

Three commits were added on this branch since fcc4957; the head is now 71aec66.

1. A merge of main (9a8e30c). Apps list: the apps in a folder of their own (#76) #136 added the installed-apps check to the same one-line mutants matrix in ci.yml, so the line conflicted. It now lists both checks. Main has not changed VirtualDisplay.swift.
2. The check now runs the real decision. Before, Tests/checks/virtual-display-api judged encodings with a copy of Runtime.method's logic, so reverting Runtime.method's guard to the old equality (the bug this pull request fixes), or making the applySettings: call expect "c@:@", still passed all 141 checks.
   • VirtualDisplay.methodProblem(cls:selector:encoding:) gives Runtime.method's decision for one entry of the surface; checkPrivateAPI now uses it and lists the same lines as before.
   • VirtualDisplay.applySettings(_:to:) is Runtime.applySettings moved out of Runtime unchanged; init calls it.
   • The check makes NSObject subclasses at run time (objc_allocateClassPair, class_addMethod) and puts each encoding on a method of one. Three have an applySettings: typed B24@0:8@16, c24@0:8@16 and C24@0:8@16: the first two pass and read YES and NO through ObjCBool; the third is refused with "expected B@:@ or c@:@, found C@:@". No private class is looked up.
   • 152 checks; 17 of 17 mutants caught, among them the guard reverted, normalized dropped, the call expecting "c@:@" and the answer ignored. ApplyFn returning Bool is not among them: on arm64 it compiles to the same code as ObjCBool, so CI cannot tell them apart.
3. Docs. docs/DEVELOPMENT.md and the checks README now say the "B" on macOS 26.7.1 is inferred, not printed: Feature Request: Support Intel based Macs #62's OpenCore machine passed the self test with an x86_64 build that took "B" alone. The README row also says that on arm64 the only "c" methods the check runs are its own.

Verified on an M2 Pro with macOS 27.0.1: release builds for arm64 and x86_64; the check and its mutants, and the check built for x86_64 and run under Rosetta; run-all.sh for virtual-display-api, installed-apps, keychain and origin; a scratch driver built from this VirtualDisplay.swift, which natively read B24@0:8@16, found all 17 selectors and created a display that came online at 2000×1400, and under Rosetta read c24@0:8@16 and found all 17 selectors (on fcc4957 the same driver also created and removed a display under Rosetta), without the self test's pointer warp, HID move and ScreenCaptureKit steps.

Nothing has run on Intel hardware; the merge commit will say so. It merges once CI passes on this head, with #88 right after it.

[Saffsanity]

Thank you @kyleparisi, your encoding fix is in the Mac nightly, the first universal download, Apple silicon and Intel in one app! Since you have the 2018 Mac mini, you may well be the first to run this build on a real Intel Mac: with Sill for iPhone and iPad 0.5.5 (5) on TestFlight or the App Store's 0.5.1, I'd love to hear here (or in #62) whether the virtual display comes up and what frame rate you get. Nightlies build as 0.5.5 with rising build numbers and Sill's update check never offers them, so you install them yourself; 0.5.1 stays the supported release.