An Expert’s Perspective on the White House App — Putting Security Findings in Context
Posted by Andrew Hoog
Andrew Hoog
Executive Summary
Recent reporting on the White House mobile app has overstated several security and privacy concerns by focusing on what the app could do rather than what it actually does in practice.
NowSecure analyzed the app using static and dynamic mobile application security testing. We found no evidence of unauthorized location tracking described in media coverage.
The app behaves like most modern mobile applications. It uses common third-party components and generally follows standard platform controls. It doesn’t present an unusual risk to users.
This is a good example of how easy it is to misread mobile app behavior without testing it in a real environment.
A More Complete View of the White House App
When the White House mobile app launched in March 2026, people quickly started analyzing it. Much of the early conversation focused on location tracking.
The WH app is not secretly tracking user location.
Some researchers saw location-related code in a third-party SDK — specifically OneSignal — and assumed it was active. But that conclusion came from static analysis alone.
When we ran the app on real devices and observed its behavior, we didn’t see any location data being collected or transmitted and that distinction is what the coverage missed.
Static analysis shows what an app can do. Dynamic testing shows what it actually does.
If you stop at static analysis, you only get part of the story.
Static analysis shows what an app can do. Dynamic testing shows what it actually does.
Capability Doesn’t Mean Behavior
Modern mobile apps rely heavily on SDKs like OneSignal. These platforms provide a wide range of features like notifications, messaging, analytics and in some cases, location capabilities. Developers choose what features to enable.
In this case, the OneSignal SDK includes location functionality, but that feature is not enabled in the current version of the app. While the permission appeared in earlier versions, it was not enabled by default. Even if it were enabled, the user would still need to explicitly grant permission at the OS level before any location data could be accessed.
The presence of code doesn’t mean the app uses it or that it can bypass platform protections.
But in practice, this pattern shows up across thousands of mobile apps. That said, context matters. For a high-profile app, especially one associated with the federal government, developers should expect more scrutiny. Even normal design decisions can raise questions.
That’s why teams building high-impact mobile apps often go further:
- Review SDKs more closely
- Reduce unnecessary dependencies
- Simplify the software stack where possible
What This Really Comes Down To
This isn’t really about one app. It’s about how people analyze mobile apps.
If you rely only on static analysis, you’ll see potential. If you include dynamic testing, you’ll see reality.
Without both, it’s easy to draw the wrong conclusions.
We see it regularly — code gets flagged, capabilities get misread and headlines run with the worst-case interpretation.
Best Practices for High-Impact Apps
Apps tied to government, finance, healthcare or large user bases operate under a microscope. That doesn’t make them inherently less secure but it does raise expectations for mobile app risk management.
For these applications, AppSec and DevSecOps teams should:
- Test continuously during development, using both static and dynamic analysis.
Static analysis shows what’s present in the binary. Dynamic analysis shows what’s active at runtime. Automated mobile application security testing integrated into CI/CD pipelines can identify issues before release. - Treat every SDK as part of your attack surface.
Evaluate third-party components for data collection, remote control capabilities and infrastructure dependencies. - Don’t disable platform security controls. Transport security and encryption protections exist for a reason. Turning them off globally (ATS on iOS, cleartext on Android) removes basic OS protections. .
- Validate privacy claims against actual behavior
Privacy disclosures must reflect observed data flows — not just intended functionality. - Don’t rely on app store reviews.
Apple and Google perform baseline checks, but they don’t validate full runtime behavior, third-party SDK activity or real-world data flows.
What the App Actually Does
There’s been a lot of noise about what this app might be doing. What matters is what it actually does.
Based on real-world testing, the app behaves like a typical mobile application. It does not secretly track location or bypass platform protections. Because this is a U.S. federal government application, it’s reasonable to treat it as a high-impact app and apply a higher standard of mobile app risk management. We recommend rigorous, continuous mobile application security testing.
The bigger lesson is simple: If you want to understand mobile app risk, you have to test how the app behaves — not just what the code suggests.
You also can’t assume app store reviews will catch everything. They won’t.
Static analysis shows what’s possible. Dynamic testing shows what’s real. And that distinction matters
See How Your Mobile Apps Actually Behave
If your mobile app security program relies on static analysis alone, you’re seeing half the picture. NowSecure Platform runs automated static and dynamic testing on real devices and tells you exactly where your apps stand. Get a demo.
Common Questions About the White House App Analysis
Does the White House app track your location?
No. Based on dynamic testing on real devices, we did not observe any location data being collected or transmitted. While location-related code exists in a third-party SDK, that functionality is not enabled and would require explicit user permission to access.
Why did some reports say the app could track users?
Most of those conclusions came from static analysis, which identifies what code is present in an app. It does not show whether those capabilities are actually in use. Dynamic testing is required to validate real-world behavior. We tested version 47.0.4 of the app and perhaps earlier versions had certain features enabled.
Are the findings in the app unusual?
No. The patterns observed — such as the use of third-party SDKs and configurable features — are common across modern mobile applications.
Isn’t app store review supposed to catch these issues?
App store reviews focus on baseline checks and policy compliance. They do not validate runtime behavior, third-party SDK activity, or real-world data flows. Organizations need their own mobile application security testing to fully understand risk.
