Which Facebook SDK version a Flutter app gets, and what controls it

The plugin declares a version range on each platform and your build resolves inside it. Three declarations, one per integration path, and they are the answer to the question:

All three say the same thing in three dialects: any 18.x, nothing from 19. The podspec says why in a comment on the line above:

Do not specify PATCH version of FBSDKCoreKit. See README file for explanation.

Those are the constraints shipping in plugin 0.30.5. They move only in a plugin release, and the CHANGELOG records it when they do.

This is a decision rather than an accident, and the README states it: the plugin follows the major version of the current Facebook SDK, in order to be as compatible as possible with other dependencies in your project.

The consequence is the part that surprises people, and the README says it plainly. You get "the latest version" up until the next major release, and it might be a source of unexpected behavior for you if you are not aware of this. You are now aware of it.

The alternative was considered and rejected. Locking the plugin to a specific minor version of the SDK causes incompatibilities with other plugins and dependencies in a consumer's project. Whichever minor we chose would be the wrong one for somebody, and they would have no way around it except forking. A range lets your resolver pick a version that satisfies your whole dependency graph rather than only ours.

So it is a trade, stated honestly: you get a plugin that coexists with the rest of your dependencies, and you give up knowing the exact SDK build without looking it up. The last section on this page is how to look it up.

Here is what a floating, major-pinned range actually produces, and it is the thing you cannot learn from either of Meta's release-notes pages.

At plugin 0.30.5, the Android Maven range covers the latest 18.x release, which is 18.3.0. The iOS pins cover the latest 18.x release, which is 18.1.0.

Same plugin, same policy written three ways, two different minor versions inside one app. That is not a defect and it is not a mismatch to correct. The Android and iOS SDKs are separate projects with separate release histories, so "the latest 18.x" is simply a different number on each side.

Three practical consequences:

• Read each platform's release notes separately. There is no single Facebook SDK version number for your app to have.
• When you report a problem, give both resolved versions. One of them alone leaves half the question open.
• If your Android and iOS builds behave differently, check the two resolved versions before you assume the difference is in your own code. It may be, but this is cheaper to rule out.

Four floors, and all four are declared in the plugin's own manifests rather than in documentation you have to take on trust:

Why Flutter 3.38

Not a preference. The plugin's iOS side uses Flutter's scene-delegate plugin APIs, FlutterSceneLifeCycleDelegate and addSceneDelegate, which were added in Flutter 3.38. Below that release the symbols do not exist. What it buys you is covered in the Swift Package Manager guide.

iOS 13.0, and why the example app is not the contract

13.0 has been the plugin's real minimum since 0.26.0, declared in both s.ios.deployment_target in the podspec and platforms: [.iOS(.v13)] in Package.swift.

The example app's Xcode project setting said 12.0 until 0.30.5, when it was raised to match. It had simply never been updated. If you were reading the example app to work out the minimum, you were reading the wrong file. The podspec and the package manifest are the contract; the example is a sample that has to compile.

The Android toolchain, at 0.30.5

Useful when it is your build failing rather than your events: Kotlin 2.4.10, AGP 8.13.0, Gradle pinned at 8.13 to match AGP 8.13.x, compileSdk and targetSdk 36, and minSdk 21. Those are the plugin's own numbers, from android/build.gradle and the Gradle wrapper, and the CHANGELOG records each change to them.

One version on this page is not a dependency range, and it is the reason the plugin sets anything at startup at all. Facebook SDK 18.x ships with a default Graph API version that Meta has already removed, and the default differs per platform.

The plugin overrides that during plugin initialization, so most apps need no configuration for it. As of plugin 0.30.5 the version it sets is v24.0. Treat the plugin's README and CHANGELOG as the source of truth for the current literal, because it moves as Meta's supported range moves.

What a removed version actually does

It does not make your requests fail. Meta's versioning guide states that once a version is no longer usable, calls made to it are set to default to the oldest next version that is still usable. An app left on a removed default keeps working, served by a version nobody chose.

What lands on you is the notice. Meta emails app owners a removal deadline, and that deadline comes from Meta's current developer-notification floor rather than from the expiry date of the version you happen to be on. The floor moves on Meta's schedule, independently of any one version's expiry. Issue #474 on this plugin is one of those emails, and the full story is in Facebook events not showing in Events Manager.

If you need a specific version

Call setGraphApiVersion as early as possible in startup, before anything that can trigger a Graph API request. Your call wins: the plugin sets its default when it attaches to the engine, and your Dart call runs after that.

final facebookAppEvents = FacebookAppEvents();

// Optional. The plugin already sets a current default at initialization.
await facebookAppEvents.setGraphApiVersion('v24.0');

await facebookAppEvents.activateApp();

Do not infer it from this page. Read it out of the files where each toolchain records the version it actually chose.

iOS

With CocoaPods, ios/Podfile.lock names the resolved FBSDKCoreKit version. With Swift Package Manager, Package.resolved names the resolved facebook-ios-sdk version.

Android

Gradle will print the version it selected for a configuration:

cd android
./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep facebook-android-sdk

The dependency report names the version Gradle selected out of the range, which is an answer rather than a guess.

What happens at Facebook SDK 19

[18.0,19.0) and "18.0.0"..<"19.0.0" both exclude 19 by construction. A Facebook SDK 19 release therefore does not reach your app on its own: the ranges have to move first, and that happens in a plugin release. So when you are planning an upgrade across a Facebook SDK major, the plugin's CHANGELOG is the file that tells you whether it is available yet. Meta's release notes tell you only that the SDK exists.