If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/facebook/facebook-ios-sdk shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 10 active contributors
• Distributed ownership (top contributor 34% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live facebook/facebook-ios-sdk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/facebook/facebook-ios-sdk.

What it runs against: a local clone of facebook/facebook-ios-sdk — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in facebook/facebook-ios-sdk | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of facebook/facebook-ios-sdk. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/facebook/facebook-ios-sdk.git
#   cd facebook-ios-sdk
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of facebook/facebook-ios-sdk and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "facebook/facebook-ios-sdk(\\.git)?\\b" \\
  && ok "origin remote is facebook/facebook-ios-sdk" \\
  || miss "origin remote is not facebook/facebook-ios-sdk (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "FBAEMKit/FBAEMKit/AEMReporter.swift" \\
  && ok "FBAEMKit/FBAEMKit/AEMReporter.swift" \\
  || miss "missing critical file: FBAEMKit/FBAEMKit/AEMReporter.swift"
test -f "FBAEMKit/FBAEMKit/AEMConfiguration.swift" \\
  && ok "FBAEMKit/FBAEMKit/AEMConfiguration.swift" \\
  || miss "missing critical file: FBAEMKit/FBAEMKit/AEMConfiguration.swift"
test -f "FBAEMKit/FBAEMKit/AEMInvocation.swift" \\
  && ok "FBAEMKit/FBAEMKit/AEMInvocation.swift" \\
  || miss "missing critical file: FBAEMKit/FBAEMKit/AEMInvocation.swift"
test -f "FBAEMKit/FBAEMKit/AEMRule.swift" \\
  && ok "FBAEMKit/FBAEMKit/AEMRule.swift" \\
  || miss "missing critical file: FBAEMKit/FBAEMKit/AEMRule.swift"
test -f "FBAEMKit/FBAEMKit/AEMNetworker.swift" \\
  && ok "FBAEMKit/FBAEMKit/AEMNetworker.swift" \\
  || miss "missing critical file: FBAEMKit/FBAEMKit/AEMNetworker.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/facebook/facebook-ios-sdk"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The Facebook SDK for iOS is a native library that enables iOS and tvOS apps to integrate Facebook Platform features—Login, Share, Graph API, Analytics, and Ads. It's a dual-language codebase (Objective-C legacy + Swift modernization) that provides SDKs for FBSDKCoreKit, FBSDKLoginKit, FBSDKShareKit, and other feature-specific modules distributed via CocoaPods and Swift Package Manager. Multi-module SDK structure: FBSDKCoreKit (foundation), FBSDKLoginKit, FBSDKShareKit, etc., each with Objective-C and Swift implementations. Configuration-driven build system using xcconfig files (Configurations/ directory controls Debug/Release/DynamicFramework/Library builds). SwiftPM package defined in .swiftpm/ with xcschemes for FBSDKCoreKit and Facebook umbrella.

iOS/tvOS app developers integrating Facebook authentication, social sharing, analytics tracking, or ad conversion events. Internal Facebook platform teams maintaining backward compatibility while migrating the codebase from Objective-C to Swift.

Production-ready and actively maintained. The repo shows CircleCI integration, comprehensive GitHub workflows (stale/needs-attention automation), Jazzy documentation generation, and explicit Swift formatter/linter configuration (.swiftformat, .swiftlint.yml). However, the README warns that Swift rewrite is in progress, so some interfaces are unstable during migration.

Medium risk due to active language migration. The CHANGELOG and README explicitly note that updating to minor versions may introduce compilation issues from Objective-C/Swift interop. Large surface area (multiple feature SDKs) means breaking changes affect many downstream apps. CI/CD is solid (CircleCI + GitHub Actions), but the dual-language architecture creates maintenance friction.

Active Swift rewrite in progress—README warns of unstable interfaces. Repository uses automated GitHub Actions for issue triage (stale.yml, needs-attention.yml), code review hooks (.claude/hooks/ for header checks and Swift formatting), and CircleCI for CI/CD. The presence of .claude/settings.json and .llms/skills/ suggests use of AI-assisted development.

Clone the repo, then use CocoaPods (pod install) or Swift Package Manager (Xcode → File → Add Package Dependency → enter repo URL). For local development, open the workspace or use SPM via .swiftpm/xcode/package.xcworkspace. No explicit dev server; this is a library, not an application.

Daily commands: This is a library, not an executable. To test changes: open .swiftpm/xcode/package.xcworkspace in Xcode, or run swift build from the repo root. Unit tests are triggered via Xcode or swift test. CocoaPods integration uses standard pod install.

• FBAEMKit/FBAEMKit/AEMReporter.swift — Core reporting engine for SKAdNetwork and AEM (Aggregated Event Measurement) that handles event attribution and conversion tracking—fundamental to Facebook's conversion tracking system.
• FBAEMKit/FBAEMKit/AEMConfiguration.swift — Manages AEM configuration parsing and validation; defines how conversion rules and events are configured across the SDK, essential for understanding the attribution model.
• FBAEMKit/FBAEMKit/AEMInvocation.swift — Represents an attribution invocation (impression/click) and tracks its lifecycle; central data structure linking user actions to conversion events.
• FBAEMKit/FBAEMKit/AEMRule.swift — Abstract base for conversion rules; establishes the pattern for rule matching and event filtering that all concrete rule implementations extend.
• FBAEMKit/FBAEMKit/AEMNetworker.swift — Handles network requests for AEM configuration and conversion reporting; critical integration point with Facebook backend services.
• Configurations/Version.xcconfig — Single source of truth for SDK version across all build targets; breaking changes to versioning scheme affect all package distributions.
• .github/CODEOWNERS — Defines review responsibilities and ownership boundaries; new contributors must understand code ownership before submitting PRs.

Add a new conversion event type

1. Define the event in AEMEvent.swift as a new case or property (FBAEMKit/FBAEMKit/AEMEvent.swift)
2. Update AEMRule.swift or subclasses to handle matching the new event (FBAEMKit/FBAEMKit/AEMRule.swift)
3. Add serialization logic if the event contains custom parameters (FBAEMKit/FBAEMKit/AEMUtility.swift)
4. Create unit tests in AEMEventTests.swift covering the new event type (FBAEMKit/FBAEMKitTests/AEMEventTests.swift)

Add a new matching operator for rules

1. Add the operator case to AEMAdvertiserRuleOperator.swift (FBAEMKit/FBAEMKit/AEMAdvertiserRuleOperator.swift)
2. Implement comparison logic in AEMAdvertiserSingleEntryRule.swift and/or AEMAdvertiserMultiEntryRule.swift (FBAEMKit/FBAEMKit/AEMAdvertiserSingleEntryRule.swift)
3. Update AEMAdvertiserRuleFactory.swift to instantiate rules with the new operator (FBAEMKit/FBAEMKit/AEMAdvertiserRuleFactory.swift)
4. Write tests in AEMAdvertiserSingleEntryRuleTests.swift and AEMAdvertiserMultiEntryRuleTests.swift (FBAEMKit/FBAEMKitTests/AEMAdvertiserSingleEntryRuleTests.swift)

Extend AEM reporting to a new backend endpoint

1. Add the new endpoint configuration to AEMSettings.swift (FBAEMKit/FBAEMKit/AEMSettings.swift)
2. Create or update AEMRequestBody.swift to serialize the additional payload (FBAEMKit/FBAEMKit/AEMRequestBody.swift)
3. Modify AEMNetworker.swift to invoke the new endpoint in the reporting flow (FBAEMKit/FBAEMKit/AEMNetworker.swift)
4. Add integration tests in AEMReporterTests.swift mocking the new endpoint (FBAEMKit/FBAEMKitTests/AEMReporterTests.swift)

Add a new configuration rule type from backend

1. Define the new rule structure and extend AEMRule.swift if needed (FBAEMKit/FBAEMKit/AEMRule.swift)
2. Update AEMAdvertiserRuleFactory.swift to parse and instantiate the new rule type (FBAEMKit/FBAEMKit/AEMAdvertiserRuleFactory.swift)
3. Ensure AEMConfiguration.swift correctly deserializes rules from JSON (FBAEMKit/FBAEMKit/AEMConfiguration.swift)
4. Write unit tests in AEMAdvertiserRuleFactoryTests.swift and AEMConfigurationTests.swift (FBAEMKit/FBAEMKitTests/AEMConfigurationTests.swift)

• Swift — Primary implementation language for modern iOS SDK; enables type safety and interop with Objective-C legacy code
• undefined — undefined

The repo is mid-migration from Objective-C to Swift—some modules export both old and new interfaces, creating potential for duplicate-symbol errors. Xcode workspace (.swiftpm/xcode/package.xcworkspace) must be used for local development, not the package.json-style approach. Build configuration is xcconfig-heavy; forgetting to update Configurations/ when adding new targets causes silent build failures. The README warns that @import syntax from Objective-C may be required to use newly Swift-defined symbols.

• Objective-C / Swift Interoperability — This codebase is actively migrating from Objective-C to Swift; mastering bridging headers, @import syntax, and protocol/class mapping is essential to avoid link errors
• xcconfig Build Configuration — The Configurations/ directory controls all build variants (Debug/Release, static/dynamic frameworks); understanding configuration inheritance prevents silent misconfigurations
• Swift Package Manager (SPM) Module Structure — FBSDKCoreKit and other modules are published as SPM packages; understanding targets, product definitions, and scheme configuration is needed to add or modify exports
• Graph API and Access Tokens — FBSDKCoreKit manages OAuth 2.0 Facebook access tokens and Graph API calls; understanding token lifecycle and refresh is core to the SDK's purpose
• iOS App Tracking Transparency (ATT) / Privacy — The README highlights iOS 14+ data disclosure requirements; SDK must handle IDFA permissions correctly, affecting all tracking/analytics features
• CocoaPods Podspec Versioning — This SDK is distributed via CocoaPods; understanding podspec structure, subspecs (LoginKit, ShareKit variants), and dependency specifications is needed for release management
• Semantic Versioning and Breaking Changes — The README warns of breaking changes during Swift rewrite; CHANGELOG.md tracks these; understanding SemVer and deprecation patterns prevents breaking downstream apps

• facebook/facebook-android-sdk — Android equivalent of this SDK; developers porting Facebook integration across platforms reference both
• facebook/facebook-python-business-sdk — Python SDK for Facebook's Business APIs; complementary for backend integrations with iOS app events
• apple/swift-package-manager — Underpins the SwiftPM package distribution used in this SDK; understanding SPM fundamentals helps with package configuration
• realm/realm-swift — Large, production Objective-C↔Swift interop codebase; provides patterns for managing dual-language migrations
• firebase/firebase-ios-sdk — Comparable multi-module iOS SDK using similar build infrastructure (xcconfig, SwiftPM, dual-language support)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions workflow for tvOS platform testing

The repo supports tvOS (mentioned in description) but .github/workflows only contains needs-attention.yml and stale.yml. No dedicated tvOS build/test workflow exists. CircleCI config exists but GitHub Actions would provide faster feedback for PRs and better integration with GitHub's platform.

• [ ] Review .circleci/config.yml to understand current tvOS test coverage
• [ ] Create .github/workflows/tvos-build-test.yml that builds FBSDKCoreKit and other frameworks for tvOS
• [ ] Ensure workflow tests both physical tvOS simulator and tvOS device targets
• [ ] Reference Configurations/Platform/iOS.xcconfig and create parallel tvOS config if needed
• [ ] Add matrix strategy to test against multiple tvOS deployment targets

Add unit tests for AEMAdvertiserRuleFactory and AEMAdvertiserRuleMatching protocols

FBAEMKit/FBAEMKit/ contains AEMAdvertiserRuleFactory.swift and AEMAdvertiserRuleMatching.swift but no corresponding test files are visible in the file structure. These are core AEM (Aggregated Event Measurement) protocol/factory classes that need test coverage. This is critical for platform stability.

• [ ] Create FBAEMKit/FBAEMKitTests/AEMAdvertiserRuleFactoryTests.swift with test cases for rule creation
• [ ] Create FBAEMKit/FBAEMKitTests/AEMAdvertiserRuleMatchingTests.swift testing protocol conformance
• [ ] Reference FBAEMKit/Configurations/FBAEMKitTests.xcconfig for test target setup
• [ ] Add tests covering edge cases: invalid rules, malformed JSON, null values
• [ ] Ensure test coverage aligns with FBSDKCoreKit testing patterns by examining existing test files

Create .swiftpm/xcode Swift Package documentation file and add missing schemes

The repo has SwiftPM support (.swiftpm/xcode/xcshareddata/xcschemes/) with only FBSDKCoreKit.xcscheme and Facebook.xcscheme visible. Other major modules (FBAEMKit, etc.) lack dedicated schemes. Also missing README guidance on SwiftPM integration despite CocoaPods/Carthage being documented.

• [ ] Create SwiftPM build scheme for FBAEMKit in .swiftpm/xcode/xcshareddata/xcschemes/FBAEMKit.xcscheme
• [ ] Create SwiftPM build scheme for other major targets (FBSDKLoginKit, FBSDKShareKit if they exist)
• [ ] Create .swiftpm/INTEGRATION.md documenting SwiftPM setup, minimum Swift version, and known limitations
• [ ] Update main README.md with SwiftPM installation instructions (add to section with CocoaPods/Carthage)
• [ ] Test all schemes build successfully using swift build and xcodebuild -scheme

• Add Swift documentation comments (///) to public APIs in FBSDKCoreKit that lack them; grep for 'public func' without preceding ///-comments in Sources/
• Implement missing unit tests for Objective-C types newly wrapped in Swift (check .llms/skills/testing.md for test patterns); identify untested legacy ObjC files in coverage reports
• Expand .llms/skills/public-api-design.md with real examples from a recently-migrated module (e.g., LoginKit); document versioning patterns used for deprecated APIs

The Facebook iOS SDK repository demonstrates generally good security practices with proper project structure, configuration management, and CI/CD integration. However, several areas require deeper analysis: dependency vulnerability scanning cannot be completed without visible Package.swift content, xcconfig files should be audited for hardcoded secrets, and test security coverage should be verified. The codebase lacks visible security documentation or security policy files. No obvious SQL injection, XSS, or critical misconfigurations are apparent from the file structure alone. Recommended actions: enable automated dependency scanning, implement security testing in CI/CD, and create a security.md or SECURITY.md policy document.

• Medium · Missing dependency lock file visibility — Package.swift (not provided). The Package.swift dependency file content is not provided for analysis. This prevents verification of dependency versions, known vulnerabilities, and supply chain security. Swift Package Manager dependencies should be explicitly pinned to specific versions. Fix: Ensure all dependencies are pinned to specific versions in Package.swift. Use swift package update with caution and verify dependency security using tools like Dependabot or similar supply chain scanning tools.
• Low · Potential hardcoded configuration exposure — Configurations/ directory and subdirectories. Multiple .xcconfig files are present in the repository (Configurations directory). These files may contain build-time secrets or sensitive configuration values. While xcconfig files are generally safe, they should be carefully reviewed to ensure no credentials or sensitive data are hardcoded. Fix: Audit all .xcconfig files to ensure no API keys, tokens, or sensitive credentials are hardcoded. Use environment variables or secure configuration management for sensitive data. Add xcconfig files containing secrets to .gitignore.
• Low · Limited visibility into test security practices — FBAEMKit/FBAEMKitTests/ and other test directories. The codebase structure shows test files (FBAEMKitTests) but the actual test implementations are not provided for review. Security tests should verify input validation, authentication, and authorization mechanisms. Fix: Ensure comprehensive security testing including: input validation tests, authentication/authorization tests, sensitive data handling tests, and cryptography validation tests. Review test coverage for security-critical components.
• Low · CI/CD pipeline security review needed — .circleci/config.yml. CircleCI configuration is present but the actual content is not provided. CI/CD pipelines can introduce security risks if not properly configured (e.g., exposed secrets in logs, insecure artifact storage). Fix: Review CircleCI configuration to ensure: secrets are not logged, build artifacts are securely stored, access controls are properly configured, and no credentials are exposed in pipeline outputs.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.