Apple Internals: Swift in the Kernel - by Josh Maine

Calif

SubscribeSign in

Apple Internals: Swift in the Kernel<br>A new series reverse-engineering Apple's internals.

Josh Maine<br>Jun 18, 2026

Share

After WWDC, I saw Devon Maloney posted a slide saying Apple has “started writing parts of the core operating system kernel in Swift” for the 27 releases. First steps toward a memory-safe kernel. What does this even mean?!<br>Naturally I dropped what I was doing and went grepping through the iOS 27 kernelcache. Alas, nothing came of it. All is not lost though: I found the Embedded Swift runtime in macOS 27, sitting in com.apple.kec.pthread of all places. Then I went poking around the root filesystem and it turns out Apple gave the whole effort a name: KernelKit.<br>Let's dissect it.

Where this is going: the C/C++ core (Mach, BSD, IOKit) is untouched. Swift shows up only as a small Embedded runtime inside specific KernelKit kexts at the extension layer.<br>A new directory in /System

On the macOS 27 root volume (26A5353q), right next to /System/DriverKit, are two kexts:<br>/System/KernelKit/<br>└── System/Library/Extensions/<br>├── Libm.kext/<br>│ ├── Libm<br>│ ├── Libm_kasan<br>│ └── Info.plist<br>└── pthread.kext/<br>├── pthread<br>├── pthread_development<br>├── pthread_kasan<br>└── Info.plist

The Info.plist for the pthread one is where it gets fun:<br>"CFBundleSupportedPlatforms" => ["KernelKit.MacOSX"]<br>"DTPlatformName" => "kernelkit.macosx"<br>"DTSDKName" => "kernelkit.macosx27.0.internal"<br>"DTXcode" => "2700"

And version.plist:<br>"ProjectName" => "libpthread_kernelkit"<br>"BuildAliasOf" => "libpthread"

So there's an internal SDK called kernelkit.macosx27.0.internal, and libpthread_kernelkit is a separate Xcode target building from the same libpthread sources as the regular kext. Libm gets the same treatment: ProjectName: Libm_kernelkit.<br>If this is giving you DriverKit déjà vu, you are on to something: its own directory under /System, its own SDK, its own Mach-O platform constant, the same playbook seven years later.<br>New Mach-O platform IDs

The LC_BUILD_VERSION for these binaries says:<br>cmd LC_BUILD_VERSION<br>platform 25<br>minos 27.0<br>sdk 27.0

The Mach-O platform enum currently goes up to 24 (visionOSExclaveKit). Nothing in public headers, LLVM, or loader.h knows what 25 is yet; ipsw just printed Platform(25) until I went and added the constants.<br>Then I checked the iOS 27 kernelcache's pthread kext, expecting the boring old absence of LC_BUILD_VERSION that iOS 26 had:<br>LC_BUILD_VERSION Platform: Platform(26), MinOS: 27, SDK: 27

That's notable for two reasons. LC_BUILD_VERSION is the stamp a Mach-O carries to record which OS it was built for, and Apple tracks each one by a number rather than a name. Last year's iOS 26 build of this kext had no such stamp at all, so its mere presence here is new. And the number is 26 , not the 25 macOS reported a moment ago. Apple could have filed every OS's kernel-Swift code under one shared platform, but instead each OS gets its own: macOS is 25, iOS is 26, with the rest in the table below.<br>To get the actual names I pulled the table out of the Xcode 27 beta linker. ld keeps a static array of 96-byte platform descriptors (from Platform.cpp); the uint32 ID sits at offset +0x20 in each. Calibrated against the known entries 23/24 (visionOS-exclaveCore/Kit), the six new ones are:<br>| ID | name (from `ld` @ `0x1001c67c8`+) |<br>|----|-----------------------------------------------|<br>| 25 | `macOS-kernelKit` |<br>| 26 | `iOS-kernelKit` |<br>| 27 | `tvOS-kernelKit` |<br>| 28 | `watchOS-kernelKit` |<br>| 29 | `visionOS-kernelKit` (alias `xrOS-kernelKit`) |<br>| 30 | `bridgeOS-kernelKit` |

The table ends at 30. All six are new in the 27 train; iOS 26.6's pthread kext (libpthread-539) has no LC_BUILD_VERSION at all. 25 and 26 are the only ones I've seen in shipping binaries so far.<br>The Xcode beta toolchain already knows

TargetConditionals.h has no TARGET_OS_KERNELKIT, and there's no KernelKit.platform under Contents/Developer/Platforms/. But cstrings from the toolchain binaries provide some more clues:<br>ld:

macOS-kernelKit<br>iOS-kernelKit<br>tvOS-kernelKit<br>watchOS-kernelKit<br>visionOS-kernelKit<br>bridgeOS-kernelKit<br>/System/KernelKit/usr/lib<br>/System/KernelKit/usr/lib/swift<br>/System/KernelKit/System/Library/Frameworks<br>kernelKit can only be used with -r, -kext and -static

tapi and swift-frontend:

TARGET_OS_KERNELKIT<br>environment kernelkit<br>kernelkit_osx kernelkit_ios kernelkit_tvos<br>kernelkit_watchos kernelkit_bridgeos kernelkit_xros

Six per-OS variants. bridgeOS gets one, because apparently the Touch Bar needs in-kernel Swift before iOS does. There's a TARGET_OS_KERNELKIT preprocessor conditional. The linker hard-codes /System/KernelKit/usr/lib/swift as a search path, which tells you where the in-kernel Swift stdlib is going to live once it grows past what's statically baked into pthread today. And the ld error string kernelKit can only be used with -r, -kext and -static confirms there's no dylib or executable output, just kext bundles and object files.<br>The linker,...