Push works on test devices but users say they don't receive it: check code or phone settings first?

Bottom line first: push works on test devices but users say they don't receive it. Usually, it is not that the developer 'did not write push', but that a link in the chain is broken—the user turned off notification permission, the device token is invalid, the Android OEM channel is not configured, the iOS certificate environment is wrong, or the system power-saving policy freezes the process. Based on 2026 project delivery habits, checking the four stages 'permissions → token → channel → content' first saves more time than repeatedly changing code. Suitable for apps with time-sensitive touchpoints such as orders and customer service; pure internal tools do not need to force it.

Which layers does a push notification pass through from server to phone screen?

Push is not the app polling for messages on a timer; the server hands the message to a system-level push service, which then wakes the app or displays the notification directly. iOS mainly uses APNs. Android, because of OEM-customized systems, usually needs separate integration with Huawei, Xiaomi, OPPO, vivo, and other OEM channels, or uses a third-party aggregation push service as a unified interface. 'Not receiving' can happen at any of the four layers: server, channel, system, or app.

Many clients think push is just one API, but it is actually cross-end collaboration: the client handles permission and token reporting, the server routes by platform, and operations maintains certificates and keys. A common practice in 2026 is that the client only manages tokens, the server schedules uniformly, and the channel layer provides fallback. Miss one link, and a test device in the background may fail silently, while the log often only shows 'sent successfully'.

• iOS: Delivery via APNs; development and production certificates and keys must not be mixed. After mixing, some devices may receive intermittently.
• Android: OEM channels differ greatly. If the corresponding channel is not integrated, the app usually cannot receive notifications after being killed.
• Third-party aggregation: Integrates multiple channels at once, but you still need to configure each OEM account, package name, and signature.
• Online and offline: Online can use a long connection; offline relies on system channels. System channels have time and frequency limits.

User settings, device token, OEM channel, server: how do you tell whose problem it is?

To determine responsibility, do not argue first; use elimination. First, check whether the user turned off notification permission. Second, check whether the device token is valid. Third, check the OEM channel and certificate. Fourth, check the server send records. Based on project experience, users turning it off themselves and invalid tokens account for a significant share; these two cannot be solved by changing code, only by guiding users to enable notifications or re-reporting the token.

• User side: Notification permission off, Focus mode, or Low Power mode can prevent or delay notifications.
• Device side: Invalid token, or not updated after reinstall or device change, while the server still sends to the old token.
• Channel side: OEM channel not enabled, package name/signature mismatch, expired certificate.
• Server side: Send frequency exceeded, message body format error, or no platform-based routing.

If Android cannot receive in the background but works in the foreground, suspect the OEM channel and power-saving policy first. If iOS receives intermittently, suspect mixed certificate environments or an unupdated token first. If all devices cannot receive, first check whether the server actually called the send API.

Four-stage chain check: checking in order is faster than random changes

Break troubleshooting into 'permission stage, token stage, channel stage, and content stage', because if the previous stage fails, changing code later is meaningless. Each stage needs verifiable criteria; do not just look at a log that says 'sent'.

1. Permission stage: Confirm system notification permission, in-app switch, and channel switch. The pass criterion is that a manually sent test notification is visible in the notification shade.
2. Token stage: Confirm token reporting, updating, and storage across devices. The pass criterion is that after reinstall or device change, the server can get the new token and replace the old one.
3. Channel stage: For Android, verify the OEM channel, package name/signature, and channel ID; for iOS, verify the APNs production environment. The pass criterion is that a real device can receive in the background or when the process is killed.
4. Content stage: Check title, body, deep-link parameters, silent format, and frequency limits. The pass criterion is that tapping the notification opens the correct page without crashing or losing parameters.

Delivery-site experience: for an order-based app project, the constraints were a tight budget, only two weeks left before launch, and Android OEM accounts not all enabled. The approach was to first lock the signature and package name, then apply for channels, while having the server clean up invalid tokens. The result was one less round of rework in integration testing, at the cost of spending about 1 to 2 extra days on confirmation upfront. The typical range for OEM channel review waiting is 1 to 3 weeks; if you wait until integration testing to apply, it can easily delay launch.

Self-built push vs. third-party aggregation: how do cost and timeline compare?

Self-built push integrates directly with APNs and each OEM channel, giving strong control, but it requires maintaining multiple SDKs, certificates, and keys. Third-party aggregation provides a unified API for one-time integration, removing the need to integrate each vendor individually, and is suitable for small and medium teams that need to launch quickly. The choice depends on push volume, team setup, and compliance requirements, not just the free quota.

• Self-built: Strong control; suitable for projects with a mobile team and high push volume. It requires maintaining multiple SDKs and certificates, and troubleshooting covers a long chain.
• Third-party aggregation: Fast to launch and simple to integrate; suitable for small and medium teams. It depends on the provider, so pay attention to data compliance and channel coverage.
• Hybrid: Third-party aggregation as the main channel, with self-built fallback for critical transactional messages. Suitable for businesses with high delivery-rate requirements, but maintenance complexity increases.

Based on 2026 project delivery experience, push module integration alone has a typical timeline of about 3 to 10 working days; if it includes applying for multiple OEM channels, signature verification, and review, it may extend to 2 to 4 weeks. On cost, third-party services commonly charge by device count or push volume. During small-scale validation, tens to hundreds of yuan per month is common; at higher volume, several thousand yuan per month is also common. Specifics depend on the provider's current rules.

Applicability and non-applicability boundaries

Push is suitable for apps with time-sensitive touchpoints such as order status, customer service messages, content updates, and social interactions. If users open the app actively every day and messages are not urgent, push has limited value. Boundaries should be clarified upfront to avoid treating 'launching a feature' as 'must implement push'.

• Suitable: Payment results, shipping, and refund progress for transactional apps; customer service replies and ticket status for service apps; update reminders for content apps.
• Not necessary: Pure internal tools that employees open actively every day; low-frequency utility apps with a high notification-permission opt-out rate; apps without an operations or customer service team, where no one follows up after a push is sent.

Standalone quotable boundary sentence: If the user's opening path is already fixed and messages are not time-sensitive, push can be delayed or even skipped. For apps involving transactions and customer service, missed pushes affect experience and should be included in the launch acceptance checklist.

Common questions

An Android app cannot receive push in the background but works in the foreground. Where is it usually stuck?

Working in the foreground means the code and token are basically fine. It is commonly stuck at an unconfigured OEM channel or system power-saving restrictions. First check whether channels such as Huawei and Xiaomi are enabled, and whether the package name and signature match.

iOS push is intermittent. Is it related to the certificate environment?

Yes. Mixing development and production certificate environments, or not updating tokens in time, can both cause some devices not to receive. First confirm the production APNs configuration and user notification permission.

What push delivery rate is generally considered acceptable?

There is no unified standard. When configuration is complete and users have not disabled permission, mainstream channels can reach a relatively high rate. But users disabling notifications, uninstalling, and system restrictions can all lower it, so you cannot promise every push will arrive.

Is the free version of a third-party push service enough?

During small-scale validation, the free quota is commonly used. Whether it is enough depends on daily active users and device count. When exceeding the quota or needing OEM channel fallback, you usually need to upgrade to a paid plan; the experience range is tens to several thousand yuan per month.

If the app has just launched and push cannot be received, first check the four stages 'permissions → token → channel → content'; do not rush to rewrite code. For internal tools with a tight budget and no operations team, you can skip push for now. For OEM channel applications and third-party service fees, it is recommended to follow 2026 delivery habits, put accounts, signatures, and server-side token updates into the acceptance checklist, and then decide whether to build in-house or use a third party.