SDK Versions

Flutter is ahead of the two natives it bridges — expected, since it versions independently as a bridge package, not in lockstep with what it bridges.

Three separate version notions per native SDK — don’t conflate them

Each native SDK has three independent version numbers, none of which are currently linked to each other:

1. The published artifact version — a Gradle property (onesygnalVersion, defaulting to 0.1.0) or the podspec’s s.version field. This is what a dependency manager resolves.
2. The runtime-reported SDK version (SDK_VERSION on Android, sdkVersion on iOS) — a hardcoded constant sent to the backend for analytics/support purposes, currently 0.1.0 on both, matching (1) today only because nobody has published a new version yet.
3. The library version for $lib_version (LIB_VERSION on Android, libVersion on iOS) — a separate hardcoded constant, also currently 0.1.0.

Publishing a new artifact with e.g. -PonesygnalVersion=0.2.0 would ship a package whose own runtime constants still report 0.1.0 — nothing currently enforces these three staying in sync. A separate version-consistency test checks that apps/flutter-sdk/pubspec.yaml, the Flutter plugin’s own ios/onesygnal.podspec (s.version), and both wrapper-version constants (WRAPPER_VERSION/wrapperVersion, currently 0.4.0) agree with each other — but that only covers the Flutter bridge’s own versioning, not the two native artifact/runtime/lib version triples above. If you’re debugging a version mismatch report from an integrator, check which of these you’re actually looking at.

See Distribution Model for how these artifacts are (and currently aren’t) published.