From f436db106c802b2107e0eae68900536b5fb6efb3 Mon Sep 17 00:00:00 2001 From: jcant0n Date: Sun, 9 Aug 2026 15:00:24 +0200 Subject: [PATCH] docs: say what each platform check is actually worth The list was ten ticks and nothing else, which reads as ten platforms verified equally. They are not, and three of them are not verified at all. Seven are checked against the real .nupkg before publishing: five desktop identifiers and wasm drop a sphere onto a floor through the library, and the iOS simulator is linked and its executable inspected for defined entry points. ios-arm64 is indirect, because a device build needs a signing identity CI does not have. Both android identifiers are not checked at all -- they are ordinary shared libraries and nothing installs the package on Android today. A reader deciding whether to ship on a platform should be able to see which of those they are getting. The android row in particular is a gap worth advertising rather than leaving for somebody to discover. --- README.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/README.md b/README.md index bc026d8..331bbb5 100644 --- a/README.md +++ b/README.md @@ -31,6 +31,23 @@ This repository contains low-level bindings for [JoltPhysics](https://github.com - [x] iOS Simulator ARM64 - [x] Browser WASM +Ten runtime identifiers ship. Seven of them are checked against the real `.nupkg` before a +release is published, and a failure stops the publish. What that check is worth differs, and the +difference is worth knowing rather than glossing: + +| | how it is checked | +|---|---| +| the five desktop identifiers | the package is installed and a sphere is dropped onto a floor through the native library, which has to fall, settle, and settle *on* the floor | +| `browser-wasm` | the same, under node, against the archive linked into the application at publish time | +| `iossimulator-arm64` | an application is linked against the package and its executable has to **define** the entry points, not merely reference them | +| `ios-arm64` | **not verified directly.** A device build needs a signing identity CI does not have. It links the same archive through the same targets file as the simulator, so the evidence is indirect | +| `android-arm`, `android-arm64` | **not verified.** They are ordinary shared libraries loaded the way the desktop ones are, but nothing installs the package on Android today | + +iOS works differently from every other identifier and you do not have to do anything about it: +Apple only lets an application load dynamic libraries that ship inside its own bundle, so the +package carries a static archive and a `buildTransitive` targets file links it into your +application at build time. + ## Development ### Generate bindings locally