The seams of a hybrid iOS app

Working on app links taught me that the most interesting code in a hybrid app lives at the seams.

Inside the running app, you can pretend the native shell and the embedded WKWebView are one thing. The shell wraps the WebView, the user taps around, screens load. The fiction holds as long as everything starts from a tab or a button. The moment a URL arrives from outside (a push notification, a shared link, a search result) the seam becomes visible. The URL was written for the web. The entry point is native. Something has to translate.

That something turns out to be one of the bigger pieces of architecture in the app. URLs come in flat: a host, a path, some query parameters. The native side thinks in tabs and view controllers. A URL has to become a navigation decision before the WebView has anything useful to load, and the decision isn’t always obvious. Did a Swiss user receive a .de link from a friend? They probably want the product, not a country mismatch. Is the URL pointing at a checkout page? The user almost certainly doesn’t want a freshly-loaded checkout view; they want their cart tab. Is the destination even still alive on our servers? Better to know before asking the WebView to fail.

What I took away is that hybrid apps make trade-offs visible. Pure-native apps don’t treat URLs as a first-class input. Pure-web apps don’t have native tabs to route into. Hybrid apps have both, and the seams between them become small architectural problems you have to solve deliberately. Six edge cases in, you have a system. The user doesn’t care which half they’re in. They want to get to the product. The seam should disappear.

The amount of work that takes is one of those things you don’t appreciate until you’ve done it.