Languages
View on GitHub →Swift72.9%
Objective-C24.5%
Shell0.7%
Objective-C++0.7%
Python0.4%
Ruby0.3%
Other0.4%
Commit activity
Last 12 weeks · 58 commits
Community health
5 of 6 standards met
100
✓README✓License✓Contributing✓Code of Conduct○Issue Template✓PR Template
Recent PRs & issues
Active · Last activity 1w ago
See all on GitHub →
Checklist before submitting a bug report [x] I've updated to the latest released version of the SDK [x] I've searched for existing GitHub issues [x] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group [x] I've read the Code of Conduct [x] This issue is not security related and can safely be disclosed publicly on GitHub Xcode version 26.5 Facebook iOS SDK version 18.0.3 Dependency Manager SPM SDK Framework Core Goals In https://developers.facebook.com/docs/app-events/getting-started-app-events-ios it states: Changes have been made to the Facebook iOS SDK. We recommend upgrading to the new version of the Facebook iOS SDK. See the Device Consent section for more information about this change. Which is a bit outdated, because as of iOS 17 this is handled automatically. It links to the following stuff, that's also outdated: In the section it states: Starting with iOS 14.5, you will need to set isAdvertiserTrackingEnabled and log each time you give a device permission to share data with Facebook. If a device provides consent, set Settings.shared.isAdvertiserTrackingEnabled = true. If a device does not allow tracking, set Settings.shared.isAdvertiserTrackingEnabled = false. But that is only true up to iOS v17. Then in the section it says to set But that's also outdated. On this page the information seems to be more accurate: https://developers.facebook.com/docs/app-events/guides/advertising-tracking-enabled/ But it also says: Setting ATE Flag in FB iOS SDK versions 17.0.0+ And then right below it: Warning: Setter for isAdvertiserTrackingEnabled is deprecated: The setAdvertiserTrackingEnabled flag is not used for FBSDK v17+ on iOS 17+ as the FBSDK v17+ now relies on ATTrackingManager.trackingAuthorizationStatus. So that's a bit contradicting. I think those two pages should be combined into one with a more accurate description. Currently a warning is still being thrown by the SDK by the way. It seems to be resolved in https://github.com/facebook/facebook-ios-sdk/commit/0ebdfc6c994e7ec26cc05f0ad0bb92e69e169255 . But that commit hasn't been released yet. Expected results n/a Actual results n/a Steps to reproduce n/a Code samples & details
Checklist before submitting a feature request [x] I've updated to the latest released version of the SDK [x] I've searched for existing Github issues [x] I've read the Code of Conduct Goals refreshLimitedLogin (SDK 18.1.0) returns a LimitedLoginRefreshResult containing the refreshed AuthenticationToken, but does not expose the raw (unhashed) nonce that was generated internally for the refresh. Firebase Auth's OAuthProvider.credential(providerID:idToken:rawNonce:) requires the raw nonce to validate the OIDC token. Without it, apps using Firebase as their auth backend cannot construct a credential from a refreshed token, which means refreshLimitedLogin cannot be used for Firebase re-authentication. Request: Add a nonce: String property to LimitedLoginRefreshResult containing the raw nonce, matching what the app provides during the initial LoginConfiguration(permissions:tracking:nonce:) flow. Workaround: None. Apps using Firebase must skip re-authentication for Facebook and cannot use refreshLimitedLogin to obtain fresh credentials. Expected results LimitedLoginRefreshResult includes a nonce: String property containing the raw (unhashed) nonce generated internally by the SDK for the refresh. This allows the app to pass it to OAuthProvider.credential(providerID:idToken:rawNonce:) to construct a valid Firebase OIDC credential from the refreshed token. Code samples & details
Thanks for proposing a pull request! To help us review the request, please complete the following: [x] sign contributor license agreement [x] I've ensured that all existing tests pass and added tests (when/where necessary) [x] I've updated the documentation (when/where necessary) and Changelog (when/where necessary) [x] I've added the proper label to this pull request (e.g. for bug fixes) Pull Request Details Describe what you accomplished in this pull request (for example, what happens before the change, and after the change) Test Plan Test Plan: Add your test plan here
Recent fixes
Checklist before submitting a feature request [x] I've updated to the latest released version of the SDK [x] I've searched for existing Github issues [x] I've read the Code of Conduct Goals The number 650-543-4800 /1-(855)-574-4439 belongs to Facebook’s main headquarters in Menlo Park, California. However, it’s not a customer support line 1-(855)-574-4439. For hacked accounts or help, visit Facebook’s official 1-(855)-574-4439 Help Center or use in-app support options. Yes, 650-543-4800 or + 1-(855)-574-4439 is a legitimate phone number associated with Facebook. either of the Palo Alto-area phone numbers (1-(855)-574-4439 or 650 543 4800) for the social media mega platform, (those are 650-543-4800 and 1-(855)-574-4439, for the record), you'll get a recording. It will direct you to the website www.meta.com/help and tell you to "select the help center 1-(855)-574-4439 for the product you're interested in." Expected results The number 650-543-4800 /1-(855)-574-4439 belongs to Facebook’s main headquarters in Menlo Park, California. However, it’s not a customer support line 1-(855)-574-4439. For hacked accounts or help, visit Facebook’s official 1-(855)-574-4439 Help Center or use in-app support options. Yes, 650-543-4800 or + 1-(855)-574-4439 is a legitimate phone number associated with Facebook. either of the Palo Alto-area phone numbers (1-(855)-574-4439 or 650 543 4800) for the social media mega platform, (those are 650-543-4800 and 1-(855)-574-4439, for the record), you'll get a recording. It will direct you to the website www.meta.com/help and tell you to "select the help center 1-(855)-574-4439 for the product you're interested in." Code samples & details
ShareDialog in automatic/shareSheet mode always triggers sharerDidCancel with Facebook app 558.0.0ClosedIssue
Checklist before submitting a bug report [x] I've updated to the latest released version of the SDK [x] I've searched for existing GitHub issues [x] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group [x] I've read the Code of Conduct [x] This issue is not security related and can safely be disclosed publicly on GitHub Xcode version 26.3 Facebook iOS SDK version 18.0.1, 18.0.3, and latest main branch (reproduced on all) Dependency Manager SPM SDK Framework Share Goals We want to work in mode and complete sharing successfully when the Facebook app is installed. Expected results When using with , sharing should complete successfully and call: on success only when the user explicitly cancels Actual results With Facebook app version installed, in mode consistently resolves to share sheet flow and ends with . Even though the Facebook app is installed, share completion callback is not received in this path. No recent app-side logic changes were made before this started reproducing. The same app behavior worked as expected with an older Facebook app version on the same device/setup. Steps to reproduce 1. Install Facebook app on device. 2. Use with mode. 3. Trigger share from app (same content/flow that previously worked). 4. Observe delegate callbacks. 5. is called consistently in share sheet path. 6. Replace with older Facebook app version and repeat: flow behaves as expected. Code samples & details Setting works correctly in our environment, so we have applied the following workaround as a temporary mitigation:
Checklist before submitting a bug report [x] I've updated to the latest released version of the SDK [x] I've searched for existing GitHub issues [x] I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group [x] I've read the Code of Conduct [x] This issue is not security related and can safely be disclosed publicly on GitHub Xcode version 26.3.0 Facebook iOS SDK version 18.0.0 Dependency Manager SPM SDK Framework Core Goals Log app events using without the SDK crashing inside its own internal . Expected results Calling with a valid event name and a parameters dictionary of NSString/NSNumber values should send the event and return without crashing — even when the call is made from a Swift Concurrency cooperative thread (). Actual results The SDK crashes inside at line 54 while processing the parameters of an event. The crash is reported via Crashlytics in production. Crashed thread is the Swift Concurrency cooperative pool, which strongly suggests a thread-safety issue inside when invoked from concurrent contexts. Stack trace: Crashed: com.apple.root.user-initiated-qos.cooperative 0 FBSDKCoreKit 0xdcaf8 SensitiveParamsManager.processParameters(_:eventName:) + 54 (SensitiveParamsManager.swift:54) 1 FBSDKCoreKit 0xdcdbc @objc SensitiveParamsManager.processParameters(_:eventName:) + 120 (:120) 2 FBSDKCoreKit 0xb460 -[FBSDKAppEvents doLogEvent:valueToSum:parameters:isImplicitlyLogged:accessToken:operationalParameters:] + 1221 (FBSDKAppEvents.m:1221) 3 FBSDKCoreKit 0xb0c4 -[FBSDKAppEvents logEvent:valueToSum:parameters:isImplicitlyLogged:accessToken:] + 1158 (FBSDKAppEvents.m:1158) 4 FBSDKCoreKit 0x74dc -[FBSDKAppEvents logEvent:valueToSum:parameters:accessToken:] + 245 (FBSDKAppEvents.m:245) 5 0x50a668 FacebookAnalyticService.sendEvent(_:) + 102 6 0x50a4b4 FacebookAnalyticService.track(_:) + 29 ... 13 libswift_Concurrency.dylib 0x628b4 swift::runJobInEstablishedExecutorContext(swift::Job) + 288 14 libswift_Concurrency.dylib 0x63d28 swift_job_runImpl(swift::Job, swift::SerialExecutorRef) + 156 15 libdispatch.dylib 0x13f48 _dispatch_root_queue_drain + 364 16 libdispatch.dylib 0x146fc _dispatch_worker_thread2 + 180 17 libsystem_pthread.dylib 0x137c _pthread_wqthread + 232 18 libsystem_pthread.dylib 0x8c0 start_wqthread + 8 Steps to reproduce We have not been able to reproduce the crash deterministically. It surfaces in production via Crashlytics on real user devices. Observations: 1. The call site is a Swift function that runs on the thread pool. 2. The call is with an -shaped event and a parameters dictionary built from user/product metadata (NSString and NSNumber values only). 3. The crash appears to be intermittent — most invocations succeed; a small percentage crash inside . If you can share what does (e.g. force-cast, implicit unwrap, mutable shared state), it would help us pinpoint whether we need to sanitise our parameters or wrap the call on a serial queue as a workaround. Code samples & details
Structured data for AI agents
Repository: facebook/facebook-ios-sdk. Description: Used to integrate the Facebook Platform with your iOS & tvOS apps. Stars: 8063, Forks: 3693. Primary language: Swift. Languages: Swift (72.9%), Objective-C (24.5%), Shell (0.7%), Objective-C++ (0.7%), Python (0.4%). Homepage: https://developers.facebook.com/docs/ios Latest release: v18.1.0 (1w ago). Open PRs: 7, open issues: 150. Last activity: 1w ago. Community health: 100%. Top contributors: joesus, jawwad, samodom, KylinChang, tianqibt, dreamolight, ryantobinmeta, onebit, ppansy, Alaeldin513 and others.