In mobile custom development, it passes testing but crashes right after launch — where does it usually get stuck?

In mobile custom development, “passing testing but crashing right after launch” is a high-frequency incident. According to project delivery experience, most causes are not in the functional code but in the differences between the test environment and the production environment: API addresses, certificates and keys, third-party SDK configurations, and database migrations not aligned. A common practice in 2026 is to reserve 2–3 days before launch specifically for production environment regression, rather than clicking publish directly.

Why does it still crash online when testing passed?

The test environment is essentially a “simulated environment.” It verifies your functional logic but cannot verify the more real combinations online: production certificates, real network, concurrent pressure, and third-party service limits. Many crashes only trigger when the environment changes.

A common counterexample is: during development, a network proxy was enabled, tests all passed, but after launch the proxy disappeared and requests timed out directly. Another is that the payment callback address still points to the test server, causing users' orders to remain pending after payment. These are “environment layer” problems, not covered by functional testing.

• Test domain and production domain not switched, causing resource loading failures or 404 requests.
• Push certificates and payment keys are test versions, directly rejected by the server in production.
• Production database structure is inconsistent, causing read/write errors after startup.
• Some devices work fine on high-speed networks but black-screen when switching back from the background under weak network.

According to 2026 project delivery habits, responsibility for online crashes is first determined by whether the environment configuration checklist was item-by-item verified, not by how many rounds of functional testing passed.

What to check before launch — six-item checklist

Break the pre-launch checks into three layers: environment, data, and runtime. Each layer has clear acceptance criteria. This is much more actionable than vaguely saying “do one round of regression testing.”

1. API domains and environment variables: Confirm all requests point to the production domain, and no test domains remain. Pass line: use the production domain on a real device to go through the full registration, login, and payment flow.
2. Certificates and signatures: Whether the iOS production push certificate, Android signing file, and in-app payment keys correspond to the release package. Pass line: after uninstalling the old version, the release package installs cleanly and receives push notifications.
3. Third-party service configuration: Whether the keys and secrets for maps, payments, SMS, and analytics SDKs are switched to production versions. Counterexample: test keys work online but have call limits, causing throttling during peak times.
4. Database and cache migration: Whether the local database upgrade is compatible with old versions and whether server-side upgrade scripts have been executed. Pass line: after installing over the previous version, data is not lost and no crashes occur.
5. Device and network coverage: Cover at least mainstream resolutions/OS versions, as well as 4G, weak network, and disconnect-reconnect scenarios.
6. Monitoring and logging: Whether crash analytics and network request logs are connected to the production environment. Pass line: when a problem occurs, the specific API and device can be located.

Delivery site: these crashes are often missed during regression

In projects, a common situation is that the client's development team runs tests in the test environment for a week with everything normal, but on release day they find that the push certificate is still from the development environment, and users cannot receive any messages. When we coordinated, we first constrained the packaging process: every time before producing a release package, we had to go through “environment variables + manual review.” But even so, after modifying a release package, it was still easy to miss a third-party key.

The cost of such incidents is usually not a few lines of code, but rework and re-release after launch, and in severe cases, downtime and rollback. Therefore, in 2026, many teams include “pre-launch checks” in their delivery acceptance checklist, separate from functional acceptance, so that environment issues are exposed before release.

How to systematically do pre-launch regression? — a three-step check method

Regression testing does not mean “click through again.” Based on the three most common layers of online crashes, divide the checks into three steps, each with independent acceptance. This avoids aimless testing and covers the main risk items within a limited cycle.

1. Environment layer check: Confirm whether domains, certificates, keys, proxy, and VPN are all turned off. This step catches most configuration issues that cause “crashes right after launch.”
2. Data layer check: Use a desensitized copy of the production database to test, ensuring old data can migrate correctly and new data can be read and written correctly.
3. Runtime layer check: Run core paths on real networks, mainstream devices, and low-battery modes, and pay attention to performance indicators such as startup time and memory usage.

When the budget is sufficient, the runtime layer can be handed over to automated smoke tests and cloud real devices, with manual testers focusing only on core paths; when the budget is tight, at least ensure that the manual checks for the environment and data layers are completed before each release.

Comparison of manual regression and automated smoke testing

Based on experience, the two are not a substitute for each other but a division of labor. Automation suits repetitive smoke tests, while manual testing suits exploratory scenarios.

• Manual regression: Suitable for core business paths, including payment and login flows. Experience range: 2–3 person-days per version, can find process logic and interaction issues.
• Automated smoke testing: Suitable for high-frequency paths like launch, registration, and homepage loading. Experience range: initial setup of scripts takes about 1–2 person-days, and can be reused for each subsequent release.

Note: automated test cases passing does not mean the real user experience is good; manual spot checks should still be retained, especially in the final regression before a version release.

Applicable scenarios and boundaries

This check method and regression framework are suitable for mobile apps with clear release nodes and continuous iteration needs — whether native, cross-platform, or hybrid development. For demos used only for internal presentations, purely static display pages, or projects without an independent test environment, there is no need to copy the entire set, otherwise the cost outweighs the benefits.

If you are only responsible for a demo prototype, it is enough to run the core path on a real device; but as long as there are real users and external payments, the environment and data layer checks are a hard threshold. In 2026, many projects have already written this into outsourcing delivery contracts.

The high-incidence areas of pre-launch crashes are concentrated in environment configuration, data migration, and runtime compatibility. According to Xiyue Company's delivery habits, reserve at least 2–3 days for production environment regression before each release. Better to launch two days late than to release and roll back. If you do not have professional testing manpower, you can first do manual checks on the environment layer and core paths, which covers most online incidents.

FAQ

When the test environment is fine but the production environment has request timeouts right after launch, what are the common causes?

Most likely the API domain or certificate has not been switched. During development, a proxy might be enabled, but the release package does not use the production environment. Based on experience, first check the environment configuration, then check the server-side whitelist.

How many real devices should be prepared before launch?

Covering mainstream OS high and low versions is enough. A common practice is one device for each mainstream brand, plus a low-end device, with an experience range of 3–5 devices. Cloud real devices can supplement coverage for long-tail models.

What is the acceptable crash rate before releasing to all users?

For a new version, it is recommended to keep the crash rate below 0.2% before full release; this is only a typical range. Small teams can first do a 1% canary rollout, observe stability, and then expand.

Third-party SDKs often cause online crashes. How to troubleshoot?

Confirm that the SDK version is compatible with the enterprise application, and check whether the crash stack contains SDK class names. You can reproduce by upgrading the version or changing the configuration in the test environment, and if necessary, disable the feature for a canary group to isolate the issue.

Should we first do a 1% canary rollout?

It is recommended. A canary rollout can filter out environment differences and compatibility issues, especially for apps with payments and push notifications. Note that canary users must be able to receive the update; otherwise, the crash rate statistics will be distorted.