iOS
Native iOS (Xcode) projects.
integrate
Section titled “integrate”For an iOS project, alphyn-cli integrate:
- Resolves the framework from the Alphyn package registry. It generates a small local Swift
package whose single
binaryTargetpoints atAlphyn.xcframeworkin the registry, pinned to the SHA-256 the SDK manifest publishes. Nothing is downloaded or vendored into your project. - Wires the Swift package into your Xcode project so the app target links the
Alphynproduct; Swift Package Manager fetches and verifies the framework against the pinned checksum at build time. - Merges
Info.plist: adds the keys the SDK requires (including the attestation-host ATS exception), preserving any values your app already declares. The merge is byte-preserving and fully reversible. - Adds the launch hook: inserts the SDK initialization into your
AppDelegate(or your@mainApp entry point). - Installs the archive post-action into each shared scheme that archives the app, creating the app’s shared scheme when the project has none. This is the step that registers a build: at archive time it posts the build’s hash to the attestation backend. The signature host comes from the SDK manifest and is baked in safely; a cleartext or credential-bearing URL is refused rather than silently shipped into your app.
- Records the result in
alphyn.json.
Swift Package Manager authenticates to the registry host through your ~/.netrc, so add one line
(the CLI also prints it at the end of integrate), then resolve packages in Xcode. See
SDK Registry Access:
machine packages.byterialab.com login x password <YOUR_APP_API_KEY>If your build cannot reach the registry, embed the self-contained Alphyn.xcframework by hand
instead: see Manual XCFramework installation (offline).
register
Section titled “register”There is nothing to run manually on iOS. Builds register themselves at archive time through
the post-action integrate installed. integrate --ios-api-key <key> writes the key into a gitignored
.alphyn/ios-api.key file that the post-action reads automatically, so an archive registers with
no further setup; the key value never lands in the committed project. To override per build (for
example on CI), point the ALPHYN_IOS_API_KEY_FILE build environment variable at a key file. Run
alphyn-cli doctor to confirm the post-action is wired.
The archive does not require the Xcode UI: xcodebuild runs the same scheme post-action, so a
terminal or CI archive registers itself the same way:
xcodebuild -project <App>.xcodeproj -scheme <AppScheme> -configuration Release \ -destination 'generic/platform=iOS' archive -archivePath build/App.xcarchiveAs soon as the archive completes, its build signature appears in the dashboard. The usual archive requirements apply (signing identity and team); a simulator build is not an archive.
This automates the manual Register via Xcode Post-action flow: the CLI installs and retargets that post-action for you.
Development builds (iOS debug hash)
Section titled “Development builds (iOS debug hash)”During development the app’s hash changes on every build and is never registered (registration happens at archive time). Pin your app’s development debug hash from the dashboard (App Details) so simulator and device debug builds initialize the SDK:
alphyn-cli integrate --ios-api-key <key> --ios-debug-hash <64-hex>The hash is rendered into the #if DEBUG branch of the launch hook, so a release build never
carries it, and it is recorded in alphyn.json across re-runs. integrate also enrolls a
development build signature with the backend, which a dev build needs before its first archive;
SDK init in the dev loop then succeeds when the pinned hash matches the app’s dashboard debug
hash.
This enrollment needs no build and no archive: it is a pure CLI call, and the development
build signature appears in the dashboard as soon as it runs. register performs the same
enrollment, so once the hash is pinned you can re-ensure it at any time without a full
re-integrate; the pinned hash is recorded, so later runs need no flag:
alphyn-cli register --ios-api-key <key>The enrollment is idempotent (re-running it never creates a second row), and alphyn-cli doctor reports the development build signature as enrolled.
doctor
Section titled “doctor”Confirms the SDK resolves from the registry through the generated Swift Package (its binaryTarget
is wired into the Xcode project and its pinned checksum still matches the one recorded in
alphyn.json), the required Info.plist keys are present, the launch hook is present as real
code, and an app-archiving shared scheme carries the archive post-action. When a development debug
hash is pinned, it also reports whether the development build signature is enrolled on the backend
(advisory; it never fails the run). On a self-contained offline install it instead verifies the
embedded framework against the recorded checksum.
remove
Section titled “remove”Reverses the SDK wiring in the .pbxproj (the generated Swift Package reference, or the framework
embed on an offline install), reverses exactly the Info.plist keys and values it added, drops the
archive post-action it created (while preserving one you authored yourself), removes the launch
hook, deletes the generated Swift package or vendored framework, and removes alphyn.json.