The Problem with Android Apps That Could Be Web Pages: Developer Analysis Highlights Industry Challenges

“Do we really need this app?”—a fundamental question backed by code analysis has sparked discussion in the tech community. Blogger danq.me reported feeling significant discomfort after being required to install the Android app “Travelbound” to check their child’s travel schedule, prompting them to reverse-engineer the app’s network communications.

The analysis revealed that the app merely displays text and images delivered via a web API, making its functionality entirely replaceable by a web page. This finding, shared on the author’s blog and the online community Lobsters, has stirred debate within the industry.

The App in Question and Its “Anti-Features”

The controversy centers around the Travelbound app, provided by a group travel service. Parents of students at a performing arts school were asked to install the app to access travel itineraries, accommodation details, and travel documents for a Disney World performance.

However, upon analyzing the app, danq.me discovered that its contents consisted solely of text-based itineraries, a few photos, and links to PDF files—all delivered over the internet. In essence, the information provided by the app could easily have been presented on a standard HTML web page.

Moreover, danq.me labeled two non-essential features of the app as “anti-features.” One involved sending tracking data linked to Google accounts back to the developer. The other displayed advertisements for other trips offered by the company under the guise of “inspiration.” The developer expressed strong criticism of these elements.

The Reverse Engineering Process

To uncover the app’s inner workings, danq.me followed these steps to analyze its network traffic:

1. Setting Up a Virtual Environment: Created a new virtual device using Android Studio’s Virtual Device Manager.
2. Rooting the Device: Verified adb shell functionality and rooted the virtual device using the rootAVD tool.
3. Permission Configuration: Ran Magisk and configured it to automatically approve the app’s su permission requests.
4. Proxy Setup: Enabled HTTP Toolkit to intercept all traffic from the virtual device. HTTP Toolkit installed a fake VPN provider to route device communications through the proxy.
5. App Installation: Installed the Travelbound app from the Play Store.
6. Traffic Filtering: Configured HTTP Toolkit to focus only on traffic generated by the Travelbound app.

Through this analysis, danq.me discovered that the app constructs a URL in the format https://travelbound.api.vamoos.com/api/itineraries/{username}-{password} by combining the user’s credentials. Requests to this endpoint returned JSON data that included arrays of itinerary details, lists of advertisements to display, and references to image files hosted on Amazon S3.

danq.me questioned why the developer didn’t simply present this dynamically generated HTML content as a web page. They also noted that the short expiration times set for image files hosted on Amazon S3 necessitated frequent JSON data retrieval.

Why an App? Examining the User Experience

This case challenges the current practices in mobile app development. While native apps excel in areas like camera access, GPS functionality, Bluetooth LE, advanced offline processing, and rich push notifications, simple tasks like displaying text and images—such as in the case of the Travelbound app—can be easily handled by a web page or a Progressive Web App (PWA).

Several factors may explain why companies opt for apps over web pages: app install numbers are often a key performance indicator (KPI) for business or product teams; apps remain visible on a user’s home screen and can send push notifications to drive engagement; and tracking user behavior and displaying ads are often more detailed and straightforward within apps than on the web.

However, this approach risks degrading the user experience. Apps require installation, consume storage space, and necessitate updates—imposing burdens on users. From an accessibility standpoint, web pages often outperform apps, offering better support for text scaling and screen readers.

Lessons for the Industry and Future Prospects

This case highlights the issue of “means becoming ends” in Android app development. Similar to how Fermata Auto highlighted restrictions and workarounds in Android Auto, this scenario underscores the need to balance platform constraints with user experience.

Product managers and engineers should always ask themselves, “Why can’t this be a web page?” when starting a new mobile project. If a clear answer is lacking, they should seriously consider using web technologies, including PWAs.

This is particularly true for enterprise or group-targeted information distribution platforms, where users are often forced to install dedicated apps just to access basic information. It is hoped that this case will lead to a renewed focus on user-centric product design.

Editorial Opinion

This case serves as a valuable example of questioning the essence of user experience, often overlooked amidst the push for “mobile-first” strategies. In the short term, particularly for simple B2C information distribution services, there may be an accelerated reevaluation of whether apps are truly necessary. Awareness of this issue within the developer community could lead to more critical discussions around decisions to “appify” services where a web solution would suffice.

In the long term, companies may shift their focus from traditional KPIs like app install numbers to providing users with the most optimal means of accessing information. The adoption of PWAs could increase, restricting native app development to areas where native functionalities—such as advanced hardware control or complex offline processing—are genuinely required. However, “unnecessary apps” driven by data collection or ad revenue motives are likely to persist.

From the editorial perspective, product planners should take this case as a serious reminder of the importance of thoughtful and user-focused decision-making.

References

• “I converted an Android app to a webpage”, by danq.me via abhin4v — Lobsters, 2026-07-11T05:24:30.000Z (ARR)
• Source URL: https://danq.me/2026/07/09/your-app-could-have-been-a-webpage/