Today’s Google I/O keynote intro­duced a new tech­nol­o­gy called Android Instant Apps. In a nut­shell, Instant Apps dis­plays a small, focused por­tion of an app when a user clicks on a relat­ed link — even if the app isn’t installed on their sys­tem. The exam­ple used in the keynote was the Buz­zfeed Video app: when a user clicks on a URL to view a Buz­zfeed video, and doesn’t have the app installed, the URL is inter­cept­ed by the Android sys­tem and opened in a part of the app, deliv­ered from the Google Play servers, rather than in a browser.

Instant Apps requires the app cre­ator to build their app in a pre­scribed way, using deep link­ing and set­ting up mod­u­lar views, but it appar­ent­ly only takes about a day to mod­i­fy an exist­ing app to work in this way. There are still some unan­swered ques­tions about Instant Apps, not least in regards to whether their use is optional.

This cer­tain­ly solves the biggest prob­lems with apps: hav­ing peo­ple find them, and install them. And from the per­spec­tive of the user it prob­a­bly makes no dif­fer­ence if they ful­fil their task through the medi­um of a web­site, app or Instant App — pro­vid­ed the medi­um is seam­less to tran­si­tion, fast to load, and focused on the task.

But for devel­op­ers, an Instant App doesn’t seem to offer much val­ue beyond a web­site: as it’s an Android-only ser­vice, the URL that launch­es it can be shared across iOS and desk­top also, mean­ing there is still a dupli­ca­tion of effort to build that web presence.

So then what’s the incen­tive of putting in the extra work for Instant Apps? Per­haps it exists only when the app can offer some­thing that the web is unable to, such as access to sys­tem-lev­el APIs (like pay­ments); or per­haps when the web alter­na­tive isn’t optimised.

Oth­er­wise this seems like it’s a drop-in replace­ment for the web; and, as Klint Fin­ley said when dis­cussing the con­cep­tu­al­ly-relat­ed uni­ver­sal links on iOS:

If you want apps that work like the web, the web is still your best choice.