ann-flavor-cocoapods 0.4.6 → 0.4.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0753376f0ddae76a1894acb795e3e1cac3f6a975a79b799e0cccc79c9db2760b
-  data.tar.gz: cc9c6297e39a2702dc119975168fc92926eb2db5bdfc9c23ff44eb9076b8b568
+  metadata.gz: 0d456b989981f0e9a376250a86ef9938ae916032e121b89fd4117232303d0ece
+  data.tar.gz: f02019d7919198b23a805c0104912e106537dd9b136bd15c9d3c4f0f498dd109
 SHA512:
-  metadata.gz: 2b56c73fc8ced1dbd22e58e2780aded019fc5cf87e76ed6df5fac6ec6ab4650f4391e3707543147095df39b1342fa892a9c6699604cad1ce75daec906b7a37cb
-  data.tar.gz: 2c1dcff237aded83a87e68fe1b1d4869bd901d61c5703749307df2dd02ba91105fefdc62363fcc5d7b2dbb095bb09d491d5410b64456eced522e82a2255b9322
+  metadata.gz: fd843dc2cea6f16e286dc7a33c24bc88eb6993f44d0816e40f7eeac307075ef86766538ed29d51a1b922e01bedef9ee29403e3157d9eb923c76e22a475befdee
+  data.tar.gz: 1a193d4841e2968798c94e09704175cf45be1643a15a03038dbba4643eca7486a2fd5d071e431b5cdb836665a82a086fe8e7cccc6f4d5011cb75184a3572724d

data/CHANGELOG-TECHNICAL.md

