Running iOS notifications in Github Action is not possible

[alexandercerutti]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Misc

Discussion Details

Hello,
since the release of Xcode 14 two years ago, iOS Simulators started supporting iOS notifications through the usage of APNs (so, network and not only .apns file pushing).

The changelog cites the following:

Simulator now supports remote notifications in iOS 16 when running in macOS 13 on Mac computers with Apple silicon or T2 processors. Simulator supports the Apple Push Notification Service Sandbox environment. Your server can send a remote notification to your app running in that simulator by connecting to the APNS Sandbox (api.sandbox.push.apple.com). Each simulator generates registration tokens unique to the combination of that simulator and the Mac hardware it’s running on.

I setup an e2e test made of several components:

• Test with expectations / assertions (Node.JS)
• iOS App (built for APNS sandbox environment)
• iOS UITests
• Server that is used by both NodeJS and iOS app.

The test builds and runs the iOS app and automates some things (notifications permission requires tapping consent - so UITests are great to automate this), then checks if the notification is arrived by watching the springboard.

It runs perfectly on my Macbook Pro M1 2021 (also with a GH self-hosted runner, ofc). With the same configuration I tried moving it to a Github Action in order to allow running on triggers.

I tried both the images macos-15 (Intel - on which it will never work) and macos-15-xlarge (arm64 M2 Apple silicon machines), which both bring Xcode 16, but no notification is sent.

Debugging is very hard in this sense, as the simulator doesn't allow any custom log to get printed (xcodebuild clones your simulator and doesn't print anything - you cannot even read them later).

I created some logs network requests to be printed by the server in order to understand which was the point the whole test was getting stuck on.

Apparently, notification popup appears and it gets tapped, so the permission is given.
However, the device token is not generated and, therefore, neither the AppDelegate function didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError gets called.

This makes me think the machines lack of some permissions, the hardware is not enough, or it fails at doing some requests to APNS (I guess it could be the most plausible reason, as I think the simulator should register and then APS should be able to communicate with it).

I tried to run an action on macos-15-xlarge with nrukavkov/open-ports-check-action@v1 to check for ports 443, 5223 and 80 for api.sandbox.push.apple.com and only 443 is reachable (which seems fine?).

