# facebook-ios-sdk: what the Facebook SDK for iOS actually installs, and what it costs you > The Meta-maintained SDK that wires Facebook Login, Sharing, App Links and the Graph API into iOS and tvOS apps. A practical read on the Swift rewrite, the module split, and the cases where it is the wrong dependency. **facebook/facebook-ios-sdk** — Used to integrate the Facebook Platform with your iOS & tvOS apps. - Repository: https://github.com/facebook/facebook-ios-sdk - Website: https://developers.facebook.com/docs/ios - Stars: 8,112 · Forks: 3,698 - Language: Swift - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/facebook-facebook-ios-sdk ## What facebook-ios-sdk is for, and who should pull it in The README states the library "allows you to integrate Facebook into your iOS app", and lists five feature areas: Login, Sharing, App Links, Graph API and Analytics. That list is the honest scope. It is not a general networking layer and it is not an analytics product you would pick on its own merits. It is the client-side half of the Facebook Platform, and you adopt it when your product has already decided to use that platform. The audience is narrow and concrete. A consumer app that wants "Continue with Facebook" on its sign-in screen. A content app that wants its share sheet to post to Facebook. A growth team that needs App Links so a link opened on a phone lands in the right place in the app. In each case the SDK is the supported path, and hand-rolling the same flows against the Graph API means reimplementing login state, token refresh and the platform's own rules. If none of those three sentences describe your roadmap, the SDK is dead weight. Facebook Analytics is not a reason to add it, and neither is "we might want login later". The dependency carries a developer agreement, a privacy disclosure obligation and a module graph that will show up in your build times. ## The module split, and why FBSDKCoreKit is not the whole SDK The repository layout is the clearest documentation of the architecture. At the top level sit five podspecs, each paired with a directory of the same name: FBSDKCoreKit.podspec with FBSDKCoreKit/, FBSDKCoreKit_Basics.podspec with FBSDKCoreKit_Basics/, FBSDKLoginKit.podspec with FBSDKLoginKit/, FBSDKShareKit.podspec with FBSDKShareKit/, FBAEMKit.podspec with FBAEMKit/, and FBSDKGamingServicesKit.podspec with FBSDKGamingServicesKit/. There is also a Package.swift at the root and a FacebookSDK.xcworkspace that ties the pieces together for development. That structure tells you the dependency is modular by design. FBSDKCoreKit_Basics is the low-level layer; FBSDKCoreKit sits above it and carries the app-level plumbing; login, sharing, gaming services and aggregated event measurement are separate modules that depend on core. When the README says to "select the `Facebook`-prefixed libraries you want to use" in Swift Package Manager, it is describing exactly this: you are expected to pick a subset, not the whole set. A login-only integration should not be pulling in the share kit. FBAEMKit is the module worth naming explicitly, because it is the one people discover late. It exists to support Aggregated Event Measurement, the mechanism Facebook introduced for reporting conversions after Apple's tracking changes. If your team measures installs or purchases through Facebook, that module is doing real work whether or not anyone on the team has read its name. The README also carries a warning box: the SDK is being rewritten in Swift to "modernize the code base", and during that process "some interfaces will be unstable". It says updating to a minor version may introduce compilation issues related to language interoperability, that using symbols now defined in Swift may require `@import` syntax from Objective-C, and that C++ will likely need workarounds such as Objective-C wrappers. That is an unusual thing for a vendor to put in a README, and it should be read as a genuine constraint rather than marketing hedging. ## Installing facebook-ios-sdk with Swift Package Manager The README's TRY IT OUT section documents Swift Package Manager as the first path. In Xcode you select File > Swift Packages > Add Package Dependency, follow the prompts using the URL for this repository, then select the `Facebook`-prefixed libraries you want. There is no separate command-line step documented, so the Xcode flow is the one to follow. The repository also ships a Package.swift at the root, which is what makes the SPM path work and what the samples/SmoketestSPM/ sample exercises. The README does not print the package URL as a code line, but it says to use the URL for this repository, which is https://github.com/facebook/facebook-ios-sdk. That is the value you paste into the Add Package Dependency prompt. After adding it, the README points at https://developers.facebook.com/docs/ios/getting-started for tutorials and https://developers.facebook.com/docs/ios for reference documentation. That is where the actual first-use code lives; the repository README does not include a login snippet. The samples directory is the other place to look, with samples/FacebookLoginSample/ and samples/FacebookShareSample/ as the two most directly useful starting points. ## Installing facebook-ios-sdk with CocoaPods and Carthage The badge row at the top of the README advertises both CocoaPods and Carthage compatibility, and the podspecs confirm the CocoaPods side: FBSDKCoreKit, FBSDKLoginKit, FBSDKShareKit, FBAEMKit, FBSDKCoreKit_Basics and FBSDKGamingServicesKit each have their own podspec. That means a Podfile can pull in only what the app uses, and the pod names you would reference are exactly those podspec filenames, minus the .podspec extension. Because each module is published separately, adding FBSDKLoginKit without FBSDKCoreKit is not the intended shape; core is the shared layer the others build on. The README does not spell out the transitive dependency rules, so if you are trimming pods, check what the resolver pulls in rather than assuming. It also does not print a Podfile example, so the podspec names in the repository root are the authoritative list to work from. Carthage is listed as compatible via the badge, but the README gives no Carthage instructions and the repository has no Cartfile in its top-level entries. Treat the badge as a statement of compatibility rather than a documented setup path. ## The Swift rewrite is the real integration risk The most consequential thing in the README is the warning box, and it deserves more attention than the feature list. Meta is rewriting the SDK in Swift, and the README says plainly that "some interfaces will be unstable during this process" and that "updating to a minor version may introduce compilation issues related to language interoperability". That is a specific, checkable failure mode. It means a routine pod update or package resolution bump can break a build that compiled yesterday, and the fix may be a syntax change on your side rather than a bug on theirs. The README names two remedies: `@import` syntax from Objective-C for symbols now defined in Swift, and Objective-C wrappers as a workaround for C++ code. If your app is Objective-C, or if it links C++ through the SDK, budget time for this on every minor upgrade rather than treating it as a one-off migration. The second limitation is contractual rather than technical. The DEVELOPER TERMS in the README state that enabling Facebook integrations shares information about people's use of your app with Facebook, that Facebook uses it to provide insights about ad effectiveness, and that the integrations "enable us and our partners to serve ads on and off Facebook". They also require that you have given users appropriate notice and obtained consent, and state that you "will not share information with us about children under the age of 13". That last clause is a hard boundary: if your app is directed at children under 13, this SDK is not a defensible choice, regardless of what the code does. The third constraint is the iOS 14 section. The README says tracking events your app collects and sends to Facebook may need to be disclosed in the App Store Connect questionnaire, that keeping this reflected in your privacy policy is your responsibility, and it links to Apple's App Privacy Details page. Nothing in the SDK does that disclosure for you. ## When to use a thinner alternative instead The honest alternative is not another SDK of the same kind. It is the platform's own authentication, Sign in with Apple, and a plain URLSession or ASWebAuthenticationSession call for anything else you need from a social API. The difference in approach is structural. facebook-ios-sdk is a set of prebuilt modules that manage Facebook session state, token handling and the platform's specific flows on your behalf, and in exchange it embeds Meta's code, its update cadence and its terms into your app. Sign in with Apple is a system framework with no third-party dependency, no developer agreement beyond Apple's, and no ad-serving clause. If your only requirement is "let users create an account without typing a password", the system option does the job with less surface area. The trade-off is reach and features. Sign in with Apple cannot post to Facebook, cannot resolve an App Link into your app, and does not participate in Facebook's ad measurement. If your growth model depends on Facebook distribution, the SDK is the supported path and the thinner alternative simply does not cover the requirement. If it does not, you are paying the integration and compliance cost for capability you will not use. One more practical note: the README directs bug reports to https://developers.facebook.com/support/bugs/ rather than to the GitHub issue tracker, and points to Stack Overflow under the facebook-ios-sdk tag for questions. That is where support actually happens, and it changes how you should plan for turnaround on a blocking bug. ## Maintenance, licensing and upgrade cost The repository is not archived, and the last push was on 2026-09-21, one day before this was written. Recent releases are v18.1.1 on 2026-08-27, v18.1.0 on 2026-06-22 and v18.0.3 on 2026-02-11. The cadence is real, and the README asks you to subscribe to releases so you are notified about "new features, deprecations, and critical fixes", with CHANGELOG.md as the record. Upgrade cost has two components. The first is the Swift rewrite risk described above, which makes minor-version bumps potentially source-breaking for Objective-C and C++ interop. The second is deprecation churn: the README's request to watch the changelog exists because interfaces do get retired. A team that pins an old major version and never reads the changelog will eventually be upgrading under duress. On licensing, the repository's LICENSE file is the governing document, and the GitHub metadata reports the licence as NOASSERTION, meaning the platform could not classify it automatically. The README itself says only "See the LICENSE file" and carries a copyright line for Meta Platforms, Inc. That is not a permissive licence you can assume; read LICENSE and NOTICE before shipping, and route anything ambiguous to your own counsel. The DEVELOPER TERMS are separate from the licence and bind you by use, not by distribution: they cover data sharing, ad serving, consent obligations and the under-13 restriction. A permissive code licence would not neutralize those terms. ## Conclusion Adopt facebook-ios-sdk if your product genuinely needs Facebook Login, Facebook sharing or App Links, and you accept the developer terms and the iOS 14 data disclosure work that comes with them. Do not adopt it for analytics alone, and do not adopt it if your users are children under 13, since the developer terms rule that out. Before writing code, verify two things: which module actually carries the feature you need (FBSDKLoginKit for login, FBSDKShareKit for sharing, FBAEMKit for aggregated event measurement), and whether the current minor version compiles against your Objective-C or C++ interop code, because the README warns that some interfaces are unstable during the Swift rewrite. ## FAQ ### What is the Facebook SDK for iOS used for? The README describes it as an open-source library that lets you integrate Facebook into your iOS app, and lists Login, Sharing, App Links, Graph API and Analytics as the feature areas. It is the client-side half of the Facebook Platform, so it is adopted when a product has already decided to use that platform rather than as a general networking or analytics dependency. ### What does iOS SDK mean? In this repository the term refers to the Facebook SDK for iOS, a library the README says integrates Facebook into your iOS app and which is distributed as separate modules such as FBSDKCoreKit, FBSDKLoginKit and FBSDKShareKit. The README points to https://developers.facebook.com/docs/ios for the reference documentation. ### Is the Facebook iOS SDK free? The README describes the library as open source and points to the LICENSE file, while the GitHub metadata reports the licence as NOASSERTION, so the platform has not classified it automatically. Cost is not only licensing: the README's DEVELOPER TERMS also bind you to data sharing, ad serving and consent obligations when you enable Facebook integrations. ## Sources - [facebook/facebook-ios-sdk on GitHub](https://github.com/facebook/facebook-ios-sdk) - [Issues](https://github.com/facebook/facebook-ios-sdk/issues) - [Project website](https://developers.facebook.com/docs/ios) - [README](https://github.com/facebook/facebook-ios-sdk/blob/main/README.md) - [Releases](https://github.com/facebook/facebook-ios-sdk/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebook-facebook-ios-sdk