fix(ios): drop the android-only default flavor when building the ipa

[ethicnology]

pubspec sets default-flavor: production for the Android product flavors, but Flutter resolves it on every platform (flutter_command.dart: cliFlavor ?? defaultFlavor). flutter build ipa therefore looked for a Production scheme, which the iOS project does not define — it has a single Runner scheme and only Debug/Release/Profile configurations — and aborted with the misleading 'You must specify a --flavor option to select one of the available schemes', listing the virtual SwiftPM package schemes as if they were flavors.

Strip the key for the duration of the build and restore it on any exit path, so local iOS builds stop needing the manual edit. appFlavor becomes null instead of 'production'; the app reads it only to draw the beta banner, so production behaviour is unchanged.

Broken by 50baefd, which added the key; the iOS release workflow never reached this step before today.

[claude]

Claude finished @ethicnology's task in 2m 35s —— View job

---

Review of PR #2673 — drop android-only default flavor for iOS ipa builds

• Gather context (diff, makefile, pubspec)
• Review for correctness bugs, security issues, regressions
• Post review summary

Verdict: the change is correct. No security issues, no regressions. I verified each claim in the PR description against the code; one minor cosmetic nitpick below. (Note: I can only update this single comment, so findings are posted here rather than as inline review comments.)

What I verified

• The grep pattern matches the actual key. default-flavor: production sits indented under flutter: at pubspec.yaml:182, and '^[[:space:]]*default-flavor:' (makefile:115) matches it. Comment lines mentioning the key start with # and are not stripped.
• No behavioral regression from appFlavor becoming null. appFlavor is read in exactly one place, lib/main.dart:360 (if (appFlavor != 'beta') return app;), so null behaves identically to 'production' — the beta banner stays off. The PR description's claim holds.
• Failures propagate. If flutter build ipa fails, the EXIT trap restores pubspec.yaml but POSIX shells preserve the pre-trap exit status, so make still fails with the build's status. The restore-on-any-exit-path design works.
• Read-from-backup avoids the classic self-redirect bug. grep -v ... "$$backup" > pubspec.yaml reads the copy, not the file being truncated. > pubspec.yaml also keeps the original file's inode/permissions.
• No injection surface. BUILD_NUMBER is validated as a positive integer (makefile:103) before being interpolated into the build command, and mktemp is used safely.
• The mid-recipe comment block (makefile:105-112) is valid GNU make — column-zero comment lines among recipe lines are ignored, and the shell command is one continued line so the trap stays in scope for the flutter invocation.

Minor nitpick (cosmetic)

Double restore on Ctrl‑C — makefile:114 traps EXIT INT TERM with the same handler. On SIGINT the INT trap runs (restores pubspec, deletes the backup), then the shell exits and the EXIT trap fires again; its cp "$backup" pubspec.yaml now fails with a spurious cp: ... No such file or directory message. Harmless — pubspec is already restored and the exit status is unaffected — but a guard makes it clean:

trap '[ -f "$$backup" ] && cp "$$backup" pubspec.yaml; rm -f "$$backup"' EXIT INT TERM

Fix this →

One observation, not a defect: if someone edits pubspec.yaml while the multi-minute build runs, the restore silently overwrites their edits. Given this is a local release command, that seems acceptable.

---