feature-flags-addition

Feature Flag Addition Pattern

When This Pattern Applies

This pattern is activated when the user explicitly requests to add a feature flag, such as:

• "Add a feature flag for [feature name]"
• "Create a feature flag for [feature name] on [platform]"
• "I need a feature flag to control [feature name]"

Overview

Adding a feature flag requires careful consideration of several factors:

1. Platform (iOS, macOS, or both)
2. Source type (how the flag is controlled)
3. Default value (fallback behavior)
4. Local overriding (debug menu access)
5. Remote configuration (if applicable)

Step 1: Validate and Check for Duplicates

Before adding a new feature flag, check if a similar flag already exists:

# Search for similar flags
grep -i "case.*[searchTerm]" iOS/Core/FeatureFlag.swift
grep -i "case.*[searchTerm]" macOS/LocalPackages/FeatureFlags/Sources/FeatureFlags/FeatureFlag.swift

Step 1.5: Create Asana Task (REQUIRED)

STOP: Before proceeding with implementation, the user must create an Asana task.

Instruct the user:

Please create an Asana task in the Apple Feature Flags Registry:

1. Open Asana
2. Navigate to the "Apple Feature Flags Registry" project
3. Create a new task default feature flag task
4. Copy the task URL

Paste the Asana task URL when ready to continue.

This is mandatory - all feature flags must be tracked in the Apple Feature Flags Registry.

Step 2: Ask Clarifying Questions

Question 1: Platform Selection

Ask the user:

Which platform(s) should this feature flag target?
  a) iOS only
  b) macOS only
  c) Both iOS and macOS

Default: Infer from user's request. If ambiguous, ask.

Question 2: Feature Flag Source Type

Ask the user:

What source type should this feature flag use?

  a) .remoteReleasable - Can be controlled remotely in production (RECOMMENDED for most features)
     • Allows gradual rollout
     • Can be toggled without app updates
     • Requires Privacy Config setup
     
  b) .remoteDevelopment - Remote control in development environments only
     • For testing remote config before production
     • Not visible in production builds
     
  c) .internalOnly() - Only enabled for internal users
     • Always on for internal users
     • Always off for external users
     • No remote control
     
  d) .disabled - Always off for everyone
     • Placeholder for future features
     • Code is present but inactive

Which option? (a is recommended for new features)