// Case study / SDK debugging
A silent iOS data-loss bug, traced to the initialisation sequence.
I flagged and proved a systematic iOS undercount of
Application Opened events versus Android, then used AI
assistance to review the SDK code path and locate the runtime behaviour
causing silent cold-launch event loss.
What happened
A cross-platform count gap became an SDK initialisation finding.
A major QSR had a systematic iOS undercount of
Application Opened events versus Android. The bug was
silent: no visible errors, no obvious dropped-event logs, only a stable
undercount. I traced the issue to the app's initialisation sequence and
Segment analytics-swift 1.9.1:
process(incomingEvent:) returns immediately when
enabled == false, so cold-launch events fired before remote
config re-enabled the SDK were dropped rather than queued.
The same engagement surfaced broader cross-platform tracking-plan parity gaps and a GTM container governance issue where two international locales were feeding the main analytics container.
Context
The dashboards showed a gap. The instrumentation did not explain it.
Mobile analytics showed a stable difference between iOS and Android
Application Opened counts. Downstream funnel reading was
being skewed, but there was no explicit error pointing to the source of
the loss.
Risk
The undercount looked like real user behaviour.
Because the loss was silent, stakeholders could read the difference as platform behaviour rather than measurement failure. That made root-cause discipline essential: read the app startup sequence and the SDK source path actually running in production.
Method
AI helped hunt the code path after the evidence was already visible.
I first identified the cross-platform count gap and gathered proof that the issue was not a dashboard mismatch. Then I used AI assistance to inspect the Segment analytics-swift source path, compare candidate failure modes, and narrow where the cold-launch event loss lived.
StartupDisabled gate
rawSegment.enabled = false at startup while remote
config is unresolved.
EventCold launch
Application Opened fires before remote config flips the
SDK back on.
SDKDrop path
process(incomingEvent:) returns immediately when
enabled == false.
Systematic iOS undercount of Application Opened versus
Android surfaced in mobile analytics.
Initialisation sequence showed
rawSegment.enabled = false at startup, re-enabled only
after remote config completed.
Segment analytics-swift 1.9.1 returned immediately when disabled, dropping cold-launch events instead of queueing them.
Broader review surfaced tracking-plan parity gaps and two international locales feeding the main GTM analytics container.
Action
The fix path required reading what actually shipped.
I traced the undercount through runtime behaviour rather than treating
it as a reporting discrepancy. I first flagged the iOS-versus-Android
gap and gathered proof that Application Opened was being
undercounted. Then I used AI assistance to review the version-pinned SDK
source path, map it against the app startup sequence, and identify why
cold-launch events were dropped silently.
Outcome
The drop path was pinned to a specific SDK gate.
- Silent iOS undercount traced to cold-launch event loss.
- Segment analytics-swift 1.9.1 initialisation behaviour identified as the drop path.
- Cross-platform tracking-plan parity gaps surfaced in the same engagement.
- Two international locales found feeding the main analytics GTM container.
Design lesson
Parity is a runtime property.
It is not enough for iOS and Android to share the same tracking plan on paper. If one SDK drops cold-launch events before remote config resolves, the platforms are not equivalent in production, no matter how clean the documentation looks.