HELPERG (opens in a new tab) Ecosystem

WebmasterID logoWebmasterID
Menu

← All releases

App analytics

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.

AnalyticsCore

Highlights

What shipped

Two steps, three days apart. On 7 October 2026 the SDKs went live on public channels. On 10 October 2026 the dashboard gained an Apps section beside Web, and the installation guide was rewritten after it was followed literally on Android and iOS.

  • iOS: WebmasterID iOS SDK 1.2.0, a public Swift package, for iOS 15.0 or later.
  • Android: WebmasterID Android SDK 0.2.0 for Kotlin or Java, from webmasterid.com/sdk/maven, for API 24 (Android 7.0) or later.
  • Flutter: webmasterid_flutter 0.3.0 on pub.dev, for Flutter 3.47.0 or later, running on the native SDKs on iOS and Android.
  • Dashboard: register an app under iOS apps or Android apps, copy its public property ID and the install steps for the public SDKs, and read the five Apps reports.

What the Apps reports show

Every report counts by the time WebmasterID received an event, not by the device's clock. The overview lists what the reports can and cannot answer.

  • Overview: events, sessions, active installations, first-observed installations and identified users, events per day, top events, and tracking health.
  • Events: each of the 14 event names with counts and sessions, top screens and countries, and the 50 most recent events with shortened pseudonymous identifiers.
  • Conversions: app-reported funnel events in one table, store-verified purchases in another.
  • Retention (beta): Day 1, 7 and 30 cohorts by installation; a day that has not passed is not yet observable, never 0%.
  • Attribution: what is known about where app activity came from. The SDKs send no source, campaign or referrer, so install sources show as unknown, never as organic.

Consent and identity

The app passes the user's decision to the SDK. Allowed: events carry a session ID, an installation ID and, after identify(), an account key; the server stores the installation ID and account key as keyed hashes, which are pseudonymous, not anonymous. Restricted: a session ID only, which is reduced identification, not anonymity. Disabled: nothing is sent.

  • The server refuses IDFA, IDFV, the Android advertising ID and other device identifiers.
  • App Tracking Transparency is not requested; an ATT answer is not consent to analytics.
  • The country comes from the network edge; no IP address or user agent is stored.

Purchases

Optional, and separate from analytics. On iOS the SDK forwards Apple-signed StoreKit 2 transactions, which the server checks against Apple's certificates; on Android it forwards Google Play purchase tokens, which the server checks with Google. Store notifications are connected on the app's page in the dashboard. Only production, revenue-bearing purchases count, gross before refunds and per currency.

  • App Store notification delivery is verified in production.
  • The Google Play side is deployed but not yet proven end to end with a test purchase.
  • No purchase has yet been carried through either store's sandbox and verified.
  • RevenueCat and other purchase frameworks are not supported.

What it does not do

WebmasterID is not a mobile measurement partner, and app reports stay separate from website reports.

  • No install attribution: no ad-network postbacks, SKAdNetwork, Apple AdServices, Google Play Install Referrer, deep-link campaigns, cost or ROAS.
  • First-observed installations are not App Store or Google Play downloads.
  • No custom event names or properties; no app version or OS breakdowns.
  • No combined web-and-app report and no matching of a person across devices.
  • App data is not in the Event Explorer, exports, or the MCP and agent tools.
  • No React Native, Unity or .NET SDK.

Getting started

Registering an app collects nothing. Events appear once the app has the SDK installed, starts it with the user's consent decision, sends events and delivers them.

  • New customers: create an account and choose Pro or Agency at checkout.
  • Existing customers: open iOS apps or Android apps in the dashboard and register the app.
  • Then follow the installation guide at webmasterid.com/docs/mobile-sdk to the first event, and check it in Apps → Overview → Tracking health.

Tags

AnalyticsCore

Each tag links back to the filtered changelog.

Related

More releases

Mobile SDKs 1.3.0 / 0.3.0 / 0.4.0
Analytics

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.

  • 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.
  • + 3 more — see the release page
Read release notes →
Core v1.8.1
CoreAgentMCPBillingOnboardingSecurityUX

Core v1.8.1 — MCP server, workspaces, billing, and operator visibility

The rollup release: a real MCP HTTP server, workspace-scoped multi-tenancy, Stripe-backed billing, full onboarding, and the new operator identity surfaces.

  • Real MCP HTTP server at /api/agent/mcp with workspace-scoped Bearer auth and ten read-only tools.
  • Workspace switcher + operator profile in the dashboard sidebar; copyable user IDs on /settings/account.
  • Stripe billing with three plans (Pro / Agency / Business), signature-verified webhooks, and a customer portal.
  • + 3 more — see the release page
Read release notes →