Skip to content
Back to skills

Ios Secrets Setup

BSecurity

Configure iOS service keys, Secrets.xcconfig, CI signing credentials, or release secret injection and provenance.

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 2, 2026
developmentgoswiftgitapi

Works with

  • api

Security analysis

B88/100
  • criticalSends environment variables or credentials to an external URL

Pro shows the line behind each finding and how to fix it

Scanned September 25, 2026

npx -y skills add patrickserrano/lacquer --skill ios-secrets-setup --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ios Secrets Setup?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ios Secrets Setup
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/patrickserrano-ios-secrets-setup/badge)](https://www.skillsdirectory.com/skills/patrickserrano-ios-secrets-setup)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ios-secrets-setup
description: Configure iOS service keys, Secrets.xcconfig, CI signing credentials, or release secret injection and provenance.
---

# iOS App-Runtime Secrets Setup

App-runtime keys (RevenueCat, Aptabase, …) live in a gitignored
`Secrets.xcconfig`, never in source or the committed `project.yml`. The
lacquer syncs a `Secrets.xcconfig.example` template into the component dir.

1. **Copy & ignore:** `cp Secrets.xcconfig.example Secrets.xcconfig`, fill in
   real values, and add `Secrets.xcconfig` to `.gitignore`. The example is
   committed; the real file never is. (The committed `project.yml` must also
   stay key-free.)
2. **Wire into the build (`project.yml`):** point the target's configs at the
   xcconfig and surface each key into `Info.plist`:
   ```yaml
   targets:
     <App>:
       configFiles:
         Debug: Secrets.xcconfig
         Release: Secrets.xcconfig
       info:
         path: App/Info.plist
         properties:
           REVENUECAT_API_KEY: $(REVENUECAT_API_KEY)
           APTABASE_APP_KEY: $(APTABASE_APP_KEY)
   ```
3. **Read at runtime** from the Info dictionary — fail loud if a required key
   is blank rather than shipping a broken SDK init:
   ```swift
   enum Secrets {
       static func required(_ key: String) -> String {
           guard let v = Bundle.main.object(forInfoDictionaryKey: key) as? String,
                 !v.isEmpty else {
               fatalError("Missing \(key) — copy Secrets.xcconfig.example to Secrets.xcconfig and fill it in")
           }
           return v
       }
       static var revenueCatAPIKey: String { required("REVENUECAT_API_KEY") }
       static var aptabaseAppKey: String { required("APTABASE_APP_KEY") }
   }
   ```

`Secrets.xcconfig` values are **build-time** — they are baked into the
binary, so treat them as obfuscated, not secret. A truly sensitive secret
belongs on a server, never in the app.

> **RevenueCat ships two different keys — do not confuse them.** The
> `REVENUECAT_API_KEY` above is the **public SDK key** (`appl_…`), safe to
> compile into the app. RevenueCat's **REST API** uses a separate **secret
> key** (`sk_…`) that grants full account access — it must **never** go in
> `Secrets.xcconfig` or the binary. That's a CI/server secret
> (`REVENUECAT_REST_API_KEY`), set via `gh secret set` per the
> CI/server secrets section in [references/project-rules.md](references/project-rules.md).

## Project conventions

Read [references/project-rules.md](references/project-rules.md) for the relevant
section when handling this task. Read only what applies; examples do not
authorize releases, deployments or changes outside the user's scope.
Always-loaded safety rules still apply.

- Secrets & Service Keys

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…