Implementation coverage
This documentation describes implemented source surfaces, not a speculative target architecture. Availability still depends on adding the corresponding SDK module and configuring its backend feature.
Mobile capability matrix
| Capability | Android | iOS | Flutter |
|---|---|---|---|
| Installation bootstrap/recovery | Native | Native | Native bridge |
| Server-mediated profile binding | Yes | Yes | Yes |
| Installation/profile attributes | Yes | Yes | Yes |
| Tags and subscription lists | Yes | Yes | Yes |
| Durable events and screens | Yes | Yes | Yes |
| Push transport | FCM | APNs | Native bridge |
| Permission prompt | Host app | Host app | Host/platform app |
| Notification display/events | Yes | Yes | Native bridge |
| Rich media | Android module | Service extension | Native setup |
| In-app overlays | DivKit | DivKit | Native Platform View |
| Embedded placements | Compose/View | SwiftUI | Native Platform View |
| Custom actions | Yes | Yes | Yes |
| Preference Center | Ready-made/headless | Ready-made/headless | Ready-made/headless |
| Message Center | Ready-made/embedded/headless | Ready-made/embedded/headless | Ready-made/embedded/headless |
| Feature flags | synchronous local read | local read | async bridge to local read |
| Runtime feature controls | Yes | Yes | Yes |
| Privacy opt-out/wipe | Yes | Yes | Yes |
Product capability coverage
| Area | Implemented surfaces |
|---|---|
| Workspace | account, team, roles/permissions, security, audit, billing |
| Project | environments, shared media, design tokens, reusable components, localization |
| Environment | apps, provider credentials, access keys, usage/quotas, diagnostics, retention |
| Audience | profiles, identities, installations, events, consent, segments, test groups, privacy |
| Messaging | push campaigns, transactional templates, in-app experiences, Message Center |
| Orchestration | event/screen/audience/API entry, waits, conditions, push, in-app, webhooks, profile updates |
| Experimentation | feature flag and experience variants, allocation, conversion tracking |
| Operations | durable outboxes/workers, provider diagnostics, webhooks, exports, scheduled reports |
| Analytics | messaging, in-app, inbox, segments, funnels, automations, experiments, usage |
Deliberate contract boundaries
- Mobile SDKs do not accept a user ID directly; binding is server-mediated.
- SDKs do not request notification permission; the host owns user timing and education.
- App keys are public identifiers; privileged server endpoints require an access key.
- Flutter delegates Engage business behavior to native SDKs rather than reimplementing it with Dart HTTP/storage plugins.
- In-app sync uses HTTPS and local caches, not a persistent application WebSocket/SSE connection.
- iOS Engage push is direct APNs, not FCM-to-APNs.
Source authority
Released SDK tags define public mobile APIs. The backend controllers and mobile OpenAPI contract define HTTP behavior. The console source defines operator workflows. If this page diverges, treat it as a documentation defect.