System Events

Reserved events emitted by the SDK and Nuxie runtime

Nuxie reserves event names that begin with $ for SDK and platform behavior. Your app sends ordinary product events without the prefix, such as signup_completed or export_limit_reached.

Do not emit reserved events directly. Use the corresponding SDK method, authored action, or native system interaction so Nuxie can attach the correct identity, Journey, Version, and idempotency data.

App lifecycle

The iOS SDK emits these automatically when automatic lifecycle tracking is enabled.

Event	Meaning
`$app_installed`	First launch after installation
`$app_updated`	First launch after the app version changes
`$app_opened`	App enters the foreground
`$app_backgrounded`	App enters the background

Every event also receives SDK context such as app version, device, locale, and $session_id when available.

Identity

$identify records an identity change or user-property update. Call the public API instead of tracking the event yourself:

NuxieSDK.shared.identify(
    "user-456",
    userProperties: ["email": "user@example.com"],
    userPropertiesSetOnce: ["signup_source": "organic"]
)

When an anonymous user becomes known, the SDK includes the previous anonymous identity and serializes the transition across its event, purchase, and Journey state.

The SDK sends two state-changing Journey reports. The server stores the authoritative Journey record and advances its cursor from these reports; it does not derive lifecycle state from analytics events. These reports are runtime protocol and cannot be selected as authored triggers or goals.

Event	Meaning
`$journey_leg_started`	A locally assigned Journey section starts; for a new binding this also creates the Journey
`$journey_leg_completed`	A locally assigned Journey section ends and reports its outcome and declared outputs
`$journey_milestone`	An authored milestone is recorded in the ordinary event stream

Leg reports carry identifiers and ordering fields such as journey_id, leg_id, and leg_generation. Treat them as runtime records, not as a public command API. Conversion and terminal status live on the server-owned Journey record rather than in derived lifecycle events.

Experience presentation

Event	Meaning
`$experience_shown`	An Experience becomes visible
`$experience_dismissed`	The user dismisses it
`$experience_errored`	Presentation fails
`$experience_artifact_load_succeeded`	The signed Version artifact is ready
`$experience_artifact_load_failed`	The Version artifact cannot be loaded or admitted
`$screen_shown`	A screen becomes active
`$screen_dismissed`	A screen is dismissed

Presentation events include the relevant Experience, Version, screen, and Journey identifiers when applicable. Purchase outcomes use the commerce events below. A timeout or host close is represented by dismissal reason and the Journey’s authored completion outcome. $experiment_exposure records actual visibility of a selected variant; assignment alone is not an exposure.

Commerce and Feature use

Event	Meaning
`$purchase_completed`	StoreKit reports a successful purchase
`$purchase_failed`	A purchase attempt fails
`$purchase_cancelled`	The customer cancels the purchase sheet
`$purchase_pending`	StoreKit reports a pending purchase
`$purchase_synced`	Verified transaction evidence commits to Nuxie
`$restore_completed`	Restore completes with purchases
`$restore_failed`	Restore fails
`$restore_no_purchases`	Restore completes without purchases
`$feature_used`	Authoritative metered Feature use commits

Use purchase, restore, useFeature, or useFeatureAndWait rather than sending these names. A local purchase completion and a server-confirmed purchase sync are distinct events.

Permissions and responses

The runtime also emits reserved outcomes for authored system prompts and response collection:

$notifications_enabled and $notifications_denied
$permission_granted and $permission_denied
$tracking_authorized and $tracking_denied
$response_set and $response_unset

Response events are runtime controls tied to a published response schema. Use screen response actions; do not send them as analytics events from application code.

Use system events in Nuxie

System events can be used in analytics, Segment conditions, and supported Journey conditions. For example, a Segment can select users with at least one $app_opened event in the last seven days.

The event catalog hides most reserved events by default to keep product-event discovery focused. $identify and $feature_used remain visible because they support user properties and Feature usage.