You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
xcframework: CI, rolling release, arm64-only simulators, docs
Follow-up polish on the fork's Apple-platform build:
1. CI workflow (.github/workflows/fork-xcframework-release.yml)
Rebuilds the xcframework on push to master, weekly, and on-demand.
Uploads a zip as a 30-day Actions artifact and publishes to a
rolling "latest" prerelease so downstream consumers can curl
a prebuilt framework without cloning the repo.
2. Drop x86_64 from iOS/visionOS/tvOS simulator slices
Every modern Xcode Simulator runs arm64-on-arm64 on Apple Silicon.
The x86_64 sim slice was dead weight — halves simulator build times
and binary size. macOS keeps the Intel slice since real Intel Macs
are still in use. Slice names change from e.g.
"ios-arm64_x86_64-simulator" to "ios-arm64-simulator".
3. README: codesigning section
Documents that the xcframework ships unsigned on purpose and that
consumers must set "Embed & Sign" in Xcode. Prevents the common
mistake of pre-signing before embedding, which archive validation
rejects.
4. README: prebuilt download section
Points consumers at the rolling "latest" release from (1) instead
of making them build from source.
5. .gitignore: /.claude/
Prevents accidental commits of Claude Code workspace state.
Sanity-verified locally by reconfiguring and building the arm64-only
iOS simulator slice — libllama.a / libggml-metal.a produced as
non-fat arm64 archives.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+29-4Lines changed: 29 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,6 +26,17 @@ CMake Error at ggml/src/ggml-cpu/CMakeLists.txt:57 (target_compile_features):
26
26
27
27
The failure reproduces against `upstream/master`, verified 2026-04-15. Ninja bypasses it entirely because it does not rely on Xcode's toolchain detection for cross-SDK builds. The resulting xcframework is equivalent — the Xcode-specific `-DCMAKE_XCODE_ATTRIBUTE_*` arguments in `COMMON_CMAKE_ARGS` are harmless no-ops under Ninja, so they were left alone rather than stripped.
28
28
29
+
## Downloading a prebuilt xcframework
30
+
31
+
GitHub Actions rebuilds the xcframework on every push to `master` and on a weekly schedule. The latest artifact is attached to a rolling prerelease tagged `latest`:
Drag `llama.xcframework` into your Xcode project's *Frameworks, Libraries, and Embedded Content* section. Each workflow run also uploads the zip as a 30-day Actions artifact if you need a specific build.
Simulator slices are **arm64-only** — every modern Xcode Simulator runs arm64-on-arm64 on Apple Silicon. The x86_64 simulator slice has been dropped to halve simulator build times and binary sizes. macOS keeps the Intel slice since real Intel Macs are still in use.
46
59
47
60
Mac Catalyst is **not** in the xcframework — CMake's cross-compile flags conflict when combining both Catalyst architectures in a single configure step. See [APPLE-PLATFORMS-BUILD.md](APPLE-PLATFORMS-BUILD.md) for the manual lipo workflow.
48
61
@@ -64,7 +77,7 @@ CMake Warning at ggml/src/ggml-cpu/CMakeLists.txt:558 (message):
64
77
Unknown CPU architecture. Falling back to generic implementations.
65
78
```
66
79
67
-
This is **not** a Metal fallback. It fires only when x86_64 is part of the architecture list (iOS sim, macOS, visionOS sim, tvOS sim) and means the x86_64 **CPU backend** slice uses generic scalar kernels instead of AVX/AVX2. The arm64 CPU backend and the Metal backend are unaffected. For shipping on Apple Silicon devices this warning is cosmetic — no one runs production inference on an x86_64 simulator.
80
+
This is **not** a Metal fallback. It fires only when x86_64 is part of the architecture list (now just the `macos-arm64_x86_64` slice) and means the x86_64 **CPU backend** slice uses generic scalar kernels instead of AVX/AVX2. The arm64 CPU backend and the Metal backend are unaffected. For shipping on Apple Silicon devices this warning is cosmetic.
68
81
69
82
### Requirements
70
83
@@ -100,6 +113,18 @@ Reference numbers from the 2026-04-15 verification (SmolLM2-135M-Instruct Q4_K_M
100
113
101
114
The xcframework slices contain identical Metal backend code — same `_ggml_metallib_start`/`_end` symbols, same 110 kernels — so a working host Metal build is a reliable proxy for the framework slices.
102
115
116
+
## Code signing
117
+
118
+
**The xcframework is unsigned.**`build-xcframework.sh` sets `CODE_SIGNING_ALLOWED=NO` on purpose — a redistributable framework must not carry its own signature, because the consuming app has to re-sign embedded binaries with its own Team ID at archive time. This is the expected pattern for distributing a third-party `.xcframework`.
119
+
120
+
When you embed `llama.xcframework` in an Xcode project:
121
+
122
+
- In the *Frameworks, Libraries, and Embedded Content* section, set *Embed* to **Embed & Sign**. Xcode will sign the embedded `llama.framework` with your app's signing identity during the build.
123
+
- No action needed in your entitlements — the framework uses only public `Metal.framework` / `Accelerate.framework` APIs.
124
+
- For distribution outside the App Store (Developer ID / notarization), the framework will be signed and notarized as part of your app's archive, not separately.
125
+
126
+
If Xcode refuses to build with a signature error, the fix is almost always switching *Embed* from *Do Not Embed* to *Embed & Sign*. Do **not** pre-sign the framework with `codesign` before embedding — that produces nested signatures that archive validation rejects.
0 commit comments