However, this Apple Support page states how 5223 is needed (but I'm not sure it is for api.sandbox.push.apple.com, mostly not).

Do someone knows anything more about this and do you have any ideas how can I test and understand further about this?

Thank you!

[zyfoxx]

Hi, I've run into similar issues with APNs device token registration on GitHub Actions macOS runners (especially ARM/M2).

From my experience, here are a few things to check:

Simulator Limitations in CI

• On GitHub-hosted runners, iOS simulators sometimes can't generate a device token due to hardware or entitlement restrictions. This works fine on physical Macs or self-hosted runners, but cloud environments often lack certain permissions.
• Even if notification permissions appear and are accepted, the callbacks (didRegisterForRemoteNotificationsWithDeviceToken and didFailToRegisterForRemoteNotificationsWithError) might never fire.

Network Ports

• Port 443 is usually enough for APNs Sandbox on simulators. Port 5223 is more relevant for physical devices. As long as port 443 is open to api.sandbox.push.apple.com, networking shouldn't be the main issue.

Troubleshooting Tips

• Make sure your app's entitlements and provisioning profiles are correct.
• Try logging all possible errors and outputs in your AppDelegate for better visibility.
• If possible, use a self-hosted Mac runner (M1/M2) for E2E APNs testing—this usually solves the issue.

Summary

This is a common limitation of cloud CI runners for iOS APNs testing. For full E2E push notification tests, a physical or self-hosted Mac is often required.

Hope this helps!

[alexandercerutti]

Do you think this virtual environment can be simulated somehow? Do you know if it uses something like Apple Container or some in-house solution? I'd love to understand more.

About the port, I'm not exactly sure how we can double check for networking. I mean, we can test for ports with sockets, but what else?

[zyfoxx]

Do you think this virtual environment can be simulated somehow? Do you know if it uses something like Apple Container or some in-house solution? I'd love to understand more.

GitHub isn't transparent about whether macos-15-xlarge uses Apple Containers, Parallels, or a custom solution. According to the Xcode 14 Release Notes, the iOS simulator requires Apple Silicon/T2 and a connection to api.sandbox.push.apple.com for the APN Sandbox. The GitHub VM likely uses macOS virtualization with strict sandboxing, which prevents the simulator from accessing low-level APNs, such as retrieving device tokens. Local simulation will be difficult without knowing the details of their VM—try setting up a macOS VM in Parallels with strict sandboxing to experiment, but this will require trial and error. Alternatively, contact GitHub support or check the GitHub Community Forum for more information. If you have the budget, testing on a self-hosted runner using MacStadium or a physical Mac will likely be more straightforward.

About the port, I'm not exactly sure how we can double check for networking. I mean, we can test for ports with sockets, but what else?

To check the network, add a step in GitHub Actions using curl -v https://api.sandbox.push.apple.com or nc -zv api.sandbox.push.apple.com 443 to ensure a connection to the APN Sandbox (port 443 is sufficient for the simulator, according to Apple's documentation). You can also try traceroute api.sandbox.push.apple.com to see if there are any bottlenecks, although CI may limit access. Add logging on the APN server to check whether the token registration request arrives. If there are no logs, it's likely the simulator isn't attempting registration due to a VM limitation, not a network limitation.

Maybe Since UITests clone the simulator and limit logging, you can try running non-UI tests with xcrun simctl to capture AppDelegate output. For example, use xcrun simctl launch <device-udid> <app-bundle-id> to run the app, then check logs with xcrun simctl spawn <device-udid> log stream --level debug. This can help see if APN callbacks like didRegisterForRemoteNotificationsWithDeviceTokenare firing.

[alexandercerutti]

Alternatively, contact GitHub support or check the GitHub Community Forum for more information. If you have the budget, testing on a self-hosted runner using MacStadium or a physical Mac will likely be more straightforward.

I might think of contacting them. I have Github Pro for what otherwise? :P
I was also thinking of using MacStadium or whatever, but I honestly refuse to have a monthly expense of around 110$ (minimum) for a machine I might want to use only from time to time. Perhaps Amazon Codebuild, but I'm think it might be the same.

To check the network, add a step in GitHub Actions using curl -v https://api.sandbox.push.apple.com or nc -zv api.sandbox.push.apple.com 443 to ensure a connection to the APN Sandbox (port 443 is sufficient for the simulator, according to Apple's documentation). You can also try traceroute api.sandbox.push.apple.com to see if there are any bottlenecks, although CI may limit access. Add logging on the APN server to check whether the token registration request arrives. If there are no logs, it's likely the simulator isn't attempting registration due to a VM limitation, not a network limitation.

You are right, I could try to traceroute. 443 should be available tho, as per the test I made.

What do you mean by Add logging on the APN server? The iOS application should - in my case - receive the token and then send it to the local server I spawn. This thing doesn't happen on GH Action, so the server is not even able to try sending the notification or check registration.

Maybe Since UITests clone the simulator and limit logging, you can try running non-UI tests with xcrun simctl to capture AppDelegate output. For example, use xcrun simctl launch <device-udid> <app-bundle-id> to run the app, then check logs with xcrun simctl spawn log stream --level debug. This can help see if APN callbacks like didRegisterForRemoteNotificationsWithDeviceToken are firing.

I'm already sure didRegisterForRemoteNotificationsWithDeviceToken is not firing because I have a network request to the local server (which logs requests) I spawn that would get sent if that method is called. It gets called on my machine.

Not exactly sure how to run non-UI tests, especially on GH Action. Especially because without UITests nor a UI at all, I cannot see the simulator, interact with it at all – which means that I cannot accept the permission to send notifications, so it would be the same.

Spawning the log stream for the UITests cloned simulator fails, ofc.

[zyfoxx]

What do you mean by Add logging on the APN server?

Add logging on APN server means adding logging to the backend server that receives tokens from the application. This allows you to determine whether your server actually receives token requests from the application.

If the server never receives a request (no logs at all), it indicates that the token registration process in the simulator/CI failed or was not executed. This is common in VM environments like GitHub Actions, as simulators in CI/CD typically cannot fully register with APNs (not due to network issues, but due to VM/simulator limitations).

This thing doesn't happen on GH Action, so the server is not even able to try sending the notification or check registration.

Okay now the problem is indeed with GitHub Actions, most likely due to VM/hardware identity limitations.

Maybe you can try it on a self-hosted runner (Not a VM/cloud).

i hope this helps :)

[alexandercerutti]

I've contacted Github support in order to understand if I can dig on this even further.

I will update the thread if I'll have something new to share.

Meanwhile, thank you!