GitHub release
Integration guide
Upgrade guide

Changelog:

  • Minimum iOS version is now 9.0
  • Removed all external dependencies
  • Using WKWebView to display HTML in-app messages instead of deprecated UIWebView.
  • Some methods were renamed. See the upgrade guide for more
  • setRequiresUserConsent()/setUserConsent() to freeze the WonderPush SDK until user provides consent, if you opt for this strict mode
  • GDPR methods to download and clear data.
  • Removed collection of some device capabilities that were not useful

Howdy v3! What happened to v2?

We have dropped the leading 1. in the version number. It was meant to identify the version of the API the SDK was build to work against, but in practice it only made the numbering longer and made less obvious that we follow semantic versioning.
Version 1.2.x.y was the v2 of the SDK, in semantic versioning lingo, while version 1.1.x.y was v1.
Cocoapods already imposed us to use a 3-groups version so we were already using 2.x.y there.

What are the breaking changes?

We've dropped support for iOS 8, which amounts for around 0.1% of active iOS versions. Note that all iOS 8 devices were eligible for iOS 9.
We've also renamed some functions while providing a clear and easy upgrade path instead of bluntly breaking things and calling it a v3.

Refer to the upgrade guide for more information.

GitHub release
Integration guide
Upgrade guide

Changelog:

  • Migrated to Firebase, dropped GCM
  • Completely overhauled integration, with automatic initialization, Firebase integration reuse
  • No need for WonderPushInitializerImpl anymore, thanks to the automatic initialization. This means less code! See the integration guide for more
  • Some methods were renamed. See the upgrade guide for more
  • setRequiresUserConsent()/setUserConsent() to freeze the WonderPush SDK until user provides consent, if you opt for this strict mode
  • GDPR methods to download and clear data.
  • Collect Advertising ID only if dependency is linked to the project
  • Removed collection of some device capabilities that were not useful

Howdy v3! What happened to v2?

We have dropped the leading 1. in the version number. It was meant to identify the version of the API the SDK was build to work against, but in practice it only made the numbering longer and made less obvious that we follow semantic versioning.
Version 1.2.x.y was the v2 of the SDK, in semantic versioning lingo, while version 1.1.x.y was v1.

What are the breaking changes?

Migrating to Firebase made us drop classes that were no longer used, and we took the opportunity to remove some things while we were bumping to v3.
That said, we've deprecated some functions and changed the integration while providing a clear and easy upgrade path instead of bluntly breaking things and calling it a v3.

Refer to the upgrade guide for more information.

GitHub release
Integration guide

Changelog:

  • Fix SDK initialization on some Honor and Huawei devices that block external Service call used by OpenUDID.
    We got rid of OpenUDID, using an app-local UUIDv4 instead to be totally user privacy-friendly, including starting from a fresh state on application reinstallation.
  • Read AdvertisingId, unless ad tracking is limited, to help multi-project owners perform cross-project analysis and segmentation.

We have release the ability to segment on custom properties of an event.

You could previously segment on the event type and restrict on its age, and segment on user and installation custom properties, but segmenting on an event custom properties was not possible… until today!

In the segmentation form you will notice a new Event category with the known User event criterion you already know along with 5 new Event custom field entries:
image|251x300

The criterion in itself is pretty simple; it's a mix of User event and the custom field segmentation you already know:
image|690x89

As an example use case, one of our customer is using this brand new criterion to exclude users that have already read the article that they are going to notify their audience about, so they won't bug them uselessly and keep a smooth user experience.

We can't wait to see what you'll build with this new tool!

We have released the ability to control notification collapsing on iOS, completing the feature already available on Android and the Web.

By default, notifications sent inside a given campaign will update one-another, in order to avoid stacking up in the user's device.
We've been proposing the ability to manually control collapsing on Android and Web since a long time, but our implementation was lacking support for iOS… until today!

In the Management API, in the notification parameter of the POST /v1/deliveries call – parameter whose format reference is available here – accepted an alert.android.tag and alert.web.tag field. It now accepts an alert.ios.tag fields to complete the set, as well as the global alert.tag field to rule them all.

We will be exposing this feature from the dashboard soon.

A good use case is to assign a unique tag to a unique topic you might send multiple notifications updates about, like the live score of an ongoing match, or live updates about a breaking news.

We can’t wait to see what you’ll build with this new tool!