iOS SDK

The Monita iOS SDK observes the vendor network calls your app already makes, matches them against your property’s vendor configuration, and streams them to the same dashboards, detectors and alerts as your web traffic. Monitoring is passive: the SDK never blocks, mutates, delays or re-issues a request, so your app’s networking behaves exactly as if the SDK were not there.

Version 2.0 monitors any vendor you configure on the property, the same catalog as web monitoring: Firebase, Meta, Google Ads, Adobe, AppsFlyer, Adjust, Branch, Amplitude, Mixpanel, Segment, Braze and any custom vendor whose request URL you know.

Before you start

Create a property with source type Mobile app (or reuse an existing property if you want web and app traffic together), configure your vendors, and copy the SDK token from Manage → Installation guide. See the Monita-side setup for vendor configuration.

Requirements: iOS 14 or later, Swift 5.9 or later. The SDK has no third-party dependencies.

In Xcode, choose File → Add Package Dependencies and enter:

https://github.com/rnadigital/monita-ios-sdk

Or add it to your Package.swift:

dependencies: [
    .package(url: "https://github.com/rnadigital/monita-ios-sdk", from: "2.0.0")
]

Add the pod to your Podfile and run pod install:

pod 'MonitaSDK', '~> 2.0'

Initialize

Call configure as early as possible, ideally in application(_:didFinishLaunchingWithOptions:) or your SwiftUI App initializer, so launch-time vendor traffic (such as a Firebase first flush) is observed:

import MonitaSDK

Monita.configure(token: "dom_xxxxxxxxxxxxxxxxxxxxxxxx")

Or with options:

Monita.configure(MonitaConfiguration(token: "...", collectEndpoint: nil, configEndpoint: nil, debugLogging: false))

Prefer keeping the token out of code? Add it to Info.plist and call the zero-argument form:

<key>MonitaSDKToken</key>
<string>dom_xxxxxxxxxxxxxxxxxxxxxxxx</string>

Monita.configure()

The token identifies the property only. It is a public identifier, not a secret.

What gets monitored

Once configured, the SDK observes URLSession requests made in process, which covers your own networking and most vendor SDKs. When a request URL matches a configured vendor pattern, the SDK snapshots the URL, method, query parameters and request body, extracts the event name using your property’s event mapping, applies your filters, strips your excluded parameters, and queues the event for delivery.

Vendor changes apply remotely. Adding, editing or removing vendors on the property takes effect on devices at the next configuration refresh, with no app release.
Delivery is store and forward. Events are batched, persisted on the device and uploaded once the network is reachable, so offline sessions arrive after the next launch with connectivity.
Batches carry the app version. Every batch includes av, your app’s CFBundleShortVersionString plus CFBundleVersion, so events from different builds stay distinguishable while you debug a rollout.
Manual events. With manual monitoring enabled on the property, Monita.send(vendor:event:data:) reports events the SDK cannot observe on the network, such as activity inside a web view.

Use Monita.setCustomerId(_:), Monita.setSessionId(_:) and Monita.setScreen(_:) to join app events with your web and server-side traffic and to attribute events to screens.

The SDK does not collect consent itself. It reports the consent state your CMP already manages, so monitored traffic carries the same consent context as your tags and feeds consent posture.

By default the SDK reads the IAB standard strings that CMP SDKs write to UserDefaults, in this priority order:

IABTCF_TCString (TCF v2)
IABGPP_HDR_GppString (GPP)
IABUSPrivacy_String (US Privacy)

The value is re-read for every upload, so CMP updates propagate without any wiring. To override auto-detection, call Monita.setConsent(_:) with an explicit string, or Monita.setConsentProvider(_:) for a dynamic source.

The SDK keeps monitoring regardless of consent state by default, matching the web script, because tag monitoring is typically run as a compliance measurement function. If your policy requires gating on consent, wire your CMP decision into the event filter:

Monita.setEventFilter { _ in
    MyCMP.shared.hasAnalyticsConsent
}

Returning false drops the event before it is queued or sent.

The SDK also reports your app’s App Tracking Transparency authorization status as part of a periodic environment diagnostic, alongside the vendor and CMP SDKs it detects in the app. This is status only; the SDK never reads the IDFA or any advertising identifier.

Configuration options

MonitaConfiguration accepts full-URL overrides for customers who route traffic through their own hosts, such as a reverse proxy:

Option	Default	Description
`collectEndpoint`	`https://collect.monita.ai/api/v1`	Where captured events are delivered.
`configEndpoint`	Derived from the token	Where the property’s vendor configuration is fetched from.
`debugLogging`	`false`	Verbose logging and unbatched delivery.

Leave both endpoints nil to use the Monita production hosts.

Verify

Open Monitor → Realtime in the app, select the property and press Live. Fire a monitored vendor event (for example a Firebase log event) in your app: the payloads arrive within seconds, so you can confirm capture, event names and parameters as you tap through screens. Once a bundle id is set on the property, your app’s icon appears alongside its events. See the Realtime view for everything the stream shows.
Prefer logs? Enable debug logging during rollout:
```
Monita.setDebugLogging(true)
```
Watch the Xcode console: you should see the configuration load, each capture decision, and uploads returning 204. Debug mode also ships every event immediately in its own POST, so nothing waits on batching. Disable it for release.

Coverage and limitations

Traffic	Covered
`URLSession` requests made in process (app code and most vendor SDKs, including Firebase, Meta, AppsFlyer, Adjust, Branch)	Yes
Request URL, method, query parameters, and JSON, form-encoded or key-value bodies up to 64KB	Yes
Response status codes (tag success or failure)	Yes
`WKWebView` traffic	No
Background `URLSession` transfers	No
Raw sockets and custom network stacks that bypass `URLSession`	No
Response bodies	Never read, by design
Bodies over 64KB, streamed bodies, and binary or protobuf bodies	URL parameters only

Captured parameters are capped at 100 per event and pass your property’s exclusion rules before leaving the device. The SDK generates its own visitor and session identifiers; it never reads the IDFA, fingerprints the device, or harvests cookies or credentials.

Troubleshooting

No events arrive. Check the token, then enable Monita.setDebugLogging(true) and watch the console. If the configuration never loads, the property may be paused or removed, or the config endpoint is unreachable from the device.

A vendor call is not captured. Confirm the vendor is enabled for your property and its URL pattern appears in the request URL. Check the coverage table above: WKWebView and background session traffic are not observed.

Events are captured but arrive late. Delivery is store and forward, so offline sessions arrive after the next launch with connectivity. Monita.flush() forces an immediate attempt.

The first launch reports nothing. On the very first launch there is no cached configuration yet, so monitoring starts once the first configuration fetch completes. Requests seen shortly before that are buffered and evaluated retroactively; on later launches the cached configuration applies from the first request.

Debug logging shows “circuit breaker tripped”. The SDK captured an unusually high volume of events in a short window and turned itself off for the rest of the process as a safety valve. This usually means a vendor URL pattern is far too broad.

If you are stuck, walk through Deployment troubleshooting or contact support.