Notes ·
The Website Is Often the More Private Version
“Native Apps Should Be Avoided Whenever Possible” makes a convincing argument that people should question why every store, restaurant, bank, airline and government service wants an application installed on their phone.
Most people understand that granting location, camera or microphone access gives an app sensitive information. I do not think nearly as many people understand everything a native application can learn and transmit without those obvious permission prompts.
An installed app can communicate with remote servers, observe basic device and network information, retain identifiers and include third-party analytics or advertising frameworks. Those embedded frameworks operate as part of the application and must be included in the developer’s privacy disclosures. Apple explicitly defines third-party partners as analytics tools, advertising networks and external SDKs included inside an app.
A website can track people too. It can receive an IP address, store cookies, load advertising scripts and attempt browser fingerprinting. The web is not automatically private.
The important difference is the security boundary.
Websites run inside a browser sandbox. Access to sensitive capabilities is generally restricted by browser policies, user interaction and explicit permission. Native applications have much deeper integration with the operating system and can continue performing certain work after their interface is no longer visible.
The article summarizes that difference with this comparison:
| Capability | Native app | Website or PWA |
|---|---|---|
| Background location tracking | Yes, with the required operating-system permission | No general continuous background GPS access |
| Run at device startup | Yes, subject to platform restrictions | Limited PWA and service-worker behavior, not unrestricted background startup |
| Access biometric hardware | Yes | Limited, generally user-initiated through WebAuthn |
| Modify or delete device storage | Yes, within the app’s access and platform sandbox | Limited to explicitly authorized files or folders |
| Embed third-party software | Yes, through compiled SDKs operating inside the app | Third-party scripts remain constrained by browser and origin policies |
| Transmit data before a sensitive permission prompt | Yes | Yes, but with less access to device-level information |
| Push notifications while closed | Yes | Yes, after the user opts in |
| Access contacts, call logs or SMS | Possible with platform permission | Contacts only on supporting browsers, with explicit selection |
| Prevent the device from sleeping | Yes | Yes, with permission through the Screen Wake Lock API |
| Camera and microphone | Yes, after permission | Yes, after permission and with browser indicators |
| Offline functionality | Yes | Yes, through service workers and browser storage |
The exact capabilities vary across iOS, Android and individual browsers, but the general distinction is real. Android, for example, allows an application to access location while running in the background after the user grants the dedicated background-location permission. On newer versions, granting that access requires visiting the application’s settings rather than accepting an ordinary foreground prompt.
Web geolocation also requires permission, but it operates through the browser. The website must use HTTPS, and the browser controls whether access is granted, denied, temporary or persistent.
The difference is even clearer with contacts. A native application may receive broad contact access after permission is granted. The web Contact Picker API only shares the specific contacts and fields selected by the user, requires interaction each time and does not provide persistent access to the address book. Browser support remains limited, but the privacy model is much better.
The article uses the 2026 White House app as its central example. Researchers examining the application found numerous analytics components despite its App Store privacy manifest declaring no collected data. The article says its location pipeline could poll precise coordinates in both the foreground and background and that most of its network requests went to third-party services rather than the White House website.
That is the part people rarely see. An app can appear to offer a simple interface while containing a collection of outside analytics, messaging, advertising and attribution systems that have little to do with the feature the person installed it to use.
This is not an argument that native software is inherently bad. Some software genuinely needs deeper access to the device. Bluetooth and NFC tools, games, accessibility software, professional media applications, secure communication tools and hardware controllers may all have legitimate reasons to be native.
It is an argument that the access should be justified.
A grocery store does not need an enduring position inside my phone. A restaurant menu does not need a native application. A retailer should not require device access to provide a coupon. A news organization does not need to install third-party tracking frameworks when it already has a functioning website.
When a company aggressively pushes an app for something that works perfectly well on the web, the question should be what the company gains from the installation.
Often, the answer is better access to notifications, identifiers, behavioral analytics and the continuing presence of its software on the device.
The practical response is simple: use the website when it provides the same service, remove applications that are no longer needed and deny permissions that are unrelated to the feature being used.
Installing an app should be a deliberate decision, not the default response to a banner asking us to leave the safer version of a service.