feat(workflows): add push subscription functionality by havenbarnes · Pull Request #545 · PostHog/posthog-ios

havenbarnes · 2026-03-31T16:42:17Z

💡 Motivation and Context

This will need to be merged after the posthog PR stack PostHog/posthog#53276 and documentation updates:

We're adding push notification channel to workflows, and SDKs need to send us their device tokens to fulfill the push subscription on our end

💚 How did you test it?

Tested everything end to end locally, hitting APNS sandbox on physical device

Added tests for new logic

📝 Checklist

I reviewed the submitted code.
I added tests to verify the changes.
I updated the docs if needed chore(): add Workflows and SDK documentation around push notifications posthog.com#16177
No breaking change or entry added to the changelog.

If releasing new changes

Ran pnpm changeset to generate a changeset file
Added the release label to the PR

github-actions · 2026-03-31T16:54:11Z

posthog-ios Compliance Report

Date: 2026-04-28 23:05:58 UTC
Duration: 2010ms

⚠️ Some Tests Failed

0/1 tests passed, 1 failed

Feature_Flags Tests

⚠️ 0/1 tests passed, 1 failed

View Details

Test	Status	Duration
Request Payload.Request With Person Properties Device Id	❌	224ms

Failures

request_payload.request_with_person_properties_device_id

404, message='Not Found', url='http://host.docker.internal:8080/get_feature_flag'

…d-push-notifications

ioannisj

A few comments from a first pass

ioannisj · 2026-04-06T06:59:26Z

+        /// Requires `enableSwizzling` to be `true`.
+        ///
+        /// Default: true
+        @objc public var capturePushNotificationSubscriptions: Bool = true


This also silently handles registering push notification token through app delegate swizzling. Should we split these into two different config options?

I also feel we should give users who opt out of this config a manual way to handle this by adding public APIs so they can just forward delegate calls to this SDK (from UNUserNotificationCenterDelegate events and UIApplicationDelegate)

This also silently handles registering push notification token through app delegate swizzling. Should we split these into two different config options?

You know best here - sounds like there should be an explicit / non-swizzled version? I only opted for this as it felt the most frictionless and I noticed there were other swizzling-required SDK features.

I also feel we should give users who opt out of this config a manual way to handle this by adding public APIs so they can just forward delegate calls to this SDK (from UNUserNotificationCenterDelegate events and UIApplicationDelegate)

Certainly a good idea. I can add this on our side

You know best here - sounds like there should be an explicit / non-swizzled version? I only opted for this as it felt the most frictionless and I noticed there were other swizzling-required SDK features.

I would have a non-swizzled path as well and maybe even flip the default to false here. App delegate is the entry point for apps, and if something goes wrong with swizzling here (esp with custom classes) we'd be breaking the whole app. @turnipdabeets wdyt?

Agreed, if we offer this it should be opt-in and maybe 2 separate versions/configs for users who can't swizzle.

i'd lean to make it as automagically as possible but also give a manual API (opt out by default)
thes less users have to do, the more automatic stuff works the better
swizzle is dangerous, but if done right its super useful
session replay and autocapture only works with swizzle and people use it just fine, except a few folks that prefer to disable everything, we should just respect the config if people disable this config or disable swizzle for everything

I'm okay with that. Only reason I pushed back a bit here is that this is not using the regular swizzling path which we know works and used by other integrations, but we now handle and need to worry about optional methods from the concrete delegate class (with swizzleAddingIfNeeded())

yep fair point, so it has to be tested that it does not break, whats the common use cases for swizzling breaking apps?
iOS version? OS (eg ipad vs ios vs macos)? runtime config or something?
figure out and test those use cases
i also think that its quite common to swizzle this code path to make notifications setup automatic, i've seen a few examples on the internet, so i think its common and it should be safe enough, even firebase mentions swizzle a few times which is the main notifications provider for apple if not using APN directly

We had a similar discussion when deeplinks were implemented on UIKit. I'm okay testing this out as true by default, then we can come back and make deeplinks automagic as well since swizzling app delegate will be there

Ok, following this thread and (i think) the consensus i've made two changes:

Set capturePushNotificationSubscriptions: Bool = false to default, will make sure this is called out in my documentation PR

Added a non-swizzling codepath for setting up push subscriptions.

LMK if I misinterpreted or anything else is needed here

github-actions · 2026-04-15T09:59:59Z

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

…d-push-notifications

ioannisj

We recently refactored PostHogIntegration protocol, so probably that's why CI is failing, should be a quick fix. Todo here I think is exposing manual methods for token registration and have token autodetection with swizzling as an opt-in?

marandaneto · 2026-04-22T09:14:12Z

