macOS Hardened Runtime Required for CoreText Emoji Rendering

hardened-runtime-emoji-crash.md

macOS Hardened Runtime Required for CoreText Emoji Rendering

Problem

On Apple Silicon Macs (ARM64), binaries signed without hardened runtime crash with SIGBUS (EXC_BAD_ACCESS / EXC_ARM_DA_ALIGN) when CoreText attempts to render bitmap emoji glyphs (sbix table). The crash occurs inside Apple's ImageIO framework:

IIOReadPlugin::callInitialize()
  → CopyEmojiImage()
  → CTFontDrawGlyphs()

The faulting address is 0x0bad4007 — a deliberate sentinel/poison pointer, indicating an internal initialization check failed inside IIOReadPlugin.

Affected Scenario

Any macOS app that calls CTFontDrawGlyphs (or the Objective-C equivalent -[NSFont drawGlyphs:...]) to rasterize emoji will crash if:

1. The binary is signed without --options runtime (no hardened runtime flag)
2. The glyph being rendered is a bitmap emoji from the Apple Color Emoji font (sbix format)

This affects Rust apps using CoreText FFI, Objective-C apps, Swift apps — anything that renders emoji through CoreText without hardened runtime.

Diagnosis

The codesign flags can be inspected with:

codesign -dvvv /path/to/binary 2>&1 | grep flags

• flags=0x0(none) — will crash on emoji rendering
• flags=0x10000(runtime) — works correctly

Fix

Sign the binary with --options runtime:

codesign --force --options runtime \
  --entitlements /path/to/entitlements.plist \
  --sign "Developer ID Application: ..." \
  /path/to/YourApp.app

Minimum entitlements needed (if your app uses JIT or unsigned memory):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
</dict>
</plist>

Ad-hoc signing (--sign -) with --options runtime may also work but has not been extensively tested.

Notes

• Observed on macOS 15.7.4 (Sequoia) with Xcode 26.2 on Apple M-series chips
• The crash does not occur when the app is launched via LaunchServices (open command or Finder), even without hardened runtime — LaunchServices appears to provide equivalent process context
• The crash only manifests when the binary is executed directly (e.g. ./MyApp or cargo run during development)
• This appears to be a bug in Apple's ImageIO plugin initialization that assumes capabilities only present with hardened runtime or LaunchServices context

Environment

• macOS 15.7.4 (Darwin 24.6.0)
• Apple Silicon (ARM64)
• Xcode 26.2 / SDK 26.2