Use a fresh Firebase Remote Config key for the account-creation flag

[yaelirub]

Follow-up to #4985.

The encourageAccountCreation flag's remoteKey fell through to the derived "encourage_account_creation". That Firebase Remote Config parameter still exists from the 2025 one-shot Encourage Account Creation experiment — removing code never removed the parameter — so the recurring modal inherits whatever value that entry currently holds.

Because a remote value overrides the flag's local default, the recurring modal could ship silently disabled (if the old experiment was wound down to false) or at an unintended partial rollout percentage, while the code still reads as "default on".

This points the flag at a fresh parameter, encourage_account_creation_recurring, so it starts from a clean slate with no inherited value or rollout condition.

Caught by @geekygecko on the Android port (pocket-casts-android#5763); the same rename has landed there, so both platforms move off the stale parameter together.

Deliberately not renamed: the identically-named AnalyticsSource.encourageAccountCreation (Constants.swift) and OnboardingFlow.Flow.encourageAccountCreation (OnboardingFlow.swift) string values. Those are analytics/flow identifiers, not Remote Config keys — renaming them would break analytics continuity and cross-platform parity.

To test

This is a Remote Config plumbing change; the observable behaviour is which parameter the flag reads.

1. Beta Features screen → confirm the Encourage Account Creation flag still appears and its dev toggle works as before.
2. With the flag on, confirm the recurring modal still shows for a logged-out user past onboarding (unchanged behaviour from Show Encourage Account Creation modal every 60 days for logged-out users #4985).
3. Before enabling remotely, a new encourage_account_creation_recurring parameter needs creating in Firebase Remote Config — the old encourage_account_creation entry is now unused by this flag.

make build_staging succeeds locally.

Checklist

• I have considered if this change warrants user-facing release notes and have added them to CHANGELOG.md if necessary.
• I have considered adding unit tests for my changes.
• I have updated (or requested that someone edit) the Event Horizon schema to reflect any new or changed analytics.

🤖 Generated with Claude Code

[claude]

Claude finished @yaelirub's task in 1m 59s —— View job

---

Review

The mapping does what the description claims: remoteKey is the single accessor used both to register defaults (podcasts/FirebaseManager.swift:19-21) and to read values (podcasts/AppDelegate.swift:306-317), so pointing the flag at encourage_account_creation_recurring moves both sides together, and the derived key would indeed have been encourage_account_creation (lowerSnakeCased() in Modules/Sources/PocketCastsUtils/Extensions/StringExtension.swift:66). With the new parameter absent from Firebase, configValue resolves to .default, no override is written, and the flag reads its local true. No correctness or behaviour issues in the diff; one operational caveat below.

Non-blocking

Modules/Sources/PocketCastsUtils/Feature Flags/FeatureFlag.swift:462 — an override already persisted on device survives the rename, since FeatureFlagOverrideStore keys on the flag name, not the remote key; publish the new parameter with an explicit true so one fetch clears any stale false from builds that read the old key. (thread)
· branch fix/eac-fresh-remote-config-key

[Copilot]

Pull request overview

Updates the iOS feature-flag plumbing so the Encourage Account Creation recurring-modal gate reads from a new Firebase Remote Config parameter, avoiding unintended inheritance from the stale 2025 one-shot experiment key.

Changes:

• Adds an explicit remoteKey mapping for FeatureFlag.encourageAccountCreation.
• Points that mapping to the new Remote Config parameter name: encourage_account_creation_recurring.
• Leaves analytics/flow identifier strings untouched (as intended) to preserve continuity.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[claude]

(non-blocking) The key rename fixes future reads, but it can't undo an override already persisted on device: AppDelegate.updateRemoteFeatureFlags (podcasts/AppDelegate.swift:306-317) writes ff-override-encourageAccountCreation into UserDefaults whenever the remote value's source is .remote, and that store is keyed by the flag's description (the raw value), not by the remote key. So any tester who ran a build containing #4985 while encourage_account_creation was serving false still has a stored false, and because the new encourage_account_creation_recurring parameter doesn't exist yet its configValue source is .default — the override block is skipped and nothing clears it. Those users keep the modal disabled.

Easiest mitigation: when creating encourage_account_creation_recurring in Firebase, publish it with an explicit true rather than leaving it absent — override(_:withValue:) deletes the stored key when the incoming value matches the flag default, so one remote fetch cleans the stale entry.

[claude]

Claude finished @yaelirub's task in 17s —— View job

---

Review

Since my last review the only change is ddf8bea, which drops the two explanatory comment lines above the new case; the mapping itself is byte-identical, so nothing new to flag.

Non-blocking

Modules/Sources/PocketCastsUtils/Feature Flags/FeatureFlag.swift:459 — still open from the previous pass: publish encourage_account_creation_recurring with an explicit true so one fetch clears any false override already persisted on devices that ran an earlier build. (thread)

--- · branch fix/eac-fresh-remote-config-key

[kean]

Good catch.