+    /// When a push notification is sent from PostHog, the device token is used to deliver the notification to the correct device.
+    ///
+    /// - Parameter deviceToken: The device token received from the system.
+    @objc public func handlePushNotificationDeviceToken(_ deviceToken: Data) {


is the deviceToken really a Data? Shouldn't it be a String or something? where do people read this from?

Depends where it comes from, if they use the swizzled codepath it will be Data. I'll converge this to string to make it more straightforward

yeah then the swizzling path should do the casting
the public API is gonna be user-friendlier with a String instead

Not sure I completely agree here since the delegate method is called with Data. So simplest api would be people just forward this call to the sdk?

https://firebase.google.com/docs/cloud-messaging/ios/get-started#disable-swizzling
i think it depends on what we are collecting here, APN tokens or fcmToken (firebase cloud messaging)?
i understood that Data was only for the swizzling use case, so its automatic, type does not matter
the manual API should have the type that the provider is using, if that is Data, then Data it should be

https://github.com/firebase/firebase-ios-sdk/blob/90c17718b5126b6d95e24c019f10a9fc6a62c54f/FirebaseMessaging/Sources/FIRMessaging.m#L427-L429 here is Data
the firebase link has fcmToken as String

so we just need to figure out what we need and what is its type and that should be the type in the public API

Ah good point on fcm vs apns tokens. Logic says that we'll need a way to distinguish BE side on this since delivery method will differ? So probably two different public api methods I would say. Swizzling here seems to cover the apns token. For FCM I assume we'll need to stick to manual wiring. Either way, we'd need to know if this is FCM or APNS when delivering the token

AFAIK, the device tokens format should be the same regardless of delivery platform; FCM ultimately delivers via APNS anyway.

We're not bringing in any FCM-related logic into the SDK - all of the platform differences for delivery happen on the backend here

So I don't think we need to care about anything on the SDK side other than delivering this device token

the question was more about the datatype really

…d-push-notifications

github-actions · 2026-05-07T10:19:20Z

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

marandaneto · 2026-05-07T10:36:21Z

@ioannisj @turnipdabeets i think this is done, but just need to test/fix conflicts
i think @havenbarnes already left so should we pick this up? can you check with his former team? also for android btw

feat(workflows): add push subscription functionality

ca3817d

havenbarnes added 9 commits April 2, 2026 12:04

cleanup

91ac799

add swizzled notification engagement event

2389d38

tweak

8f506f6

swizzle the app delegate methods as well

534daf1

tweak

402e88b

tweak

1c9166b

add tests

651bb05

add changeset

53724b3

tweak

f6b561f

havenbarnes added the release label Apr 3, 2026

havenbarnes marked this pull request as ready for review April 3, 2026 21:14

havenbarnes requested a review from a team as a code owner April 3, 2026 21:14

havenbarnes requested a review from a team April 3, 2026 21:14

havenbarnes added 4 commits April 3, 2026 16:31

fix lint errors

007867b

tweak

f9ffc91

fix pbxproj

a5e812c

Merge branch 'main' of https://github.com/PostHog/posthog-ios into ad…

832f81e

…d-push-notifications

ioannisj reviewed Apr 6, 2026

View reviewed changes

add offline persistence

99ea998

github-actions Bot added the stale label Apr 15, 2026

havenbarnes added 2 commits April 21, 2026 11:43

refactor/clean up swizzling

184f570

Merge branch 'main' of https://github.com/PostHog/posthog-ios into ad…

2395bf7

…d-push-notifications

havenbarnes requested a review from ioannisj April 21, 2026 16:46

ioannisj reviewed Apr 22, 2026

View reviewed changes

marandaneto reviewed Apr 22, 2026

View reviewed changes

Comment thread PostHog/PostHogSDK.swift Outdated

marandaneto reviewed Apr 22, 2026

View reviewed changes

Comment thread PostHog/PostHogConfig.swift

ioannisj removed the stale label Apr 22, 2026

havenbarnes added 6 commits April 22, 2026 17:31

address comments

6bcf94c

fix PostHogIntegration conformance

a7de815

tweak

a2c6ca0

cleanup PostHogSDK

d41eeb3

add non-swizzled codepath for setting up push subscriptions

b4b78dd

fix build failure

9b1b043

havenbarnes requested review from ioannisj, marandaneto and turnipdabeets April 23, 2026 19:43

rm unneeded test

6f40997

marandaneto reviewed Apr 25, 2026

View reviewed changes

Comment thread PostHog/PostHogSDK.swift

marandaneto approved these changes Apr 25, 2026

View reviewed changes

havenbarnes added 3 commits April 28, 2026 12:13

Merge branch 'main' of https://github.com/PostHog/posthog-ios into ad…

c589e93

…d-push-notifications

fix tests

1b96974

Merge branch 'main' of https://github.com/PostHog/posthog-ios into ad…

871da7d

…d-push-notifications

ioannisj approved these changes Apr 29, 2026

View reviewed changes

turnipdabeets approved these changes Apr 29, 2026

View reviewed changes

github-actions Bot added the stale label May 7, 2026

Conversation

havenbarnes commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💡 Motivation and Context

💚 How did you test it?

📝 Checklist

If releasing new changes

Uh oh!

github-actions Bot commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

posthog-ios Compliance Report

⚠️ Some Tests Failed

Feature_Flags Tests

Failures

Uh oh!

ioannisj left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Apr 15, 2026

Uh oh!

ioannisj left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marandaneto Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

havenbarnes Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 7, 2026

Uh oh!

marandaneto commented May 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

havenbarnes commented Mar 31, 2026 •

edited

Loading

github-actions Bot commented Mar 31, 2026 •

edited

Loading

marandaneto Apr 23, 2026 •

edited

Loading

havenbarnes Apr 23, 2026 •

edited

Loading