Skip to content

iOS

Native iOS (Xcode) projects.

For an iOS project, alphyn-cli integrate:

  1. Resolves the framework from the Alphyn package registry. It generates a small local Swift package whose single binaryTarget points at Alphyn.xcframework in the registry, pinned to the SHA-256 the SDK manifest publishes. Nothing is downloaded or vendored into your project.
  2. Wires the Swift package into your Xcode project so the app target links the Alphyn product; Swift Package Manager fetches and verifies the framework against the pinned checksum at build time.
  3. 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.
  4. Adds the launch hook: inserts the SDK initialization into your AppDelegate (or your @main App entry point).
  5. 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.
  6. 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).

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:

Terminal window
xcodebuild -project <App>.xcodeproj -scheme <AppScheme> -configuration Release \
-destination 'generic/platform=iOS' archive -archivePath build/App.xcarchive

As 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.

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:

Terminal window
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:

Terminal window
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.

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.

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.