Announcement: The PushEngage iOS SDK 1.0 Is Here

The PushEngage iOS SDK 1.0 is here. If you run a mobile app alongside your website, you can now bring the full PushEngage retention stack — triggered campaigns, audience segmentation, goal tracking, and revenue attribution — to your users’ lock screens with a native Swift SDK that installs in an afternoon.

This is our biggest iOS release since we launched mobile app push in 2023. Version 1.0 is a ground-up overhaul of the SDK’s architecture, a major expansion of what your app can tell PushEngage about your subscribers, and a production-hardening pass that added a full automated test suite. Here’s what’s inside.

What’s new in the iOS SDK 1.0

A cleaner two-module architecture

The SDK is now split into two modules. PushEngage is everything your app target needs: permission handling, subscription management, campaigns, and analytics. PushEngageExtension is a lean module for your Notification Service and Content Extension targets — the pieces that render rich media and track delivery. Your extension targets no longer pull in the entire SDK, and shared state (subscriber identity, configuration, logging) flows between the app and its extensions through an App Group container.

Subscriber identity with identify and logout

You can now attach up to 12 predefined subscriber fields — name, email, phone, profile ID, location, and more — to the device subscription with a single identify call. When a user signs out, logout clears the personal fields and keeps the anonymous subscription intact. Repeat calls with unchanged data resolve locally without a network round-trip, so you can call identify safely on every launch.

Custom event tracking with trackEvent

The new trackEvent API sends custom analytics events — an add-to-cart, a completed level, a viewed product — straight from your app to PushEngage, with typed properties and optional subscriber attribution. Combined with triggered campaigns, any in-app behavior can now start a notification journey without an engineering ticket for each new campaign.

Ready for React Native and Flutter teams

Version 1.0 adds first-class wrapper identification, the groundwork for the next generation of our Flutter and React Native SDKs. Cross-platform teams get the same native delivery path as Swift teams, and the PushEngage dashboard knows exactly which stack each subscriber came from.

Built for production

• iOS 12+, Xcode 15+, Swift 5.9 — with full Objective-C support and complete example apps in both languages
• Swift Package Manager and CocoaPods — source-only distribution, no prebuilt binaries to vendor
• A full automated test suite — roughly sixty new test files covering networking, notification lifecycle, subscriber state, and payload parsing
• MIT licensed and open on GitHub — read every line before you ship it

Getting started takes four lines

Add the package from GitHub, link PushEngage to your app target, and initialize in your AppDelegate:

import PushEngage

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    PushEngage.setAppID(id: "YOUR_APP_ID")
    PushEngage.setInitialInfo(for: application, with: launchOptions)
    return true
}

// Wherever onboarding makes sense:
PushEngage.requestNotificationPermission { granted, error in
    if granted { print("Subscribed") }
}

From there, every campaign type in your PushEngage dashboard — drip series, cart recovery, price drop alerts, A/B tests — works for app subscribers the same way it works for web push. Your marketing team runs campaigns from the dashboard. Your engineers never see another “can you send a push” ticket.

Upgrading from 0.1.x

App-target code is unchanged. Your notification extension targets need three small changes:

1. Dependency — extension targets now use the PushEngageExtension pod or SPM product instead of PushEngage
2. Import — import PushEngage becomes import PushEngageExtension in extension code
3. Call sites — the class prefix changes from PushEngage to PushEngageExtension; method names stay the same

CocoaPods upgraders should run pod deintegrate && pod install once so the old single-module framework is fully cleared from the build cache. The full migration guide lives in the GitHub README.

Why this matters for retention

An app install is the strongest opt-in signal a customer can give you, and the lock screen is the highest-attention surface they own. Most brands with an app are sitting on that asset without using it — the install base grows while the notification strategy stays parked at “we should get to that.” The 1.0 SDK removes the engineering excuse: integration is an afternoon, campaigns are dashboard-driven, and pricing scales only with active subscribers, so a large dormant install base costs you nothing.

If you’re evaluating the move from a delivery-only setup, our PushEngage vs Firebase Cloud Messaging comparison covers what the marketing layer adds on top of raw delivery. And if you want the strategic picture first, start with our app push marketing guide.

Get started today

The SDK is live on GitHub, CocoaPods, and Swift Package Manager. The step-by-step setup guide walks through certificates, App Groups, and your first campaign. Every paid plan is backed by our 14-day money-back guarantee — and if you’re already a PushEngage customer, app push is waiting in your dashboard right now.