In our production mobile apps, we’re able to trigger a black screen by aggressively switching between bottom tabs repeatedly. This is obviously an extreme negative test and not typical user behavior, but we’re using it to fully validate stability and lifecycle handling in the app.
Here’s a short video showing what happens at :50 second mark: https://streamable.com/dpsoao
What’s interesting is that we’re seeing the same behavior in our new redesigned app in development, which prompted us to check the current production app for comparison. Since this occurs in both, it suggests the behavior may not be specific to our new implementation.
Has anyone seen this before in Cordova-based OutSystems mobile apps? Are there known lifecycle, navigation, or WebView behaviors under aggressive tab switching that we should be aware of? We’re especially interested in any guidance on how to debug, isolate, or mitigate this type of issue.
Appreciate any insights or pointers.
Hi @Evan Moore ,
Could you share a bit more detail?
From the video, it looks like each tab switch triggers a request and re-render. Since you’re seeing the same issue in the redesigned dev app as well, it may be related to iOS WKWebView lifecycle behavior rather than app logic.
Have you tried reproducing it with a simple test app with just bottom navigation and no data calls?
Hey @Evan Moore,Yes — this is a known behavior pattern in Cordova-based OutSystems mobile apps, and it’s typically related to WebView lifecycle + navigation race conditions, not your app redesign.
What’s happening (high level):
Rapid bottom-tab switching triggers multiple screen unload/load cycles faster than the WebView can stabilize.
Cordova uses a single WebView; under aggressive navigation, the WebView can momentarily lose its rendered content and fail to repaint → resulting in a black screen.
This is more likely on Android due to WebView memory pressure and lifecycle callbacks (onPause/onResume) firing back-to-back.
Why it appears in both apps:
This behavior sits below your implementation, in the Cordova + OS navigation stack, not in your screen logic.
Mitigation & best practices:
Avoid heavy logic in OnInitialize / OnReady of tab screens.
Prevent rapid repeated navigation (debounce tab taps).
Ensure async calls are canceled or guarded when leaving a screen.
Test with Navigation logging enabled to spot overlapping navigations.
Keep plugins and runtime updated (some WebView stability fixes land there).
Debug tips:
Reproduce with Chrome Remote Debugging (Android) and watch the WebView console errors.
Enable LifeCycle events logging to confirm overlapping resume/pause flows.
Bottom line: This is a platform-level edge case under extreme stress testing. With proper guards and lighter tab screens, it’s usually mitigated and not seen in real user behavior.
Hope this helps...