TL;DR
The plugin pins the Graph API version to v24.0. It is not urgent, but it does have a hard deadline.
- Hard deadline: 2028-02-18 — the date Meta expires
v24.0.
- Should be dealt with by: 2027-02-18 — a year of buffer, because the fix has to travel plugin release → app developers upgrade → app store rollout → users actually update.
- Nothing is broken today. This is a calendar item, not a bug.
Why the pin exists
Facebook SDK v18.x hardcodes a default Graph API version that Meta has already deleted:
| Platform |
SDK v18.x default |
Removed by Meta |
| iOS |
v17.0 |
2025-09-12 |
| Android |
v16.0 |
2025-05-14 |
Both are upstream bugs (ios-sdk#2610, android-sdk#1308). The plugin works around them by calling setGraphApiVersion("v24.0") at init on both platforms. That landed in 1af789e (2026-02-25, shipped in 0.25.0) fixing #474.
v24.0 was simply the current version when the fix was written. It is not a compatibility floor — the plugin makes no Graph calls of its own, it only chooses the version the SDK will use. Nothing needs v24.0 specifically.
Where things stand (checked 2026-08-07)
Per Meta's Graph API changelog:
| Version |
Released |
Expires |
| v26.0 (latest) |
2026-07-29 |
TBD |
| v25.0 |
2026-02-18 |
2028-07-29 |
| v24.0 (our pin) |
2025-10-08 |
2028-02-18 |
So the pin is two versions behind, but has roughly 18 months of life left.
Also relevant: Facebook SDK v19 has not shipped (latest is Android 18.3.0, iOS 18.1.0). The README states this whole override becomes a no-op once v19 ships with a corrected default — so the workaround is still load-bearing and cannot yet be deleted.
Why the expiry date is not the whole story
Calls to an expired Graph version are not rejected. Meta silently routes them to the oldest still-usable version, so the app keeps working while running on a version nobody chose. What actually reaches app owners is a deprecation notice from Meta — which is exactly what #474 was.
This means a stale pin degrades quietly rather than failing loudly. The trigger to watch for is Meta announcing a removal floor above v24.0, which can land before the 2028-02-18 expiry. CONTRIBUTING.md already records this as a release-time check.
What the fix looks like
Bump the literal — currently v24.0 — in the three places CONTRIBUTING.md lists, which must stay in sync:
android/src/main/kotlin/id/oddbit/flutter/facebook_app_events/FacebookAppEventsPlugin.kt — FacebookSdk.setGraphApiVersion(...)
ios/facebook_app_events/Sources/facebook_app_events/FacebookAppEventsPlugin.swift — Settings.shared.graphAPIVersion = ...
README.md — the "Graph API Version" section under Known Limitations
It is a one-line-per-file change, but it is a behavioural change for every consumer: newer Graph versions change and remove fields, and SDK v18.x's own code was written against its own default. It deserves its own PR and its own CHANGELOG entry rather than riding along in a release or plumbing commit. (0.30.4 and 0.30.5 both deliberately left it alone for this reason.)
Decision to make when picking it up
Bump to whatever is current at the time, or track one version behind latest? Pinning to the newest release means adopting its breaking changes immediately; staying one behind trades freshness for a version that has been in the wild a while.
Closing conditions
Either of:
- The pin is bumped to a current Graph API version, or
- Facebook SDK v19.x ships with a corrected default, at which point the override is removed entirely (per the README's stated plan) rather than re-pinned.
TL;DR
The plugin pins the Graph API version to
v24.0. It is not urgent, but it does have a hard deadline.v24.0.Why the pin exists
Facebook SDK v18.x hardcodes a default Graph API version that Meta has already deleted:
v17.0v16.0Both are upstream bugs (ios-sdk#2610, android-sdk#1308). The plugin works around them by calling
setGraphApiVersion("v24.0")at init on both platforms. That landed in1af789e(2026-02-25, shipped in 0.25.0) fixing #474.v24.0was simply the current version when the fix was written. It is not a compatibility floor — the plugin makes no Graph calls of its own, it only chooses the version the SDK will use. Nothing needsv24.0specifically.Where things stand (checked 2026-08-07)
Per Meta's Graph API changelog:
So the pin is two versions behind, but has roughly 18 months of life left.
Also relevant: Facebook SDK v19 has not shipped (latest is Android
18.3.0, iOS18.1.0). The README states this whole override becomes a no-op once v19 ships with a corrected default — so the workaround is still load-bearing and cannot yet be deleted.Why the expiry date is not the whole story
Calls to an expired Graph version are not rejected. Meta silently routes them to the oldest still-usable version, so the app keeps working while running on a version nobody chose. What actually reaches app owners is a deprecation notice from Meta — which is exactly what #474 was.
This means a stale pin degrades quietly rather than failing loudly. The trigger to watch for is Meta announcing a removal floor above
v24.0, which can land before the 2028-02-18 expiry.CONTRIBUTING.mdalready records this as a release-time check.What the fix looks like
Bump the literal — currently
v24.0— in the three placesCONTRIBUTING.mdlists, which must stay in sync:android/src/main/kotlin/id/oddbit/flutter/facebook_app_events/FacebookAppEventsPlugin.kt—FacebookSdk.setGraphApiVersion(...)ios/facebook_app_events/Sources/facebook_app_events/FacebookAppEventsPlugin.swift—Settings.shared.graphAPIVersion = ...README.md— the "Graph API Version" section under Known LimitationsIt is a one-line-per-file change, but it is a behavioural change for every consumer: newer Graph versions change and remove fields, and SDK v18.x's own code was written against its own default. It deserves its own PR and its own CHANGELOG entry rather than riding along in a release or plumbing commit. (
0.30.4and0.30.5both deliberately left it alone for this reason.)Decision to make when picking it up
Bump to whatever is current at the time, or track one version behind latest? Pinning to the newest release means adopting its breaking changes immediately; staying one behind trades freshness for a version that has been in the wild a while.
Closing conditions
Either of: