CLAUDE

CLAUDE.md — iOS SDK Wiki

This directory is the published, public wiki for the Convert iOS SDK. It contains two categories of pages.

Shared Docs vs iOS-Specific Docs

• Shared docs (lowercase-hyphenated filenames, e.g. rule-evaluation.md, data-management.md, segments.md, bucketing-algorithm.md, and everything listed under "Core Concepts (Shared)" / "How-To Guides (Shared)" in AI_Index.md) — these are the cross-SDK concept docs whose canonical source lives in a private backend repo (public/js/tracking/full-stack-docs/, with concepts/ and guides/ subdirs). The same files appear in the JavaScript, Android, and PHP SDK wikis. The conceptual prose is shared; the code samples here have been adapted to Swift/iOS. If the iOS wiki is later added to the backend doc-sync, the prose portions may be regenerated — keep the iOS code adaptations minimal and self-contained.

• iOS-specific docs (CamelCase filenames, e.g. Quickstart.md, Installation.md, Initialization.md, Configuration.md, ReturnTypes.md, CodeExamples.md, OfflineBehavior.md, TrackingControl.md, AppPrivacy.md, ObjCInterop.md, Testing.md) — these are iOS-only and are edited directly in this wiki.

Decision Rule Before Editing Anything

1. Check the filename.
   • Lowercase-hyphenated → shared concept doc → prefer editing the canonical backend source; here, only adapt code samples to Swift.
   • CamelCase → iOS-specific → edit here.
2. AI_Index.md and this CLAUDE.md are wiki-specific and edited here.

Backend Sync Status

The backend doc-sync workflow currently targets the JavaScript and PHP SDK wikis; the iOS wiki is not yet in its target matrix. The shared docs here were ported from the canonical source / the Android SDK wiki, with their relative links rewritten to this wiki's URLs and their code samples converted to Swift.

Writing Rules for iOS-Specific Docs (Public Audience)

This wiki is public (as are the JavaScript, Android, and PHP SDK wikis). The backend wiki and backend repo are private. When writing or editing any iOS-specific doc here:

1. Never reference the private backend wiki or any private repo. No links to backend.wiki/*, no "see the backend wiki." Inline what is needed, or omit it.
2. Never reference internal backend filesystem paths. Use the public Swift surface: SPM (https://github.com/convertcom/ios-sdk.git, product ConvertSwiftSDK), CocoaPods (pod 'ConvertSwiftSDK'), module names (ConvertSwiftSDK, ConvertSwiftSDKCore), and type/method names.
3. Never invent URLs. Guessed GitHub wiki URLs are a common failure — org, repo, slug, and casing are all easy to get wrong. Prefer the verified convertcom/ios-sdk/wiki/... URLs already used across these pages.
4. Prefer type and method references over file paths and line numbers. ConvertSwiftSDK(configuration:) / ConvertContext.runExperience(_:enableTracking:) age better than a Sources/... path.
5. Ground every API claim in the actual SDK. Public types, method names, parameter names, defaults, and enum cases must match the released ConvertSwiftSDK Swift API — not assumptions. The SDK uses an initializer (ConvertSwiftSDK(configuration:)), not a builder; returns Variation / Feature (no Bucketed prefix); GoalData is a [GoalDataKey: GoalDataValue] dictionary; and completion-handler overloads exist only for ready, runExperiences, setTrackingEnabled, and isTrackingEnabled.