fix(ci): fix iOS release workflow provisioning profile and build number

[Chibuzor-Nwemambu]

Summary

This PR fixes two issues that were blocking the build-release-ios workflow from successfully building and uploading the Storybook app to TestFlight, and adds encryption compliance configuration to avoid manual answers on every App Store submission.

1. UUID extraction fails on macos-26 runner

The original step used security cms -D to decode the provisioning profile and extract the UUID:

UUID=$(security cms -D -i "$PROFILE" | /usr/libexec/PlistBuddy -c "Print :UUID" /dev/stdin)

On the macos-26 runner, security cms -D consistently fails with Cannot parse a NULL or zero-length data, even though the provisioning profile file is valid (12 KB, correct content). The root cause is unclear — likely a runner-level compatibility issue with the Security framework on macOS 26.

Fix: Extract the UUID by grepping the raw binary directly. The UUID is stored as plain ASCII within the CMS envelope, so this works reliably without needing to decode the CMS wrapper:

UUID=$(grep -aEo '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}' "$PROFILE" | head -1)

Note: the pattern uses [0-9a-fA-F] (case-insensitive) because Apple provisioning profiles use lowercase UUIDs. An uppercase-only pattern returns no match.

2. patch-files-action fails because buildNumber field is missing

The workflow patches app.json to set the build number before archiving:

= /expo/ios/buildNumber => "${{ env.BUILD_NUMBER }}"

The patch-files-action requires the field to already exist at the target path — it cannot create new fields. Since ios.buildNumber was absent from app.json, the patch step failed with OPERATION_PATH_UNRESOLVABLE.

Fix: Added "buildNumber": "1" as a placeholder to app.json. The value is overwritten on every CI run and never used as-is.

3. Encryption compliance key added to app.json

Added ITSAppUsesNonExemptEncryption: false to the ios.infoPlist section of app.json. This tells Apple the app uses no exempt encryption algorithms, skipping the manual compliance questionnaire on every future App Store and TestFlight submission.

Added via app.json rather than directly in Info.plist so it is applied automatically on every expo prebuild run and cannot be accidentally wiped.

Test plan

• Triggered workflow manually via workflow_dispatch on this branch
• Build completed successfully end-to-end
• IPA uploaded and appeared in App Store Connect TestFlight within minutes

[Chibuzor-Nwemambu]

@claude review

[claude]

Claude finished @Chibuzor-Nwemambu's task in 1m 19s —— View job

---

Code Review — PR #197

• Read PR diff and changed files
• Review UUID extraction change
• Review app.json buildNumber change
• Review package.json script rename
• Post review feedback

---

Overall this is a solid, well-documented fix. The PR description does a great job explaining the why behind each change, and the test plan (full workflow run → TestFlight) gives real confidence. Two of the three changes are clearly correct; the third has a documentation ripple effect worth addressing.

🔴 package.json rename breaks documented commands (and is out of scope)

.github/.../package.json renames dev:storybook → storybook:

-    "dev:storybook": "turbo run dev --filter @equinor/mobile-storybook",
+    "storybook": "turbo run dev --filter @equinor/mobile-storybook",

This rename is unrelated to the iOS release fix that the PR is about, and more importantly it leaves 8 stale references to pnpm dev:storybook across the repo's docs, all of which now point to a script that no longer exists:

• CLAUDE.md:30
• README.md:152, README.md:179
• packages/components/CLAUDE.md:168
• apps/storybook/CLAUDE.md:18
• apps/storybook/README.md:31, apps/storybook/README.md:50, apps/storybook/README.md:102

Anyone following the README/CLAUDE quickstart will hit Command "dev:storybook" not found. Two options:

1. Update the docs to use pnpm storybook (matches the "easier to run" intent), or
2. Keep both — add "storybook" as an alias while leaving "dev:storybook" in place, so existing docs/muscle-memory keep working.

I'd lean toward updating the docs since the rename is intentional. Fix this →

Consider splitting this rename into its own PR so the CI fix stays focused — but not a blocker.

🟡 UUID grep relies on head -1 (minor robustness)

UUID=$(grep -aEo '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}' "$PROFILE" | head -1)

The grep-the-raw-binary approach is a pragmatic workaround for the security cms -D failure on macos-26, and in practice the profile's UUID key is the only canonical 8-4-4-4-12 string in the envelope (cert serials/key IDs are raw binary, not hyphenated ASCII), so head -1 should reliably land on it. The fragility is that it's positional rather than keyed — if a future profile ever embeds another UUID-formatted value (e.g. in entitlements), head -1 could grab the wrong one silently.

Two cheap hardenings if you want belt-and-suspenders:

• Add a guard so the build fails loudly instead of proceeding with an empty/wrong UUID:

  if [ -z "$UUID" ]; then echo "::error::Failed to extract UUID from provisioning profile"; exit 1; fi

• Or anchor to the key, e.g. extract the plist slice and read :UUID with PlistBuddy from the decoded XML range — but that reintroduces decode complexity, so the guard alone is probably the better cost/benefit.

Not blocking given the successful end-to-end run.

✅ app.json buildNumber placeholder — correct

-            "bundleIdentifier": "com.equinor.eds.mobile"
+            "bundleIdentifier": "com.equinor.eds.mobile",
+            "buildNumber": "1"

This is exactly right: patch-files-action does an in-place = replace and can't create missing paths, so seeding ios.buildNumber is required for the OPERATION_PATH_UNRESOLVABLE fix. The value is overwritten each run by the Patch app.json step, so the placeholder is harmless. Good catch on the root cause.

✅ Debug echo

The added echo "Extracted UUID: $UUID" is a nice, low-cost aid for diagnosing future signing issues. 👍

---

Summary

Change	Verdict
app.json buildNumber placeholder	✅ Correct
UUID grep extraction	✅ Works; consider an empty-value guard
package.json rename	🔴 Update the 8 stale dev:storybook doc references (or alias)

The core CI fix is good to go. The main thing I'd resolve before merge is the doc drift from the script rename.

Note: I can review and comment, but I can't modify files under .github/workflows/ (GitHub App permission), so I haven't applied any changes — this is review feedback only.
· fix/iOS-release-workflow-debug

[Chibuzor-Nwemambu]

Added an empty-value guard after the UUID extraction (line 64). The concern isn't that head -1 is unreliable; provisioning profiles are Apple-generated and the UUID key is structurally first. The real risk is a misconfigured secret or a silent base64 decode failure producing an empty $UUID. Without the guard, that propagates silently: PlistBuddy writes an empty string to ExportOptions.plist and xcodebuild gets PROVISIONING_PROFILE="", both failing later with errors that don't point back here. The guard surfaces the real failure immediately.

Also updated 8 doc references from pnpm dev:storybook to pnpm storybook to match the earlier script rename.

[HaakonSvane]

🔥

[HaakonSvane]

✅