Custom-developed app goes live but push notifications aren't received—where does the problem usually lie?

In 2026, when a custom-developed app goes live but push notifications don't arrive, the cause is usually not bad code but a broken link in the push chain: permissions, process, vendor channel, or certificate. Based on our project delivery experience, start by checking the user's phone settings, then verify whether a system channel exists to catch messages after the app is killed, and finally review the server and certificates. Following this order, you can usually pinpoint the main cause within half a day.

Push notifications: from 'I sent it' to 'you saw it' — several gates in between

Many people assume that once a message is sent, the user will definitely see it. In reality, a push must pass through four gates on its way from the server to the notification bar: whether the server actually delivered it successfully; whether the device token registered with the push provider is valid; whether the phone OS permits this app to show notifications; and if the app process is gone, whether the system can receive and display it on the app's behalf. If any gate is closed, the message simply 'vanishes.'

• The server sends the message, but the push provider returns failure or no receipt—this indicates a configuration or account problem.
• The device token is expired or the environment is wrong (for example, mixing test and production builds), so messages fail to be delivered.
• The user has disabled notification permission or the notification category, so the message arrives but cannot pop up.
• The app process is cleaned up by the system, and without a vendor system channel as a fallback, background messages are discarded directly.

iOS and Android differ significantly along this chain. iOS delivers uniformly through APNs; as long as the certificate and environment are correct, offline receipt is relatively stable. Android depends on the situation: when the app is in the foreground, it can receive via the SDK's long connection, but if the app is killed by the system's power-saving policy, the online channel of most third-party push SDKs stops working, and you have to rely on system push capabilities from vendors such as Huawei, Xiaomi, OPPO, vivo and Honor.

Self-test order: separate phone settings from development first

When users report not receiving pushes, don't start digging through code. Prepare a day-to-day Android phone and an iPhone, and run a self-test in the order below. Based on 2026 delivery experience, a full push self-test takes 30 to 90 minutes; much of that time is spent waiting for vendor backend receipt status updates, not on the operations themselves.

1. Open system settings to confirm notification permission is enabled, and also check whether the 'notification category' has been separately turned off.
2. Swipe the app away from the recent tasks list, lock the screen and wait about one minute, then send a test message from the server and see whether the notification pops up.
3. If it pops up, check the delivery receipt in the push provider's console. If it doesn't pop up, check whether the app has successfully registered and uploaded the token for the vendor system channel.
4. Finally, switch to the production environment and run again on a device signed with the production build, to confirm the problem is not caused by a development certificate.

The step most likely to be misjudged is the second one. Many projects just tap a test push while the app is in the foreground; if it arrives, they assume the chain is fine. Actually, this doesn't cover the core scenario of the app being killed. To verify offline delivery capability, treat 'app not in the foreground' as a test condition, not an afterthought.

Based on pitfalls hit in real projects, let me add one constraint: when self-testing, try to use a phone with the same system version as your actual users, not an engineering device that has USB debugging always on. Engineering devices do not restrict background processes by default, and their power-saving policy differs from ordinary user phones, which can easily create the illusion that 'no problem in testing.'

At the delivery site: everything works during testing, but 'loses contact' after going live

In early 2026, we delivered an app for a client in the booking service business. The requirement said 'push notifications' but did not specify that users should still receive them when the screen is locked or the background process is killed. During development, we verified with a test device in the foreground and messages popped up normally, so the project entered acceptance smoothly. In acceptance, we changed to real user behavior—swiping the app out of recent tasks and locking the screen for fifteen minutes before waiting for a push. Only online-channel messages came through; after a long time, nothing arrived.

Later investigation showed that during testing we connected to the push provider's test environment, the production build had not switched to the production environment, and the vendor system channel had not been applied for or configured at all. We had to temporarily add Huawei and Xiaomi vendor SDKs, re-package and release, which delayed the launch by about one week and added about 5% to 10% to the original development cost. This cost could have been completely avoided by one sentence in the requirements review: 'Do you need offline delivery capability?'

This kind of rework recurs. The experience range is: for order alerts, approval notifications, or verification-code apps, set the vendor system channel as the acceptance baseline and don't skimp; for mere content alerts, you can skip the channel and an in-app message center is more economical.

Only online push, or connect vendor system channels: how to choose between two options

