Integrations map

integrations.map.yaml is data, not code. The scaffold renderer reads it to turn each App Spec integrations choice into SPM packages, target dependencies, adapter files, Info.plist keys, and the env vars a human must fill. Adding a provider is adding a row.

Each provider row can declare:

• spm — the Tuist remote package line (or none for a system framework).
• product — the SPM product to depend on.
• adapter — the template copied into Sources/ (each conforms to a DeliciousKit protocol).
• env — the environment variables you must provide.
• capability — an Xcode capability/entitlement to enable.
• info_plist — keys added to Info.plist (e.g. an ATT usage string).

Providers by slot

Analytics (AnalyticsTracker)

• telemetrydeck — env: TELEMETRYDECK_APP_ID
• posthog — env: POSTHOG_API_KEY, POSTHOG_HOST
• mixpanel — env: MIXPANEL_TOKEN
• firebase — env: FIREBASE_PLIST (the GoogleService-Info.plist in the bundle)

Auth (AuthProvider)

• apple — Sign in with Apple; no keys, enables the "Sign in with Apple" capability.
• supabase — env: SUPABASE_URL, SUPABASE_ANON_KEY

Push (APNs via a provider)

• onesignal — env: ONESIGNAL_APP_ID; enables Push Notifications.
• fcm — env: FIREBASE_PLIST; enables Push Notifications.

In-app purchases (PurchaseProvider)

• storekit2 — system framework, built into DeliciousKit; no package, no keys.
• revenuecat — env: REVENUECAT_API_KEY

Ads (AdsProvider)

• admob — env: ADMOB_APP_ID; adds GADApplicationIdentifier and an NSUserTrackingUsageDescription to Info.plist (ATT applies).

How it's wired

A provider's adapter conforms to the matching DeliciousKit protocol, so the app code never changes when you swap providers — you change one line in the App Spec and the scaffold does the rest. See DeliciousKit → Project structure for the protocol pattern, and the Integrations stage for when this runs.