If like me you're a Windows Phone user it can be painful to re-enter the United States after an overseas trip. At certain airports, including SFO, people with Apple and Android phones get to skip passport control. Not me -- I had to line up at a kiosk with the hoi polloi, jam my passport into the machine, and take a 20th-century selfie.

I see this (admittedly) first-world problem in two ways. As an owner of a minority smartphone with an uncertain future I wonder if I should bite the bullet and switch. But as a citizen of both the United States and the Web, I instead wonder why mobile passport control should have anything to do with the Apple and Google app stores. Can't a mobile Web app handle this relatively simple chore?

In my case, the answer is no. Internet Explorer on Windows Phone doesn't support HTML Media Capture and, thus, can't access the camera. But according to Airside Mobile, developer of the mobile passport control app, there are other issues that prevent support of mobile Web browsers.

Yes, HTML5 compatibility on mobile and tablet browsers has made remarkable strides. Those who have for years predicted the end of native mobile apps and app stores may one day be vindicated. For now, though, we're stuck watching a movie we've seen before.

In the original version of that movie, apps had to be written specially for Windows, Apple, and Linux computers. Then a surprising thing happened: A new system for linking documents together on a global network turned out to be far more than what it first seemed. In the beginning, Web technology looked like the future of publishing. Soon, however, it revealed itself to be the future of software.

That future was thrilling in two ways. First, developers who lacked the expertise and complex tooling required to support native apps on three platforms were suddenly back in the game. Web apps were clunky, but they were easy to write and they worked everywhere. It was a classic Clayton Christensen worse-is-better scenario. The Web unlocked an enormously long tail of useful apps that weren't beholden to vendors' platforms.

Our second thrill was a new immediacy in the relationship between developers and users. I could publish an app at 10 a.m., respond to a user's feedback at 10:15, and release a new version at 10:30. Download? Install? Those were 20th-century relics we were happy to discard.

Then, of course, came the remake. In the new version of the movie, apps must again be written specially for Apple, Google, and Windows computers. The leading roles have morphed a bit and shifted in order of precedence, but the plot remains the same. It still requires massive expertise and complex tooling to write apps for multiple native platforms. This time around, the app stores that separate developers from users impose more tax and more delay than we suffered in an era of distribution by snail-mailing optical discs.

While it's ironic to see tech companies impose tax and delay on their government, this is a weird situation. You could open the source code to all taxpayer-funded software and we'd still be in the same place. App stores have grown so powerful that even the mighty U.S. government must rely on them to deliver basic services to its citizens.

I'm a realist, so I won't pretend that ubiquitous support for HTML5 in mobile browsers will break this logjam. To create a useful app for the mobile Web, a developer needs to command the same kinds of expertise and tooling required to build a native app. But if developers could combine those ingredients just once, instead of once per platform, they'd serve more users -- and serve them better -- than is possible today. It happened once before. Here's hoping it will happen again.