Mobile SDKs 1.3.0 / 0.3.0 / 0.4.0Released October 11, 2026

Automatic delivery on iOS and Android

The native SDKs now deliver events on their own, the same way on iOS and Android: about 5 seconds after the first queued event, when the app goes to the background, and after the next launch for anything left. An iOS app no longer needs to call flush() to be measured.

Analytics

Highlights

iOS SDK 1.3.0 (Swift Package Manager), Android SDK 0.3.0 (webmasterid.com/sdk/maven) and webmasterid_flutter 0.4.0 (pub.dev). Same public channels, no private repository.
One armed delivery about 5 seconds after the first queued event; later events join it and never postpone it. The app goes to the background: delivered at once, best effort.
After the next launch, anything an earlier launch left is delivered once the consent decision is in force — no flush(), no call from your app.
Failures are retried on a timer the SDK arms while the app runs: at most 5 minutes apart, and a server's Retry-After is honoured in full. Retries never give up while events are queued.
A suspended or terminated app runs no timer: undelivered events stay on disk and go out after the app next runs. iOS may suspend or terminate the app before a background delivery finishes.
flush() stays for boundaries you choose; the first-event check in the guide no longer calls it.

What changed, per platform

Before this release an iOS app sent events only when it called flush() or forwarded a background transition, and Android sent about 5 seconds after an event but never at launch; both stopped retrying after eight failures. Now the native client owns delivery on both platforms.

iOS 1.3.0: the client observes UIKit's foreground and background transitions itself and asks for background time with ProcessInfo.performExpiringActivity. Apps that forward the transitions themselves may keep doing so; nothing is sent twice.
Android 0.3.0: the queue an earlier launch left is delivered at startup; retries continue for as long as events are queued.
Flutter 0.4.0: delivery is the native client's. The lifecycle observer only records app_open; flush() and the diagnostics are unchanged.
A placeholder property id (ap_YOUR_PROPERTY_ID) is refused when the client is configured, before anything is stored or sent.

Updating

Raise the dependency and rebuild. On iOS, Swift Package Manager: from: "1.3.0". On Android: com.webmasterid:webmasterid-android:0.3.0. In Flutter: webmasterid_flutter: ^0.4.0, which pins the native SDKs. Consent and identity are restored exactly as before; the first-event check in the guide reads the diagnostics without flushing.

The 1.2.0 / 0.2.0 / 0.3.0 releases stay published and unchanged. An app still on them keeps the earlier delivery until it is updated.
Every published version, asset and checksum is immutable; the installation guide names the versions it was verified with.

What this release does not claim

Delivery depends on the app running. The timing above applies while execution is available; the system decides when a backgrounded app is suspended or terminated.

No background delivery is promised after suspension or termination; no 5-minute retry while suspended.
No change to purchases, App Store notifications or Google Play: those paths are unchanged.
No new event names and no attribution.

iOS, Android and Flutter SDKs, and Apps reports

WebmasterID now measures iOS and Android apps: public SDKs, consent-first events and five Apps reports beside your website reports, in the same workspace.

iOS SDK 1.2.0 from Swift Package Manager, Android SDK 0.2.0 from the Maven repository at webmasterid.com/sdk/maven, and webmasterid_flutter 0.3.0 from pub.dev. No private repository or access token.
Apps reports in the dashboard: Overview, Events, Conversions, Retention (beta) and Attribution, next to the Web reports.
Consent first: nothing is queued or sent until the app passes the user's decision, and the server refuses advertising identifiers.
+ 3 more — see the release page

Read release notes →