In 2026, whether to implement vendor channels mainly depends on whether the business needs to reach users even when they do not open the app. Below is a comparison of two common approaches, useful for solution selection and budget estimation.

• Option A: Only integrate the online functionality of a third-party push SDK. The development effort is relatively small—integrating one SDK usually takes 3 to 5 days, and the fee is mostly covered by the push provider's subscription, starting at the level of several thousand yuan. The app receives pushes when it is in the foreground or not killed, but it basically fails once the user kills the background. This suits news, content, and utility apps that users would open on their own.
• Option B: Online push plus mainstream Android vendor system channels. You must apply for open-platform accounts from each vendor, integrate their SDKs one by one, and perform real-device joint debugging. Based on 2026 delivery experience, the first integration and debugging covering Huawei, Xiaomi, OPPO, vivo, and Honor typically falls in the range of 1 to 2 weeks. If you only connect Huawei and Xiaomi, it is common to finish within a week. The additional cost depends on the technical solution and outsourcing quote, and is usually in the 10% to 15% range of the development fee.

How can you tell whether the development team really connected the vendor channel? Go to the push provider's console and check for a vendor receipt or delivery details. If the status is only 'sent successfully' but there is no 'delivery receipt,' that means the team only called the server-side API and did not complete the joint debugging of the phone's system channel. At acceptance, ask for the receipt screenshots from each vendor's console, rather than merely watching a test video.

Applicable and non-applicable boundaries: how to set the acceptance baseline

Scenarios that truly need solid offline push are those where users have no time to open the app actively, such as approvals, meeting reminders, appointment changes, order status, and verification codes. A delay of half an hour renders these useless; only a system-level channel can hold them.

Scenarios that are not suitable for heavy push investment are content communities or low-frequency tools: since users don't visit often, instead of pursuing offline arrival rate it is better to build an in-app message center, so users can pull the latest content when they next open the app. This boundary should be clearly understood, because no solution can guarantee that every push is seen by the user—the user can disable notifications at the system level, or uninstall the app. In our projects, we usually set the goal as 'receipts arrive for the majority, given that notification permission is granted and the device is online,' rather than 100% for every user, and this makes acceptance and troubleshooting clear.

If your app handles strong time-sensitive functions such as orders, approvals, or verification codes, clearly write 'must connect mainstream Android vendor system channels' into your custom development requirements, and put 'push notifications must still be received after the process is killed' into the acceptance standard. If it is only content alerts, don't rush to increase schedule and budget; building an in-app message center is more suitable for the actual needs of most businesses.

Frequently Asked Questions

Why can other apps receive push notifications, but ours cannot?

First check whether your own app's notification permission is turned off, and then verify whether the vendor system channel is connected. If other apps on the same phone receive pushes, the system itself is fine—the difference usually lies in your app or its push configuration.

Will connecting the vendor system channel guarantee delivery?

No. A vendor channel improves the offline delivery rate, but users can still disable notification permission, and some domestic ROMs perform deeper cleaning due to power-saving policies. The goal should be 'reachable by the majority,' not 100% guaranteed for everyone.

Push notifications are received during testing, but not in the production build. What are the common causes?

The common causes are mismatched certificates or environments, such as using an iOS development push certificate in a production build, or an Android package name/signature inconsistent with the vendor console. Also check whether the push provider console has been switched to the production environment.

If we only connected online push now, is it troublesome to add vendor channels later?

Not troublesome, but you will need to release a new version. According to each Android vendor's requirements, you need to apply for access, update client configuration, and perform real-device joint debugging. The typical experience range is one to two weeks; we suggest evaluating this before the first release.

Will adding vendor system channels greatly increase the installation package size?

Different push providers and vendor SDKs have different sizes; usually the package increases by less than 1 MB. This has little impact on most apps, so don't abandon offline delivery capability just because of size.

Troubleshooting push issues is essentially about distinguishing boundaries: first the user, then the vendor channel, and finally your own code. In 2026 custom development delivery, writing 'whether offline receipts are received' into the acceptance criteria can save a lot of post-launch disputes. If you are building a strongly time-sensitive app for orders, approvals, or verification codes, be sure to confirm whether vendor system channels are needed during the requirements phase. If you are only building a content alert, it is more pragmatic to put the budget in an in-app message center.