@@ -0,0 +1,617 @@
+# Changelog
+
+## 0.4.7
+
+### Added
+- **`merge_info_plist`/`merge_entitlements` gain a genuine third merge
+  layer** — `ios/ann/Info/merged/plugin-contributions.plist`/
+  `ios/ann/Entitlements/merged/plugin-contributions.entitlements`, read as
+  a plain file with no knowledge of Flutter plugins or
+  `.flutter-plugins-dependencies` on this plugin's part — sitting between
+  the base (`Runner/Info.plist`/`Runner.entitlements`) and the flavor delta
+  in precedence. Companion fix to `ann-flavor-flutter` 1.7.1: that release
+  stops pre-merging plugin-contributed content into the per-flavor delta
+  file (which had silently changed that file's meaning) and writes it to
+  this new file instead, under the same `merged/` directory this plugin
+  already owns and already `.gitignore`s — this plugin now merges it as
+  its own layer so the final merged output is unchanged.
+- `merge_entitlements`'s "nothing to sign with" check now also considers
+  `plugin-contributions.entitlements` — a plugin-only contribution (no
+  stock `Runner.entitlements`, no flavor delta) now correctly produces
+  signed output instead of leaving `CODE_SIGN_ENTITLEMENTS` unset.
+
+## 0.4.6
+
+### Changed
+- **Info.plist and entitlements merging moved from a build-time
+  `PBXShellScriptBuildPhase` to plain Ruby code that runs during
+  CocoaPods' `post_integrate` hook (pod-install time).** 0.4.1-0.4.5
+  each narrowed the conditions under which the "Cycle inside Runner"
+  failure occurred, but deep research (Apple Developer Forums,
+  CocoaPods/CocoaPods#11133, several flutter/flutter issues, and the
+  `swift-build` source) confirmed the real cause: *any*
+  `PBXShellScriptBuildPhase` with declared `output_paths` feeding
+  `INFOPLIST_FILE`/`CODE_SIGN_ENTITLEMENTS` becomes a graph node XCBuild
+  must order relative to a shared `ModuleVerifierTaskProducer` gate that
+  framework-embed phases (CocoaPods and SPM alike) are also gated
+  behind — no `build_phases` position or `input_paths` declaration could
+  avoid it. The values these phases merged (flavor name, files already on
+  disk) are fully known at `pod install` time, so there is no need for a
+  build-time script phase at all — the same pattern CocoaPods' own
+  `Pods-Runner-Info.plist` already uses.
+- `[ann-flavor] Merge Info.plist` and `[ann-flavor] Merge Entitlements`
+  build phases are no longer injected, at all, for any project (new or
+  upgrading from 0.4.1-0.4.5's phases, which are removed).
+- Merged output is now written directly to
+  `ios/ann/Info/merged/<flavor>-<buildType>.plist` and
+  `ios/ann/Entitlements/merged/<flavor>-<buildType>.entitlements` — one
+  file per flavor **and build type** (previously one merged file per
+  flavor, always built from the `release`-level cascade regardless of
+  build type — see the matching `ann-flavor-flutter` 1.6.0 changelog
+  entry for the generator-side half of this fix).
+- `INFOPLIST_FILE`/`CODE_SIGN_ENTITLEMENTS` build settings now point
+  directly at these per-build-type merged files under `$(SRCROOT)`,
+  instead of a `$(DERIVED_FILE_DIR)/...-merged...` path produced by a
+  script phase.
+
+### Fixed
+- A stale merged entitlements file is now deleted when a flavor/build-type
+  combination that previously had entitlements to sign no longer does
+  (previously only the build setting was cleared; the stale file was left
+  on disk).
+
+## 0.4.5
+
+### Fixed
+- **0.4.4 stopped the cycle for a *fresh* install, but any project already
+  on 0.4.1-0.4.3 kept hitting it after upgrading.** 0.4.4 stopped *setting*
+  `input_paths` on `[ann-flavor] Merge Entitlements`/`Merge Info.plist`, but
+  never explicitly *cleared* it. `existing = target.build_phases.find { ... }`
+  reuses the same Xcodeproj object across runs, and `pod install` never
+  touches an attribute it doesn't assign — so a project that had already run
+  0.4.1-0.4.3 (which did set `input_paths` on that same, reused object) kept
+  the stale value forever, silently reintroducing the exact "Cycle inside
+  Runner" failure 0.4.4 was meant to remove. Confirmed live against `ledger`:
+  the cycle came back, now involving whichever framework happened to be on
+  the other side of the shared `ModuleVerifierTaskProducer` gate (in this
+  case an SPM-resolved `AppLovinAdapter.xcframework`, following the
+  consumer's separate SPM plugin migration — same underlying mechanism, not
+  a new bug). Fixed by explicitly setting `phase.input_paths = []` on both
+  phases, so a stale value is genuinely wiped on the next `pod install`, not
+  just left unset going forward.
+
+## 0.4.4
+
+### Fixed
+- **"Cycle inside Runner" could still occur even after 0.4.1-0.4.3.**
+  Confirmed live (again, against `ledger`) that declaring `input_paths` on
+  `[CP] Check Pods Manifest.lock`'s own output (introduced in 0.4.1 as the
+  original fix, kept through 0.4.2/0.4.3 as "belt-and-suspenders") was
+  actually the *cause* of the cycle, not a fix for it: `[ann-flavor] Merge
+  Entitlements`/`[ann-flavor] Merge Info.plist`'s output feeds
+  `ProcessProductPackaging` (signing), which Xcode's new build system gates
+  behind a chain of task producers (`ModuleVerifierTaskProducer` et al) —
+  and `Check Pods Manifest.lock`'s own output is *itself* gated behind that
+  same chain. Declaring it as an input routed these phases through that
+  chain from the other direction, closing a genuine cycle with the Firebase
+  framework-copy phases (also gated behind it) regardless of
+  `build_phases` position. Fixed by removing the `input_paths` declaration
+  entirely — `output_paths` plus running after the Pods/framework-copy
+  phases (the 0.4.2 position fix, kept) is sufficient on its own; this
+  phase never actually needed Check Pods Manifest.lock's result as an
+  input. Xcode's own error message ("moving Check Pods Manifest.lock so it
+  runs before the phase that depends on its outputs") was describing a
+  self-inflicted dependency, not a real requirement.
+
+## 0.4.3
+
+### Fixed
+- **0.4.2's fix produced a silently-corrupt `project.pbxproj`.** Moving
+  `[ann-flavor] Merge Entitlements`/`[ann-flavor] Merge Info.plist` from
+  `build_phases.unshift` to `build_phases.push` (to fix "Cycle inside
+  Runner") used the wrong method: `Xcodeproj::Project::ObjectList`
+  (`build_phases`'s real class) overrides `<<`/`insert`/`unshift`/`delete`
+  to register an added object in the project's global objects table, but
+  does **not** override `push` — plain `Array#push` silently bypasses that
+  registration. The phase ended up referenced in `buildPhases` with no
+  matching object anywhere else in `project.pbxproj`, which Xcode then
+  failed to build with `Build input file cannot be found:
+  '.../Entitlements-merged.entitlements'. Did you forget to declare this
+  file as an output of a script phase...?` — confirmed live against
+  `ledger`. Fixed by using `<<` instead of `push` in both phases' injection
+  code. Added regression coverage asserting the phase is genuinely present
+  in `project.objects`, not just the `build_phases` array — the exact
+  distinction `push` silently violated.
+
+## 0.4.2
+
+### Fixed
+- **0.4.1's fix for "Cycle inside Runner" was incomplete — the cycle could
+  still occur.** Declaring `input_paths` on `[CP] Check Pods Manifest.lock`'s
+  own output (0.4.1) correctly ordered `[ann-flavor] Merge Entitlements`/
+  `[ann-flavor] Merge Info.plist` after that one phase, but both were still
+  `unshift`ed to the very *front* of `build_phases`. Confirmed live (again,
+  against `ledger`) that the real cycle ran through a longer chain: these
+  phases' outputs feed `ProcessProductPackaging` (entitlements/Info.plist
+  signing), which is gated behind a chain of Xcode task producers that the
+  Firebase framework-copy phases are *also* gated behind — being first in
+  `build_phases` put both on the same shared gate from opposite directions,
+  a genuine cycle no single `input_paths` declaration could resolve.
+  `CODE_SIGN_ENTITLEMENTS`/`INFOPLIST_FILE` are only consumed at packaging/
+  signing time, which is late in the build — neither phase has any real
+  reason to run before `Sources`/`Frameworks`/`Resources`/`Embed Frameworks`
+  at all. Fixed by appending both phases at the **end** of `build_phases`
+  instead of unshifting them to the front (`input_paths` from 0.4.1 kept as
+  belt-and-suspenders). Also now unconditionally repositions the phase to
+  the end even when it already exists from a prior install — a project that
+  picked up the incomplete 0.4.1 fix needs this to actually move it on the
+  next `pod install`, not just leave it in place.
+
+## 0.4.1
+
+### Fixed
+- **`pod install`/Xcode build failed with "Cycle inside Runner; building
+  could produce unreliable results"** against a real project with real
+  CocoaPods frameworks (confirmed live: Firebase). The `[ann-flavor] Merge
+  Entitlements` and `[ann-flavor] Merge Info.plist` build phases (0.3.0/
+  0.4.0) declared `output_paths` but no `input_paths`, so nothing told
+  Xcode's new build system these phases must run after CocoaPods' own
+  `[CP] Check Pods Manifest.lock` phase — `build_phases.unshift` only
+  controls list order, which CocoaPods' own installer reorders after this
+  Podfile hook runs anyway. Fixed by declaring `input_paths =
+  ['$(DERIVED_FILE_DIR)/Pods-Runner-checkManifestLockResult.txt']` on both
+  phases, matching Check Pods Manifest.lock's own declared output — Xcode
+  now has an explicit dependency to resolve the ordering, rather than a
+  cycle its scheduler was resolving incorrectly.
+
+## 0.4.0
+
+### Added
+- **New `[ann-flavor] Merge Entitlements` build phase composes the final
+  `.entitlements` file Xcode signs with at build time**, not sync time: copies
+  `ios/Runner/Runner.entitlements` (the generic/base layer, developer-owned —
+  if present; unlike `Runner/Info.plist`, most projects have no stock
+  entitlements file at all, so a missing base file here starts from an empty
+  plist rather than failing), then merges in every key from the current
+  flavor's `ann/Entitlements/<flavor>.entitlements` delta (see
+  `ann_flutter_flavor` 1.3.0 — that file now holds only the flavor's
+  `entitlements:` cascade, not a full copy of `Runner.entitlements`), with the
+  flavor's value winning on any key both define. Uses `PlistBuddy`, mirroring
+  `[ann-flavor] Merge Info.plist` (0.3.0) exactly — entitlements files and
+  Info.plist are both plain Apple XML property lists, so the same
+  type-preserving merge logic applies unchanged. Injected only when at least
+  one flavor actually needs entitlements (its own cascade, or a stock
+  `Runner.entitlements`); removed automatically once nothing needs it anymore.
+
+### Changed
+- **`CODE_SIGN_ENTITLEMENTS` now points at
+  `$(DERIVED_FILE_DIR)/Entitlements-merged.entitlements`** (the Merge
+  Entitlements phase's output above) instead of directly at
+  `ann/Entitlements/<flavor>.entitlements`, whenever anything needs signing —
+  extends the same `INFOPLIST_FILE` rewiring from 0.3.0 to entitlements. See
+  [plan 039](../../docs/03-planning/features/039-entitlements-build-time-merge.md)
+  and the [Entitlements](../../docs/04-userguide/ios/overview.md#entitlements)
+  section of the iOS userguide for the full design.
+
+## 0.3.0
+
+### Added
+- **New `[ann-flavor] Merge Info.plist` build phase composes the final
+  Info.plist Xcode builds against at build time**, not sync time: copies
+  `ios/Runner/Info.plist` (the generic/base layer, developer-owned, always
+  present) to `$(DERIVED_FILE_DIR)/Info-merged.plist`, then merges in every
+  key from the current flavor's `ios/ann/Info/Info-<flavor>.plist` delta (see
+  `ann_flutter_flavor` 1.2.0 — that file now holds only the flavor's
+  `info_plist:` cascade, not a full copy of `Runner/Info.plist`), with the
+  flavor's value winning on any key both define. Uses `PlistBuddy`
+  (`/usr/libexec/PlistBuddy`), not `python3`/`ruby` — ships as part of Xcode
+  itself, so this phase adds no dependency on any scripting runtime beyond
+  what Xcode already requires. Every plist value type (string, bool, integer,
+  real, array, nested dict — e.g. `SKAdNetworkItems`) round-trips correctly
+  through the merge, not just strings. Prints a one-line notice to the Xcode
+  build log for any key the flavor delta actually overrides, to make an
+  unintentional override easy to spot. Found-and-updated in place on a
+  re-run, same UUID-stability guarantee as the Firebase-copy and Print Build
+  Info phases.
+
+### Changed
+- **`INFOPLIST_FILE` now points at `$(DERIVED_FILE_DIR)/Info-merged.plist`**
+  (the Merge Info.plist phase's output above) instead of directly at
+  `ios/ann/Info/Info-<flavor>.plist`. Enables `Runner/Info.plist` to remain a
+  live, always-consulted base layer instead of a one-time sync-time template
+  — the change this whole release exists to support. See
+  [plan 038](../../docs/03-planning/features/038-info-plist-build-time-merge.md)
+  and the [`Info.plist`
+  keys](../../docs/04-userguide/ios/overview.md#infoplist-keys) section of the
+  iOS userguide for the full design and migration notes.
+
+## 0.2.0
+
+### Added
+- **Wires the new `entitlements:` schema field (see `ann_flutter_flavor`
+  1.1.0) into the Xcode build.** When `ios/ann/Entitlements/<flavor>.entitlements`
+  exists on disk for a flavor, `configure_build_configuration` sets
+  `CODE_SIGN_ENTITLEMENTS` to it — the same find-or-create-by-name pattern
+  already used for `INFOPLIST_FILE`. `entitlements:` is opt-in (unlike
+  `info_plist`/the icon catalog, which every flavor always has): a flavor with
+  no generated entitlements file gets no `CODE_SIGN_ENTITLEMENTS` set at all,
+  and a stale value from a flavor's `entitlements:` being removed from
+  `annspec.yaml` is explicitly cleared on the next `pod install` rather than
+  left as a dangling, build-breaking reference to a file that no longer
+  exists. `CODE_SIGN_ENTITLEMENTS` is also added to `PROJECT_LEVEL_EXCLUDED_KEYS`
+  (same shadowing risk as `INFOPLIST_FILE`/`PRODUCT_BUNDLE_IDENTIFIER`).
+
+## 0.1.39
+
+### Fixed
+- **Real bug: the Firebase copy phase and `[ann-flavor] Print Build Info` phase
+  were both delete-and-recreated on every single `pod install`, each getting a
+  fresh UUID even when their content never changed.** `reject!`/manual removal
+  only dropped the old phase from `target.build_phases` (an `ObjectList`) —
+  the object itself stayed registered in the project's global objects table
+  (`objects_by_uuid`) forever, since only `ObjectList#delete` (not plain
+  `Array#reject!`) reference-counts and fully unregisters an object. This
+  permanently grew `project.pbxproj` by one orphaned, unreferenced build-phase
+  object per phase per `pod install` — confirmed via a real object-count diff
+  across two consecutive runs with zero actual configuration change. Both
+  phases are now found-or-updated in place (reusing the existing object's
+  UUID when found) instead of unconditionally removed and recreated; the
+  find-and-delete step itself now uses `ObjectList#delete` so any already-
+  orphaned phase from a prior gem version is still cleaned up correctly.
+- `project.pbxproj` is also no longer rewritten on a `pod install` with no
+  real change: `save_if_changed` (already used for `.xcscheme` files) renders
+  what `Xcodeproj::Project#save` would write and compares against disk first,
+  skipping the write entirely when identical.
+
+### Changed
+- `[ann-flavor] Print Build Info`'s output uses plain ASCII markers (`==`,
+  `-`) instead of emoji. Cosmetic only, but fixes a real Nanaimo (Xcodeproj's
+  pbxproj serializer) nondeterminism: the same emoji byte sequence could be
+  written as raw UTF-8 or as a `\u{...}` escape depending on the string
+  object's history, defeating the new byte-comparison skip-write check above
+  even when the underlying config was genuinely unchanged.
+
+## 0.1.38
+
+### Fixed
+- **Real bug: every `pod install` (and every Studio Upgrade run) appended a
+  fresh, duplicate `BuildActionEntry` to each flavor's `.xcscheme`, forever.**
+  Xcodeproj's `configure_with_targets` always appends a new build/test/launch
+  target entry rather than checking whether an equivalent one already
+  exists, and `configure_scheme` called it unconditionally on every run.
+  Confirmed against a real project: 16 duplicate `BuildActionEntry` blocks,
+  all pointing at the same `Runner` target, after repeated runs with no
+  actual configuration change in between. `configure_scheme` now skips
+  calling `configure_with_targets` when the scheme's build action already
+  has an entry for the target, and — more generally — skips writing the
+  `.xcscheme` file at all when the fully rebuilt scheme content is
+  byte-identical to what's already on disk, so a `pod install` with no real
+  change produces no file write and no git diff at all, not just no visible
+  duplication.
+
+## 0.1.37
+
+### Fixed
+- **`MARKETING_VERSION` was never set on any per-flavor build configuration** —
+  confirmed against a real project that `flutter create`'s own stock
+  Debug/Release configs never set it either. `CURRENT_PROJECT_VERSION =
+  "$(FLUTTER_BUILD_NUMBER)"` is present on the stock template and gets copied
+  forward as a starting point for each per-flavor config, but there was never
+  an equivalent `MARKETING_VERSION` to copy along with it. This left
+  `$MARKETING_VERSION` (and therefore `CFBundleShortVersionString`, the
+  version shown in App Store Connect, and `[ann-flavor] Print Build Info`'s
+  own Version Name line) resolving empty. Now explicitly sets
+  `MARKETING_VERSION = "$(FLUTTER_BUILD_NAME)"` on every per-flavor
+  configuration, mirroring the existing `CURRENT_PROJECT_VERSION` bridge.
+
+## 0.1.36
+
+### Added
+- **The Firebase plist copy step now also logs to `ios/build_info.log`**
+  (appended, since `[ann-flavor] Print Build Info` — which runs first —
+  overwrites that file earlier in the same build), recording exactly which
+  source plist was copied to which destination, or the specific error if the
+  expected source file wasn't found. Makes it possible to confirm which
+  flavor's Firebase config actually landed in the build without needing
+  Xcode's own build log or `flutter run -v`.
+
+## 0.1.35
+
+### Fixed
+- **Real bug, present since Firebase plist wiring was first added: the copied
+  `GoogleService-Info.plist` was never actually packaged into the built
+  `.app`.** The pre-build script correctly copies the right flavor's plist to
+  `Runner/GoogleService-Info.plist` on disk, but nothing ever added that file
+  as a Copy Bundle Resources member — Xcode had no reason to bundle a file it
+  didn't know to include, even though it existed correctly in the source tree
+  the whole time. This is very likely the actual root cause behind
+  `[core/no-app] No Firebase App '[DEFAULT]' has been created` crashes on iOS
+  that this session mistakenly (though not wrongly, given evidence at the
+  time) attributed only to the plist-deletion race fixed in 0.1.33 — that fix
+  was real and necessary, but incomplete. Now finds-or-creates a file
+  reference for `Runner/GoogleService-Info.plist` and adds it to the target's
+  Resources build phase, mirroring the pattern `find_or_create_icon_catalog`
+  already uses for `Assets.xcassets`. Verified directly against a real
+  project's `Runner.xcodeproj` — confirmed the file is now a genuine Copy
+  Bundle Resources member after `pod install`.
+
+## 0.1.34
+
+### Added
+- **`[ann-flavor] Print Build Info` now also writes to `ios/build_info.log`**
+  (relative to the project root, overwritten fresh on every build), not just
+  `echo`ed into the Xcode build log. `flutter run` doesn't stream Xcode
+  script-phase output to the terminal by default (only `flutter run -v`
+  does), so this makes build/flavor info visible without that flag — e.g.
+  `tail -f ios/build_info.log` in a separate terminal while `flutter run` is
+  going. Add `ios/build_info.log` to `.gitignore` — it's a generated,
+  build-time file, not meant to be checked in.
+
+## 0.1.33
+
+### Fixed
+- **Real bug, present since 0.1.18: the app could crash at launch with "No
+  Firebase App '[DEFAULT]' has been created" after a working build, with no
+  code change in between.** The Firebase plist wiring used a pre-build shell
+  script (copies the correct flavor's `GoogleService-Info.plist` into
+  `Runner/`) paired with a post-build script that deleted it again. 0.1.18
+  declared the pre-build script's `output_paths` to fix a *different* error
+  ("Build input file cannot be found"), but that combination is unsafe: once
+  Xcode's incremental build system considers the declared output already
+  satisfied, it can skip re-running the pre-build copy on a later build —
+  while the post-build phase had already deleted that same file at the end of
+  the previous build, permanently leaving `Runner/GoogleService-Info.plist`
+  (and therefore the shipped `.app`) without a Firebase config. Removed the
+  post-build deletion entirely; `ios/Runner/GoogleService-Info.plist` is
+  already gitignored, so leaving the last-built flavor's copy on disk between
+  builds is safe — the pre-build phase always overwrites it fresh before the
+  next real build regardless.
+
+### Changed
+- **`[ann-flavor] Print Build Info` now prints the flavor key on its own
+  labeled line** (`Flavor: ledger_in`), instead of only appearing embedded
+  inside `Build Type` (`$CONFIGURATION`, e.g. `Debug-ledger_in`).
+
+## 0.1.32
+
+### Fixed
+- Corrected the `RunnerTests` `SWIFT_VERSION` fix from 0.1.30/0.1.31: asserting
+  `SWIFT_VERSION` on a target's *existing* configurations wasn't sufficient.
+  `PBXNativeTarget#resolved_build_setting` (the API CocoaPods' own analysis uses)
+  resolves a target against every configuration name that exists anywhere in the
+  project, not just the target's own list — a name the target has no configuration for
+  resolves to `nil` rather than being skipped. `Runner` gets `Debug-<flavor>`/
+  `Release-<flavor>` configurations; `RunnerTests` didn't, so it resolved `SWIFT_VERSION`
+  to `nil` for every flavor name while `Runner` resolved to a real value — still failing
+  `pod install` even when `RunnerTests`'s own stock configurations were fully consistent
+  with each other. `configure_build_settings` now also mirrors every project-level
+  configuration name onto every native target it processes.
+- Added `PodfileHelper.preflight_swift_version` (exposed as
+  `bundle exec ann-ios-flavorize preflight --project <dir>`), callable standalone with no
+  CocoaPods `installer` object needed. The fix above only runs from `pod install`'s
+  `post_integrate` hook, which — per CocoaPods' own `Pod::Installer#install!` call order
+  — only fires *after* the dependency-resolution/analysis phase that's rejecting the
+  project for inconsistent `SWIFT_VERSION`. A project that has never had a successful
+  `pod install` therefore failed before the `post_integrate` fix ever got a chance to
+  run. `preflight_swift_version` opens `.xcodeproj` directly and applies the same fix,
+  so it can run from a separate process (`ann_flutter_flavor sync`) *before*
+  `pod install` is ever invoked — unblocking a project's very first install too.
+
+## 0.1.31
+
+### Added
+- `configure_build_settings` now fails `pod install` loudly for a flavor whose
+  `.appiconset` directory hasn't been generated yet, instead of silently shipping a build
+  with no app icon. `ASSETCATALOG_COMPILER_APPICON_NAME` is set unconditionally by `sync`
+  before "Generate App Icons" has necessarily run for a given flavor — without this check,
+  `pod install` succeeded silently and Xcode just couldn't find the named appiconset at
+  build time. The error names the missing flavor and the exact expected path.
+
+## 0.1.30
+
+### Fixed
+- `configure_build_settings` now asserts `SWIFT_VERSION` (when `sdk.swift_version` is set)
+  on every native target's existing build configurations, not just the `:application`
+  target — fixes a `pod install` failure ("There may only be up to 1 unique SWIFT_VERSION
+  per target") caused by `RunnerTests` drifting out of sync with `Runner`'s per-flavor
+  configs, since this plugin never touched non-application targets before. No new
+  per-flavor configurations are created on non-application targets.
+- `find_or_create_icon_catalog` now explicitly sets the `ann` group's `path` (`'ann'`) when
+  creating it. Previously the group was created with only a `name`, so its
+  `Assets.xcassets` file reference resolved to `ios/Assets.xcassets` instead of
+  `ios/ann/Assets.xcassets` — one directory up from where `ios_icon_generator.dart`
+  actually writes the generated per-flavor `.appiconset` content. Xcode couldn't find the
+  icon catalog at build time even though the generated files were correctly on disk.
+
+## 0.1.29
+
+### Fixed
+- `AnnFlavorCore::AnnSpec#flavor_exists_on?(platform_key, flavor_key)` added to the shared core (`ann-flavor-core-ruby`, vendored into this gem at publish time). Core-only in this release — `PodfileHelper` does not call this method yet; no functional change to Podfile/xcconfig generation. Included here purely because this gem vendors the shared core's source and versions travel together.
+
+## 0.1.28
+
+### Fixed
+- **`configure_build_settings`'s generated `XCBuildConfiguration`s were silently non-functional at real `xcodebuild` time**, despite passing every prior test (all of which only inspected the in-memory `Xcodeproj::Project` object model, never shelled out to real `xcodebuild`) — found via plan 035 STEP-2.11's real-project verification. Three distinct bugs, all now fixed:
+  - The `baseConfigurationReference`/`INFOPLIST_FILE` paths were constructed with a redundant `ios/` prefix (`"ios/ann/xcconfig/..."`), doubling to a nonexistent `ios/ios/ann/...` when resolved relative to `SRCROOT` (the `.xcodeproj`'s own containing directory) — the most severe of the three, since it meant every per-flavor xcconfig's `#include` chain silently never applied at all, and `xcodebuild -showBuildSettings` misleadingly echoed back the unresolved literal path string, making it look correct until checked against what the xcconfig actually set.
+  - New per-flavor configurations were registered only on the target's own `XCConfigurationList`, never the *project*-level one — `xcodebuild -configuration <name>` (and `-list`) only recognizes configuration names that exist at the project level; a target-only name is silently ignored, with `xcodebuild` falling back to the project's `defaultConfigurationName` instead.
+  - The "copy an existing configuration's settings as a starting point" convenience (both when creating the new target-level config and the new project-level one) copied Flutter's own stock `PRODUCT_BUNDLE_IDENTIFIER` placeholder along with it — a literal key in a configuration's own `buildSettings` dict always wins over a value pulled in via `baseConfigurationReference`, so this silently shadowed the correct per-flavor bundle ID no matter what the xcconfig itself said.
+- 3 new regression tests, all verified end-to-end against a real, fresh `flutter create` project + real `pod install` + real `xcodebuild -showBuildSettings`, not just the existing in-memory object-model assertions (which had themselves been unknowingly asserting the buggy doubled-path output as correct).
+
+## 0.1.27
+
+### Fixed
+- Dependency note above corrected: `ann-flavor-flutter` 1.0.8+ requirement is now satisfied — `flutter_package` reached 1.0.10+ generating `ios/ann/xcconfig/` and `ios/ann/Info/` in this same release cycle (plan 035 Phase 2 STEP-2.2). `configure_build_settings`'s generated build configurations now point at files that actually exist on disk from a fresh `sync` + `pod install`, not just a forward-compatible no-op.
+- Verified end-to-end against `test-apps/sample_app`'s real `configure_build_settings_spec.rb` suite (11 tests against real `Xcodeproj::Project` objects, not mocks) — build-configuration creation, `INFOPLIST_FILE`/`ASSETCATALOG_COMPILER_APPICON_NAME` wiring, idempotency, the shared icon catalog reference, scheme creation and merge-preservation, and the Print Build Info phase all confirmed passing (plan 035 Phase 2 STEP-2.8).
+
+## 0.1.26
+
+### Added
+- **Programmatic `project.pbxproj` build-configuration, scheme, and asset-catalog generator** (`PodfileHelper.configure_build_settings`, called automatically by `annai_ios_podfile_setup`): closes a previously-silent, undocumented manual Xcode step. For every iOS flavor x build type, `pod install` now creates/updates the `Debug-<flavor>`/`Release-<flavor>` `XCBuildConfiguration` (pointed at the generated `ios/ann/xcconfig/<Flavor><BuildType>.xcconfig`, `INFOPLIST_FILE` set to `ios/ann/Info/Info-<flavor>.plist`, `ASSETCATALOG_COMPILER_APPICON_NAME` set to `<Flavor>AppIcon`), the shared `ios/ann/Assets.xcassets` catalog reference, and a merge-if-exists `.xcscheme` per flavor (only the `buildConfiguration=` references are touched — manually added scheme content like environment variables and launch arguments is preserved). This also means a bare Dart-CLI + `pod install` workflow (no Studio/IDE plugin required) now produces a fully working multi-flavor Xcode project on its own. Everything is idempotent by construction (find-or-create by name), so re-running never duplicates configurations and always refreshes stale values. See [plan 035](https://github.com/anntech-dev/ann-flavor-tooling/blob/main/docs/03-planning/features/035-ios-flavor-architecture-redesign.md).
+- **`[ann-flavor] Print Build Info` pre-build phase** — iOS parity with Android's `PreBuildProcessingTask`: prints resolved Build Type, App Name, App ID, Version Name, and Version Code before any compilation step, gated by `debug.print_build_and_flavor_info` (default on, same flag Android already uses).
+
+**Requires `ann-flavor-flutter` 1.0.8+ generating `ios/ann/xcconfig/` and `ios/ann/Info/` files** (Phase 2 of plan 035, not yet released as of this version) for the referenced xcconfig/Info.plist paths to actually exist on disk — until then, the build configurations point at files that don't exist yet, which is expected and does not error at `pod install` time (only surfaces at actual Xcode build time). **Update (0.1.27):** this requirement is now satisfied — see below.
+
+## 0.1.25
+
+### Added
+- `info_plist` schema field added to the shared core (`ann-flavor-core-ruby`, vendored into this plugin) — a new iOS-only field for raw `Info.plist` overrides, valid at `default`/`flavor`/`build_type` levels, as either an inline map or a file-path reference. Core-only in this release — `PodfileHelper` does not yet read or act on this field; `Info.plist` generation/patching remains unchanged. Included here purely because this plugin vendors the shared core and versions travel together.
+
+## 0.1.24
+
+### Added
+- **iOS-only (non-Flutter) project support for `project_id`-mode Firebase**: the plugin now detects project layout once, at `pod install` time, by checking for `pubspec.yaml` at the project root. Flutter projects (pubspec.yaml present) keep resolving generated Firebase config files from `lib/generated/firebase/`, unchanged. Plain Xcode projects with no Flutter wrapper (pubspec.yaml absent) now resolve them from `ios/generated/firebase/` instead of incorrectly assuming a `lib/` directory that doesn't exist. `config_file` mode (an explicit path in `annspec.yaml`) is unaffected by this change on either layout. `ann-ios-flavorize setup` now prints which layout it detected (`Detected: Flutter project` / `Detected: iOS-only project`) and its error messages no longer assume a Flutter project when `annspec.yaml` or `ios/Podfile` is missing.
+
+## 0.1.23
+
+### Fixed
+- Upgrading past 0.1.22 did not actually fix the `../../` path bug for any project that had already run `pod install` against an earlier version — `inject_build_phases`'s idempotency check only tested whether a phase carrying our marker text already existed, never whether its content matched the currently-installed gem. Once injected, a stale build phase was permanently baked into `project.pbxproj` and silently skipped on every later `pod install`, regardless of gem upgrades. The check now removes any existing `[ann-flavor] Copy Firebase plist` / `[ann-flavor] Remove Firebase plist` phases by name before re-adding fresh ones on every `post_integrate` run, so the injected script always matches the installed gem version. **Projects with a stale phase already baked in from a prior version must run `pod install` once with 0.1.23 to self-heal** — no manual `project.pbxproj` editing needed.
+
+## 0.1.22
+
+### Fixed
+- 0.1.21 fixed which target the Firebase plist copy build phase runs in but left an off-by-one in the source path it computes — `"${SRCROOT}/../../#{plist_path}"` looked two directories above `$SRCROOT` (`<project_root>/ios`), landing one level *above* the Flutter project root, so the script failed with `Firebase plist not found` even though the file existed exactly where expected. `plist_path` is relative to the Flutter project root, and for the real `Runner` target `$SRCROOT` is `<project_root>/ios` — one level below it — so only a single `..` is needed. Fixed.
+
+## 0.1.21
+
+### Fixed
+- The Firebase-config-file build phase injected by `PodfileHelper.configure_firebase` never actually ran against the app build, causing `Build input file cannot be found: '.../Runner/GoogleService-Info.plist'` — it was injected into `installer.pods_project`'s `Pods-Runner` target, CocoaPods' own generated aggregate target for building pod dependencies, never the real app project. Now injected into the real user project (`aggregate_target.user_project`, not `pods_project`) and the actual app target (identified by product type via `symbol_type == :application`, not a hardcoded name), with the project explicitly saved afterward. **Requires calling `configure_firebase` from your Podfile's `post_integrate` hook instead of `post_install`** — `post_install` fires before CocoaPods has integrated/saved the user project, so build phases added there are silently lost regardless of which project they're added to. ([#61](https://github.com/anntech-dev/ann-flavor-tooling/issues/61))
+
+## 0.1.20
+
+### Fixed
+- `pod install` failed for every consumer with `cannot load such file -- ann_flavor_core` — the 0.1.19 core-delegation change added a hard `require 'ann_flavor_core'` in `PodfileHelper`, but `ann_flavor_core` is intentionally never published to RubyGems (ADR-008). The published gem now vendors `ann_flavor_core`'s source and resolves it automatically; local monorepo development is unaffected. ([#58](https://github.com/anntech-dev/ann-flavor-tooling/issues/58))
+
+## 0.1.19
+
+### Changed
+- `PodfileHelper` now delegates `annspec.yaml` parsing and iOS bundle-ID/Firebase resolution to the shared `ann-flavor-core-ruby` gem ([ADR-008](../../docs/02-decisions/008-core-delegation-mandate.md)).
+
+### Fixed
+- `configure_firebase` now resolves Firebase config files for `profile` builds in addition to `debug`/`release` — previously `profile`-build-type Firebase overrides in `annspec.yaml` were silently skipped.
+
+### Removed
+- `PodfileHelper.bundle_id(flavor_key, ...)` (the build-type-agnostic bundle ID accessor, confirmed unused by any caller). Use `PodfileHelper.bundle_id_for_build_type(flavor_key, build_type, ...)` instead.
+
+## 0.1.18
+
+### Fixed
+- **Build phase output declaration**: pre-build script phase now declares `$(SRCROOT)/Runner/GoogleService-Info.plist` as an `output_paths` entry. This tells Xcode's build system that the script produces the file, suppressing the "Build input file cannot be found" error that fired when the plist was listed in Copy Bundle Resources but did not yet exist on disk. Post-build cleanup phase declares the same path as `input_paths` to preserve the ordering dependency.
+
+## 0.1.17
+
+### Fixed
+- **Issue #46**: Firebase plist build phase script now uses `${SRCROOT}/../../` instead of `${SRCROOT}/../` to correctly resolve paths relative to the project root. `${SRCROOT}` in the `Pods-Runner` target resolves to `ios/Pods`, so one extra `../` is required to reach the Flutter project root where `lib/generated/firebase/` lives.
+
+---
+
+## 0.1.16
+
+### Fixed
+- Restored `project_root:` keyword arg on `configure_firebase`, `bundle_id`, and `bundle_id_for_build_type` for testability; defaults to auto-discovery via `find_spec_file` when not provided.
+
+---
+
+## 0.1.15
+
+### Fixed
+- `annspec.yaml` is now discovered by walking up from `Dir.pwd` until the file is found, so the gem works standalone for iOS-only projects and as a Flutter plugin regardless of which directory `pod install` runs from. No hardcoded paths.
+
+---
+
+## 0.1.14
+
+### Fixed
+- Added top-level `annai_ios_podfile_setup(installer)` method so Podfiles can call it directly in a `post_install` hook. Previously only `AnnFlavorCocoapods::PodfileHelper.configure_firebase` was exposed, causing `undefined method 'annai_ios_podfile_setup'`.
+
+---
+
+## 0.1.13
+
+### Fixed
+- Added `lib/ann-flavor-cocoapods.rb` alias so CocoaPods can resolve `plugin 'ann-flavor-cocoapods'` under Ruby 3.4, where hyphenated gem names cannot be loaded via `require` directly.
+
+---
+
+## 0.1.12
+
+### Changed
+- Version bump — no functional changes.
+
+---
+
+## 0.1.11
+
+### Fixed
+- Added `lib/annai-flutter-flavor.rb` and `lib/ann-flavor-cocoapods.rb` aliases so legacy `require 'annai-flutter-flavor'` in Podfiles works under Ruby 3.4.
+
+---
+
+## 0.1.9
+
+### Added
+- **DEF-019** (`target` field): Core-ruby now carries `target` on `FirebaseConfig` and cascades
+  it via `resolve_firebase` / `merge_firebase_config`. Version bump triggered by ADR-006 core-to-plugin rule.
+
+---
+
+## 0.1.8
+
+### Added
+- **DEF-017**: `ann-ios-flavorize setup` CLI command for iOS-only (non-Flutter)
+  projects. Checks `annspec.yaml` exists, patches `ios/Podfile` with
+  `plugin 'ann-ios-flavorize'`, and prints next-step guidance. Idempotent —
+  safe to run multiple times. Install via `gem 'ann-flavor-cocoapods'` in your
+  Gemfile, then run `bundle exec ann-ios-flavorize setup`.
+
+### Fixed
+- **DEF-014**: `configure_firebase` now injects build phases in `project_id` mode
+  (no `config_file` set). The plist source is derived from
+  `lib/generated/firebase/GoogleService-Info-{flavor}-{buildType}.plist`.
+  Previously no build phases were injected, causing the Crashlytics dSYM upload
+  run script to fail with a missing plist error.
+
+---
+
+## 0.1.7
+
+**Backwards-compatibility shims removed** — the deprecated `firebase.file` fallback
+and `firebase_token_file` are no longer accepted. Specs must use `config_file` and
+`service_account` directly.
+
+**`service_account` support** — the `service_account` field is read from the spec
+and exported as `GOOGLE_APPLICATION_CREDENTIALS` when invoking Firebase CLI commands.
+
+## 0.1.6
+
+**`enabled: false` support** — when `annspec.yaml` sets `enabled: false`, the
+CocoaPods plugin skips all configuration silently.
+
+**Improved error messages** — field validation errors now include the exact YAML path
+and a fix hint.
+
+## 0.1.5
+
+**Breaking: `annai_app:` root key renamed to `app:`** — `annspec.yaml` files using
+the old `annai_app:` root key must be updated.
+
+## 0.1.4
+
+**Firebase `config_file` support** — the podfile helper now reads the `config_file`
+field. The old `file` field is accepted with a deprecation warning; support will be
+removed in a future version.
+
+**Firebase `path` / `firebase_app_id` / `build_target` removed** — replaced by
+`config_file` and `project_id`.
+
+## 0.1.3
+
+**Schema restructure** — credentials and sdk fields reorganised to match the updated
+`annspec.yaml` structure.
+
+## 0.1.2
+
+Documentation and sync-workflow updates. No user-facing behaviour changes.
+
+## 0.1.1
+
+Initial release.