docs: macOS native module signatures in README and 4.7.2 changelogs

Author: ndonkoHenri

src/serious_python/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.7.2
+
+* **macOS:** fix App Store Connect rejecting Xcode-distributed builds with `90238: Invalid signature … does not satisfy its designated Requirement` on bundled `.so` files ([#250](https://github.com/flet-dev/serious-python/issues/250)). Linker-signed native modules are re-signed ad-hoc while they are staged, so Xcode's distribution signing gives them valid signatures. See `serious_python_darwin` 4.7.2.
+
 ## 4.7.1
 
 * Fix macOS crashes during native scientific imports and NumPy operations by giving the asynchronous Python worker at least **8 MiB** of stack space, via `dart_bridge` 1.10.0. ([dart-bridge#21](https://github.com/flet-dev/dart-bridge/pull/21), [#85](https://github.com/flet-dev/serious-python/issues/85))

src/serious_python/README.md

@@ -319,6 +319,20 @@ produces a working app, but it cannot produce complete SDK-origin receipts. **Us
 the SwiftPM path for App Store submissions** until that path is replaced with real
 vendored XCFramework declarations.
 
+#### macOS native module signatures
+
+On macOS, the native modules under `stdlib/`, `site-packages/` and `app/` ship as
+plain `.so`/`.dylib` files, which Xcode's distribution signing (the Organizer or
+`xcodebuild -exportArchive`) re-signs with your certificate along with the rest of
+the app. A module carrying the signature the linker gave it comes out of that
+step with a designated requirement naming a different identifier than its new
+signature: codesign does not carry a linker signature's identifier over, but Xcode
+can build the requirement from it. App Store Connect rejects such an upload with
+error 90238 ("does not satisfy its designated Requirement"). The macOS build
+therefore replaces linker signatures with regular ad-hoc ones while staging these
+trees. The `SERIOUS_PYTHON_SITE_PACKAGES` and `SERIOUS_PYTHON_APP` directories
+themselves are left unchanged.
+
 ### Linux / Windows specifics
 
 The CPython runtime (`libpython3.so` + `libpython<X.Y>.so` on Linux; `python3.dll` + `python<XY>.dll` on Windows), `libdart_bridge`, the stdlib, and native modules are copied next to your app's executable at build time. `PYTHONHOME` is the executable's directory. On Windows, extension modules (`.pyd`) and their dependent DLLs live in `<exe-dir>/DLLs/`, which is added to `sys.path`.

src/serious_python_darwin/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.7.2
+
+* **macOS: bundled native modules pass App Store Connect's signature check after Xcode distribution signing** ([#250](https://github.com/flet-dev/serious-python/issues/250)). The stdlib `lib-dynload` modules and many wheel extensions (e.g. Pillow's `_imagingmorph`) arrive with the linker's ad-hoc signature, whose identifier is the file name including `.so`. When Xcode re-signs them for distribution (Organizer, `xcodebuild -exportArchive`), `codesign` cannot carry that identifier over and derives one without the extension, while Xcode can write the designated requirement from the old one, so App Store Connect rejected the upload with `90238: Invalid signature … does not satisfy its designated Requirement`. The macOS staging now re-signs every still-linker-signed `.so`/`.dylib` ad-hoc: `prepare_macos.sh` for the stdlib, `sync_site_packages.sh` for site-packages and the app. A regular ad-hoc signature's identifier survives re-signing, so the requirement and the signature agree. `SERIOUS_PYTHON_SITE_PACKAGES`, `SERIOUS_PYTHON_APP` and the provider XCFrameworks are not modified. CI now fails the macOS example build if a linker-signed library reaches the app bundle.
+
 ## 4.7.1
 
 * Fix macOS crashes during native scientific imports and NumPy operations by giving the asynchronous Python worker at least **8 MiB** of stack space, via `dart_bridge` 1.10.0. ([dart-bridge#21](https://github.com/flet-dev/dart-bridge/pull/21), [#85](https://github.com/flet-dev/serious-python/issues/85))