You were told a WebView is «free» and «always there.» So you built your checkout, your sign-up, your catalog on top of it — screens that load as documents from your server, which in turn lean on a maps SDK, a deep-link service, a payments SDK, an analytics vendor. Each is someone else's infrastructure, and someone else's decision about price, availability, and policy. The pattern is older than mobile: when a platform owns a capability you depend on, it eventually reprices, restricts, or pulls it. The only question is when.

The rug-pull playbook is the standard, not the exception

In 2018, Google rewrote Maps API pricing overnight; delivery and logistics apps that had built their entire geolocation stack on it woke up to bills roughly 1,400% higher, with some ride-share companies jumping from about $30,000 to $450,000 a month. In 2016, Facebook announced Parse would shut down within a year, forcing migrations for 600,000+ apps — many never recovered. In 2023, X (Twitter) ended free API access and an entire ecosystem of companies built on it had to pivot or die. In August 2025, Firebase Dynamic Links was sunset; every link clicked since returns a 404. None of these vendors were small. That is the point: size is not a stability guarantee, only a larger blast radius when strategy changes.

Your WebView compounds the exposure

A native feature lives inside your compiled, signed binary — you decide when it ships and whether it keeps working. A WebView screen is a document fetched from a server at session time, and that document is only as alive as every dependency behind it. If the maps SDK reprices, the link service sunsets, or the analytics vendor changes its API, the screen your users see can break or silently degrade. And you may not even know which «free» dependency failed, because the failure shows up as a blank tile or a dead button, not a red alert.

The store is the final single point of failure

Even with a perfect own stack, the channel that delivers your app is someone else's. In 2025, Apple's enforcement of the EU Digital Services Act delisted 135,000+ apps in days for missing trader information; over the same period, account bans under clause 3.2(f) rose about 300% year over year, and one social app lost its 200,000 accumulated users overnight when it was removed. You cannot appeal a policy shift fast enough to save a quarter.

The escape hatch is a runtime you control

A host-owned runtime runs your mini-program as a first-party, signed, sandboxed component. The logic ships in a package you sign and version — not in a document someone else serves. When a third-party service reprices or disappears, you swap the integration inside your own component and re-publish on your own cadence; the app keeps running. You are not a hostage to a vendor's roadmap, because the flows users touch most are yours: versioned, auditable, recoverable.

The trade-off at a glance

DimensionWebView + third-party servicesHost-owned runtime
Where core logic livesDocument fetched from a server per sessionSigned, versioned package you control
Exposure to vendor repricingHigh — maps, links, SDKs reprice overnightContained — swap the integration internally
Exposure to service shutdownHigh — Parse- or FDL-style sunsets break flowsLow — core flow runs without the external service
Recovery timeWait for vendor, migrate, re-shipMinutes — re-publish your own component
Channel riskStore policy can delist the appApp keeps running; you control the runtime

Sources