Push notifications are not arriving in your Median (formerly GoNative) iOS app. Here are the most common causes — credentials, permissions, environment mismatches — and how to fix them.
You enabled push notifications in your Median app, but messages are not arriving on iOS. There is no error, no alert, just silence.
Push failures are frustrating precisely because they are silent. iOS does not pop up an error when delivery fails, so you have to work backward through the delivery chain.
The absence of any error message is the hard part. Nothing tells you which link broke, so a systematic approach beats trial and error.
The good news is that the causes are well known and finite. Nearly every failure is a credential, permission, environment, or identifier problem rather than a code bug.
Because the list of likely causes is short, checking each one in order will almost always surface the problem.
On iOS, push flows from your server or provider, to Apple Push Notification service, to the specific device via its token. Every link must be correct.
Median abstracts much of this, but you still supply Apple credentials and the app must register successfully to obtain a token. If any link is broken, nothing arrives.
The links are concrete: permission granted, a valid token obtained, that token stored, correct APNs credentials, the right environment, and a matching bundle identifier. Miss any one and the message silently disappears.
Debugging means checking each link methodically rather than assuming the problem is in your web code.
Holding this mental model makes the rest of the process straightforward, because each cause below maps to one link in the chain.
If the user never granted notification permission, or denied it, iOS will not display your notifications. This is the first thing to check.
On the device, open Settings, find your app, and confirm notifications are allowed. Remember that once a user denies the system prompt, it will not reappear automatically — they must re-enable it in Settings.
During testing this catches people constantly: a denied prompt from an earlier build silently suppresses everything until you toggle it back on.
Make sure your app actually requests permission at a sensible moment and that the request is wired through Median's bridge correctly. No permission means no visible push, full stop.
If you are unsure of a device's permission state, deleting and reinstalling the app resets it, giving you a clean prompt to test against.
Push is tied to a specific App ID. If the bundle identifier in Median does not exactly match the one in your Apple Developer account and the push credential, delivery fails silently.
Compare the identifier across all three places: Median configuration, the Apple Developer portal App ID, and App Store Connect. They must be identical.
Copy and paste rather than retyping, because a single wrong character is enough to break the association without any warning.
Even a small discrepancy, like a stray suffix or wrong casing, breaks the link between the app and its push capability.
This is worth checking early precisely because it is invisible: nothing flags the mismatch, the notification simply never arrives.
Push requires a valid APNs credential — typically an authentication key (.p8) or a push certificate. If it is missing, expired, or belongs to a different team, APNs rejects delivery.
Verify the credential you uploaded to Median is current and correct, and that the Push Notifications capability is enabled on your App ID.
Confirm the credential belongs to the same Apple team as the App ID. A key from a different team will not authorize delivery even if everything else looks right.
Certificates expire; auth keys generally do not but can be revoked. If push worked before and suddenly stopped, an expired certificate is a prime suspect.
Moving to a .p8 auth key removes the recurring expiry problem entirely, which is why it is the recommended modern approach.
This is one of the most common and confusing causes. Development builds register with the APNs sandbox environment, while production App Store and TestFlight builds use the production environment.
A token obtained in one environment will not receive notifications sent through the other. If you test with a development build but send via production, or vice versa, nothing arrives.
TestFlight trips people up because it is a test channel that nonetheless uses the production push environment. Do not assume test builds always mean sandbox.
Make sure your sending configuration matches the build you are testing. When you move from development to a store build, confirm the environment switches accordingly.
When in doubt, note which environment your current build uses and send explicitly to that one, rather than assuming your provider picked correctly.
Even with permission and correct credentials, you need the device token associated with your target user for personalized sends. If the token was never captured or saved, you cannot reach that device.
Confirm your web app reads the token through Median's JavaScript bridge and stores it in your backend tied to the user. Log the registration to verify it fired.
Add temporary logging on both the client and server so you can see the token arrive and get persisted. A token that never reaches your backend is a silent dead end.
For broadcast messages this may be handled by your provider, but for targeted messages a missing token means that device is unreachable.
Also handle token changes: iOS can issue a new token, so update your stored value whenever the app reports one to avoid sending to a stale token.
Go in order. First, confirm notification permission is granted in the device Settings. Second, verify the bundle identifier matches across Median, the developer portal, and App Store Connect.
Third, check the APNs credential is present, current, and tied to the right team, with the Push capability enabled. Fourth, confirm the send environment matches your build — sandbox for development, production for store and TestFlight.
Fifth, verify the device token was obtained and stored. Sixth, always test on a real device, since Simulator push support is limited and version-dependent.
This sequence catches essentially every push failure, because each step corresponds to one link in the delivery chain.
Resist the urge to jump ahead to code. The overwhelming majority of push problems are resolved somewhere in these six configuration checks.
If you have verified all six links and push still fails, gather your evidence and consult Median's documentation and support with specifics: your identifiers, environment, and what you have already checked.
A precise report — the exact bundle identifier, credential type, environment, and the steps you ran — gets you a useful answer far faster than a vague description.
Remember the honest limitation: Median abstracts APNs but cannot bypass Apple's requirements. The credentials, capabilities, and environment rules are Apple's, and they must be exactly right.
Keep a written checklist of your working configuration once it succeeds. Push setups are easy to break during renewals or environment changes, and a documented baseline saves hours next time.
That baseline becomes your fastest recovery tool the next time something breaks, because you can compare the broken state against a known-good one.
Usually one of: notification permission not granted, a bundle identifier mismatch, missing or expired APNs credentials, a sandbox-versus-production environment mismatch, or a device token that was never captured. Check each link in that order.
Development builds use the APNs sandbox and production App Store or TestFlight builds use production APNs. A token from one environment will not receive messages sent through the other, so your send configuration must match the build you are testing.
Simulator push support is limited and version-dependent, so always confirm on a real device. A physical iPhone reliably validates permission, token registration, and delivery across foreground, background, and closed states.
The most common cause is an expired APNs certificate. Authentication keys generally do not expire but can be revoked. Check credential validity and that the Push Notifications capability is still enabled on your App ID.