asalyze changelog and release notes | pub.dev

NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →

3.1.610 Sept 2026

Verified on the device: an iPhone XS on iOS 16.3.1 died at currency: tx.currencyCode with EXC_BAD_ACCESS at 0x0, and the same build with this change l

Verified on the device: an iPhone XS on iOS 16.3.1 died at currency: tx.currencyCode with
EXC_BAD_ACCESS at 0x0, and the same build with this change launches clean.

Below iOS 17.2 neither property is stored — both parse the raw JWS by keypath, through different
transforms — and the two carry different back-deployment thresholds:

currencyCode   @backDeployed(before: iOS 16.0)   → on 16.3 dispatches to the OS symbol
currency       @backDeployed(before: iOS 17.2)   → on 16.3 runs the copy compiled into the app

That asymmetry also explains the crash log, which had frame 0 in a NULL image (base 0, size 0, zero
UUID) with StoreKit absent from the stack. A back-deployment dispatch is itself a call through a
resolved function pointer, so a failed resolution branches to address 0 having never entered StoreKit —
which is why "StoreKit is not on the stack" did not rule this accessor out.

From iOS 17.2 both are a stored property, so this costs nothing there. iOS 15 keeps the old call: it is
the one OS with no alternative, and it reaches a different accessor entirely.

Credit where due: the app-side engineer identified this line and this fix. I argued against the
mechanism twice — a Swift trap would indeed have been EXC_BREAKPOINT — while the remedy was right all
along, and the locking work in 3.1.4/3.1.5 fixed a real defect that was not what was crashing.

Open source →

3.1.410 Sept 2026

StoreKitObserver.environment was a plain var String . The Runtime writes it once await AppTransaction.shared returns — a storekitd round trip that tak

StoreKitObserver.environment was a plain var String. The Runtime writes it once
await AppTransaction.shared returns — a storekitd round trip that takes seconds on a cold
launch — while the transaction sweep is already reading it for every transaction it emits.
Reading a String retains a buffer; writing one releases the old buffer. 3.1.0 added rescan(),
so from then on two sweeps read it concurrently, the same buffer could be released by parties
that no longer agreed on who owned it, and the freed memory was reused. A Swift Task later
resumed into a null function pointer: EXC_BAD_ACCESS, pc = 0, ten seconds into launch. Seen on
an iPhone XS on iOS 16.3, where AppTransaction is slow enough to land mid-sweep.

Every mutable field on the observer is now behind a lock and read once into a local.

Also in this release:

Each purchase was reported twice since 3.1.0 — the sent-marker is only written after the POST
lands, so both sweeps read "not sent". A transaction is claimed the moment it is emitted, and
a failed report hands the claim back so an in-session retry still works.
Storage.markTransactionSent was a read-modify-write over three UserDefaults calls with no
lock: concurrent reporters erased each other's ids, and those purchases were re-sent forever.
A non-finite ad value could terminate the HOST app. GADAdValue.value can be
NSDecimalNumber.notANumber, and JSONSerialization RAISES an ObjC exception on NaN rather than
throwing, so try? never saw it. Non-finite values are dropped and the encoder is checked.
didBecomeActive is not a purchase signal — it fires on every return to the app. The launch
foreground no longer rescans (the backfill is already running for it), later foregrounds are
limited to one sweep a minute, and a request inside that window is delayed rather than
dropped. Sweeps can no longer overlap.
The device model is reported (iPhone11,2) alongside the OS version. Raw, never a friendly
name — a lookup table inside an SDK goes stale every September.
setUserId reaches the dashboard instead of a variable nothing read. Pass your own user id
after sign-in and find that install by searching for it; pass nil on sign-out.

Open source →

2.0.013 Aug 2026

The C# still called AsalyzeTrackPurchase, whose ObjC bridge symbol was removed in this release, so the package would have failed to link. Both are gon

The C# still called AsalyzeTrackPurchase, whose ObjC bridge symbol was removed in
this release, so the package would have failed to link. Both are gone now, which
means a project still calling it fails to BUILD rather than silently sending data
that cannot be deduped.

Asalyze-2.0.0.unitypackage is rebuilt from the same GUIDs as 1.3.1, so importing
it upgrades the existing assets in place instead of duplicating every script.

TrackAdRevenue, TrackEvent, SetUserId and InstallId are unchanged.

Open source →

Additional notes

Breaking: Asalyze.trackPurchase is removed (Swift, Dart and the Objective-C/Unity bridge).

Purchases are never reported by hand. The SDK requires iOS 15, so StoreKit 2 observation always runs and every App Store purchase already arrives with Apple's own transaction id, price, currency, offer type and dates — the authoritative values. A manual call could only ever disagree with them, and did:

no transaction id, so nothing downstream could dedupe the manual copy against Apple's;
offer defaulted to .none, so a free trial reported this way booked at full price.

In production one app reported roughly double its real revenue, with 52 free trials counted as paid purchases. Removing the method removes the whole class of error.

Also breaking: offer is now required on trackSubscription (and on SubscriptionEvent.init).

It defaulted to .none, which is the same trap: forget the argument and a free trial is recorded as a paid purchase. .none is still correct for events where no offer applies — expiry, cancellation — it simply has to be stated rather than assumed. The Flutter channel now rejects an unrecognised offer instead of quietly falling back to .none.

Migrating: delete your trackPurchase calls — nothing is lost, the SDK already has those purchases with better data than the call supplied — and pass offer: explicitly to trackSubscription. trackAdRevenue and trackEvent are unchanged; ad revenue genuinely does need reporting, since Apple knows nothing about it.

Open source →