cometchat-ios-production— agent skill

Ground truth: CometChatUIKitSwift 5.1.22 + CometChatSDK 4.1.7 (symbols verified vs catalogs/ios-v5.json). The login/auth-token API is FETCHED via cometchat-ios-core/references/docs-map.md; the REST auth-token endpoint is {DOCS_BASE}/rest-api/auth-tokens. The iOS UI Kit docs have no single production-hardening page — this checklist is the pack's own guidance from RULES.md §4 + cometchat-ios-core/references/setup-credentials.md, labelled as such. Tracked DOCS GAP.

Companion skills (read first)

• cometchat-ios-core — references/setup-credentials.md (the Secrets.xcconfig → Info.plist → Bundle.main flow) and references/swiftui.md (the init→login launch hook) this hardens.
• cometchat-security — the enterprise auth model this client-side hardening plugs into: wiring your IdP / SSO into the token flow (your IdP → your server → mint the CometChat auth token; CometChat is not an IdP), token expiry/refresh + re-login, RBAC roles + group (SBAC) scopes, and Auth Key vs auth token vs REST API Key. Load it for a security review or any SSO question.

Use this skill when

Moving off the development setup: TestFlight/App Store submission, a security review, or "is this safe to ship."

The one thing that matters

Never embed the Auth Key in the app binary.

The Auth Key can mint a session for any user in your app. Anything baked into the app — an xcconfig value promoted into Info.plist, a string constant — is recoverable from the shipped .ipa (strings, class-dump). Treat it as public.

The production login flow

1. Your app authenticates the user (your own auth / sign-in with Apple / your backend).
2. Your server mints a CometChat auth token for that user's UID via the REST API using the REST API Key ({DOCS_BASE}/rest-api/auth-tokens).
3. The server returns the token to the app over an authenticated HTTPS request.
4. The app calls login(authToken:).

// UID comes from the SERVER session, never from the client
let authToken = try await fetchCometChatToken()   // your authenticated endpoint
CometChatUIKit.login(authToken: authToken) { result in /* handle success/failure */ }

init must resolve first (initFromSettings), then login — calling login before init resolves fails silently (cometchat-ios-core).

Keep secrets out of the build

Development reads the Auth Key from a gitignored Secrets.xcconfig promoted into Info.plist. For production, ship App ID + Region only (not secrets — they identify the app) and log in with a token; leave the Auth-Key value empty in the release configuration.

# after an archive/build, confirm the key is not in the app binary
strings "$APP_BUNDLE/YourApp" | grep -q "<your-auth-key>" && echo "LEAK" || echo "clean"

Also verify Secrets.xcconfig is in .gitignore (only a committed placeholder), and that it is not bundled as a resource.

Also before launch

• Users are created server-side as part of signup — not from the app with the Auth Key.
• Log out properly: CometChatUIKit.logout(), then clear derived state and unregister VoIP/APNs push tokens (cometchat-ios-push).
• Pin exact versions — the kit is a prebuilt binary compiled against one Chat SDK version; a drifting CometChatSDK breaks it (cometchat-ios-core Install).
• App Transport Security: keep HTTPS; do not add broad NSAllowsArbitraryLoads exceptions.
• Calls need permissions: NSCameraUsageDescription + NSMicrophoneUsageDescription with real strings, or App Review rejects; VoIP push needs the entitlement.
• Region must match the dashboard app.
• Enable dashboard extensions/AI on the PRODUCTION app, not just dev.

Pre-launch checklist

• [ ] Auth Key not in the app binary (strings-verified)
• [ ] login(authToken:) in production; UID from the server session
• [ ] REST API Key server-side only
• [ ] Secrets.xcconfig gitignored; only a placeholder committed
• [ ] Exact kit/SDK/Calls versions pinned
• [ ] Camera/mic usage strings + VoIP entitlement present (if calling)
• [ ] Logout clears session, state and push tokens
• [ ] Dashboard extensions/AI enabled for the production app
• [ ] Tested against the production app's credentials

Common pitfalls

1. Auth Key recoverable from the `.ipa` — the critical one.
2. Token endpoint trusting a client-supplied UID — impersonation.
3. Login before init resolves — silent no-render (order invariant).
4. Missing usage-description strings — App Review rejection for calling apps.
5. Dashboard configured on the dev app only — features silently missing in production.

Verify it works

Archived build's binary contains no Auth Key (strings) · login works via token · a tampered UID is rejected by the server · logout fully clears · calls request permission and connect · features enabled on the production app.