Repository navigation
Validate KernelRace iOS build (PR #32) on real Xcode + device/simulator #33
Description
Context
PR #32 added iosArm64/iosSimulatorArm64 targets to KernelRace's
shared/composeApp modules, plus a hand-authored iosApp/ Xcode project
shell (SwiftUI entry point embedding the Kotlin/Native framework via
embedAndSignAppleFrameworkForXcode).
None of it could be built or run in the session that produced it — that
environment was Linux only, with no Xcode/macOS available at all. Verification
there was limited to: non-Apple targets (jvm/android/wasmJs) still compiling
after the change, and structural checks on the Xcode project files (balanced
.pbxproj braces, valid Info.plist/Contents.json). The .xcodeproj itself
has never been opened in Xcode.
What needs a Mac
-
open iosApp/iosApp.xcodeproj— confirm Xcode accepts the hand-authored project file without a "project format" repair prompt/error. This is the highest-risk item:.pbxprojis easy to get subtly wrong by hand. - Build the
iosAppscheme for a simulator (⌘R) — confirm the "Compile Kotlin Framework" run-script phase (:composeApp:embedAndSignAppleFrameworkForXcode) actually finds and embeds the framework. - Build + run on a real device.
- Confirm the app launches,
IosModelProviderdownloads/caches the GGUF (or picks up a bundled asset), and generation actually produces output — the Ktor Darwin download path (shared/src/iosMain/.../IosModelProvider.kt) has never executed. - Confirm the
PlatformChipsrow highlights "iOS" correctly at runtime (compiled but never rendered). - Add a real 1024×1024 app icon —
Assets.xcassets/AppIcon.appiconsetis currently an empty slot.
Related
- Added by feat(KernelRace): add iOS, platform chips, and fix the broken Wasm build #32
- The kernel tier this build dispatches to depends on
SKaiNET-transformers#316:
until that lands in a release, this app will run correctly but on the
scalar kernel floor rather than the Applenative-cinteropNEON/Accelerate
path — worth checking both together, since #316's real device/simulator
validation is a natural companion to this one.
Good fit for whoever on the team has a Mac + Xcode handy.
Activity
michalharakal commentedon Aug 13, 2026
Engine-side tracking issue for the underlying Apple native-cinterop kernels this whole chain depends on: SKaiNET#979.
michalharakal commentedon Aug 13, 2026
Worth stating explicitly why this one matters more than a routine "does it build" check:
KernelRace exists to prove how easy it is to build apps with SKaiNET — including on iOS, not just to exercise the engine. The entire iOS-specific surface added for it is ~200 lines across 4 files, and the one that actually calls into SKaiNET (
LlamaRuntimeBuilder.ios.kt) is 36 lines, nearly a line-for-line copy of the JVM actual. No engine code changed to make iOS work — the KMP targets and Applenative-cinteropkernels were already there.So when validating this on a Mac, the bar isn't just "it compiles and runs" — it's "does the ease-of-use story hold up": does a real device build genuinely just work off this small amount of glue, with no surprise iOS-specific hacks needed? That's the actual claim being tested here.