rdmsm4x-changelog-20260915-2223-bitroo-ios-parity-and-ecssystem-ios-fix

2026-09-15 22:23:07 EDT · rdmsm4x · session_012cXdr2uPhnPS1cQfbt9pPQ

BitRoo now exists on iPhone and iPad, per Rich's instruction. Delivering it exposed and fixed a real defect in a shared library used by 33 consumers: ECSSystem advertised iOS support it could not compile.

Scope

Tickets: EPIC-20260915-01 opened with 4 children; FEAT-20260915-01 and ISSUE-20260915-17 resolved; FEAT-02/03 and SPIKE-01 open.

What shipped

BitRooCore was already portable — no #if os(), no AppKit. The app layer was not: HSplitView, .pickerStyle(.radioGroup), .keyboardShortcut, and a 720pt minimum width wider than any iPhone. So iOS needed its own view layer, not a recompile.

• Sources/BitRooUI — new shared SwiftUI layer (PanelView, AppModel). Both platforms draw the panel from one implementation; the panel is the product.
• ios/ — XcodeGen target following apps/Tyrell/ios. Bundle ID com.eastcoastscience.BitRoo, identical to macOS (a .mobile suffix forecloses universal purchase). The generated .xcodeproj is gitignored; project.yml is the source of truth.

Two findings worth keeping

1. bitROO's .iOS(.v17) was fiction. Declared since 2026-08-22, it could never have built: ECSSystem requires 18.0. It survived because no iOS target existed to test it — a platform you never build for cannot fail. Floor moved to 18.0, the minimum the dependency permits. Per lib/CLAUDE.md ("consumers raise the floor; the library never does") bitROO moved, not ECSSystem. NOT raised to the fleet's stated iOS 27.0 — that drops devices and is Rich's call (DEC-20260915-01, still open).

2. ECSSystem advertised .iOS(.v18) it could not compile. ProcessSupervisor.swift used Foundation.Process, which does not exist on iOS. Two leaks, not the one my ticket first estimated — the second only appeared after fixing the first:

Fixed upstream, per TASK-20260830-02, rather than worked around in bitROO. The change is purely additive — 12 lines inserted, zero removed — so on macOS the preprocessor yields identical source. That is exactly why the test counts are unchanged.

Verification — counts and controls, not "green"

ECSSystem  before: 72 XCTest + 53 swift-testing = 125, 0 failures
ECSSystem  after : 72 XCTest + 53 swift-testing = 125, 0 failures   (identical)
consumers spot-built rc=0: procreap, KeyRingScope, bitROO  (33 consumers total)

iOS  xcodebuild -destination 'generic/platform=iOS Simulator' clean build -> BUILD SUCCEEDED
     262 compile tasks on a CLEAN build   <- a no-op build also exits 0; the count is the evidence
     vtool -show-build -> platform IOSSIMULATOR, minos 18.0, sdk 27.0
     simctl install + launch on iPhone 18 Pro -> PID 33101, STAT=Rs, no crash report
     screenshot captured and VISUALLY INSPECTED: FLEET scene renders, picker and token help correct

macOS  make_app.zsh -> "architectures ok: x86_64 arm64", TeamIdentifier=ZU2882L4HT
       swift test -> 10 tests, 0 failures

I used an explicit -destination and a clean build deliberately: swift build --triple …ios… prints "Build complete!" while emitting no iOS product, xcodebuild without -destination silently resolves to "My Mac", and an incremental xcodebuild prints BUILD SUCCEEDED having compiled nothing. vtool is what actually proves the binary is for iOS.

Still not true, and labelled as such

BitRoo has never talked to real hardware. No Tidbyt token exists; discover/push are written from spec and unexercised; Tronbyt has never been pointed at a server; ESP32 is a Display.Kind case and nothing more. The iOS app has run only in Simulator, never on a physical iPhone. On-device token entry does not exist. The iOS fleet scene reads ~/dev/data/fleet.json, which no phone has, so it shows "no probe data" by design — do not read a populated fleet scene on a phone as evidence anything is wired up. All recorded in bitROO's new SESSION-STATE.md and its corrected STATUS.md.

Outstanding owner actions

• DEC-20260915-01 needs Rich: iOS floor is 18.0 (dependency minimum) vs the fleet's stated 27.0. Raising drops devices.
• Remaining epic children are open and unstarted: FEAT-20260915-02 scenes, FEAT-20260915-03 Tidbyt catalog (licence check first), SPIKE-20260915-01 ESP32 (research only — no device is to be flashed by an agent).

No secrets, credentials, tokens, or signed URLs appear in this record.