Choosing Native vs WebView: inside Hearthly's trade-off decision for their first mobile app

Tech · 5 min read

Hearthly's core marketplace already had a responsive web app, but mobile sessions were growing and conversion on small screens lagged desktop. The team debated shipping a native app to improve performance and engagement versus wrapping their web product in a WebView for faster time-to-market. Engineering emphasized maintainability; product and design prioritized long-term engagement and nuanced interactions like offline job cards.

They quantified the decision: projected lift from native features (push, background sync, smoother animations) versus the cost of building and maintaining duplicate codebases. A four-week spike team built two prototypes: a native checkout flow and a WebView version using service workers and a minimal native shell. Benchmarks measured cold start time, perceived performance, offline behavior and engineering velocity.

The verdict favored a hybrid approach: a lightweight native shell with isolated native modules for payments, push notifications and offline job caching, while reusing the web stack for content and search. This reduced initial build time by 60% compared with a full native rewrite and preserved the ability to ship native-only features later; the article explains operational impact, how the team organized ownership, and the metrics they set to revisit the decision after six months.