Google stopt eind dit jaar met Instant Apps

Google lijkt te stoppen met Instant Apps. Met die functie was het mogelijk Android-apps uit te proberen zonder ze direct te installeren. Android Authority zegt nu dat die functie weinig werd gebruikt en Google er eind dit jaar mee stopt.

Volgens Android Authority wil Google vanaf december 2025 stoppen met het aanbieden van Instant Apps. Dat blijkt uit een waarschuwing die in een Canary-build van Android Studio zit wanneer ontwikkelaars de dependency voor Instant Apps inladen. Ze krijgen dan een waarschuwing te zien dat 'ondersteuning voor Instant Apps in december 2025 uit Google Play wordt verwijderd'. In een toekomstige build van Android Studio, de Otter-build, worden alle ontwikkeltools voor die functionaliteit verwijderd zodat ontwikkelaars daar ook niet meer mee aan de slag kunnen.

Google bracht Instant Apps in 2016 uit. Tweakers schreef er destijds een uitgebreid achtergrondverhaal over. Met Instant Apps was het mogelijk om apps op een Android-toestel te draaien zonder dat die hoefden te worden geïnstalleerd. Dat was handig voor gebruikers die een app wilden uittesten of wanneer ze die slechts één keer wilden gebruiken. De technologie werkte door bijvoorbeeld een url te volgen of een nfc-tag te scannen.

Het is niet bekend waarom Google stopt met Instant Apps. Het bedrijf heeft het stoppen zelf nog niet bevestigd. De functie werd maar weinig gebruikt. Vermoedelijk kwam dat omdat het ontwikkelen en onderhouden van een Instant App relatief veel tijd kostte. Bovendien moesten apps klein blijven; er zat een maximumgrootte van 15MB aan.

Reacties (37)

[The Zep Man]

Bovendien moesten apps klein blijven; er zat een maximumgrootte van 15MB aan.

Gezien hoe brak geoptimaliseerd veel Android applicaties zijn qua opslag, verbaast het mij niet dat dit een lastige eis is.

[phYzar]

Ook al heb je zelf weinig ruimte nodig voor je eigen app, vaak vreten alle extra/3rd party libraries die je nodig hebt een flinke portie ruimte op.

[le1337]

Als iemand die vaak met Java werkt (APK is grotendeels gewoon een Java zip maar net iets anders).... zou ik zeggen dat de gemiddelde app maker niet weet hoe je een "shadow jar" maakt.... Waar de libraries compressed worden/onnodige data geskipt wordt.

Op die manier kreeg ik ook een applicatie van 10MB -> 0.5MB.

Dit is ook echt niet moeilijk overigens (voor een developer iig), een simpele google search of zelfs ChatGPT vraag en je weet hoe het moet.

Maar.... de gemiddelde developer die een jar klein maakt, gebruikt daarna ook vaak obfuscation (soort van encryptie om reverse engineering lastig te maken) waar je app size weer x2-20 wordt (ligt er aan hoe heftig je dit doet).

Zo heb ik een applicatie die 2MB als basis is en 50MB na obfuscation e.d.

[josttie]

Uhh Java != Android. Dat heeft mijn bedrijf ook op de harde manier geleerd
Android gebruikt geen shadow jar, alles wordt door de Android build tools in elkaar geschroeft. Daar zit een optimizer in (r8) en die verkleint ook automatisch de namen van classes (soort van obfuscation maar niet echt) en die gooit ook ongebruikte code weg.
Maarja -> dan wil jou designer opeens 20 plaatjes in hd resolutie in je app. Met Webp krijg je die wel klein, maar er zijn grenzen. Ook zijn sommige thirdparty libraries groot (soms terecht, soms onterecht). Daar gaat de tool ook nog eens overheen en die zal dat ook proberen te optimaliseren, maar daar zijn ook grenzen aan.
Dus "even een shadow jar bouwen" -> nee..
Even je plaatjes uploaded naar een web server om ze dan te downloaden en je app size klein houden -> kan, maar niet altijd.

Daarnaast heb je nu ook Bundles -> Als je een bundle upload naar Google Play, kan die een geoptimaliseerde APK genereren voor elke telefoon. Dus als jou display een grote resolutie heeft, gooit-ie lage resolutie plaatjes eruit. Als jou telefoon een ARM chip heeft, gooit-ie de Intel native libraries eruit. Dat scheelt nog het meeste voor de eindgebruiker.

[le1337]

Proguard is bij mij vaak te summier om echt file size te behouden. (Of user error van mij).
Shadowjar doet een 'ok' job op libs.

Mijn best and worst approach is een Memory Dump te maken van de lib.
(Daarmee bedoel ik, de applicatie inladen in memory, alle functies aanroepen van de lib die ik gebruik, en dan letterlijk de lib terug uit memory dumpen, met alleen de compiled methods/classes).

En dan include je... die lib.

Je krijgt een vreselijke halve lib, maar het draait wel zo. Omdat een Memory Dump extreem aggresief is, en zo kan je bijvoorbeeld, betaalde classes die in een Exception wel bestaan missen als die Exception niet voorkwam voordat je de Memory Dump uitvoert.
Zou ik dan aanraden? Nee. Werkt het goed t.b.v. fileSize? Ja

Waar proguard een lib van 8MB naar ~6MB shrinkte kreeg ik met een memory dump de lib naar 300kb voor mijn usecase.

[Ryangr0]

En wat heb je dan precies bereikt? Dit lijkt me veel te risicovol, met als enige "pro" dat er 5.7mb bespaard is. Ik zie regelmatig apps van honderden mb's.

[le1337]

Dat ging niet om een geheel publiekelijke app, en de beveiliging was daar prio 1.

Alles werd direct via een custom loader in je memory ingeladen, en deze data stond nooit direct op je telefoon zelf en kwam alleen direct je in memory na inladen.

Om die reden werd bij elke "inlaad" dus alles gedownload vanaf een server.
En als dat duizenden keren per dag gebeurd, is -6MB best fijn. Zeker als er bepaalde gebruikers verbinden met 100kbps internet in bijvoorbeeld India met een telefoon of PC uit het jaar 2000.

Dus is inderdaad wel een hele specifieke use case.
Maar mocht je een nog grote lib hebben (bijv 30MB) zou het profijt natuurlijk ook hoger zijn met zo'n methode.

De "betere" oplossing, zou natuurlijk zijn om gewoon geen lib te gebruiken, en zelf na te maken wat je precies nodig hebt als minimale variant, maar dat kost ook gewoon veel tijd in dat soort gevallen.

[- peter -]

Daar is r8/d8/proguard standaard aanwezig voor in Android build system.

[GertMenkel]

Er zit genoeg optimalisatie in de standaard-developertoolkit, maar als je app met een eigen render-engine komt (Compose/Flutter) kun je niet extreem veel ruimte besparen door er een goede treeshaker overheen te gooien. Technieken die voor Java werken, werken ook niet per se voor Android omdat Android geen standaard-Java draait. Dat .jar's voor Java zo groot zijn heeft meestal een andere reden.

Je levert in de praktijk vaak ook compatibiliteitslagen mee om makkelijker oude besturingssystemen te ondersteunen (die gedeeltes van de moderne OS-API herimplementeren waar nodig) en wat middleware om dingen als data-opslag makkelijker te maken.

Je hebt genoeg blog posts als deze waar de makkelijke valkuilen in worden genoemd. Het is niet dat een APK klein krijgen moeilijk is, de meeste bedrijven en ontwikkelaars geven er gewoon niet zoveel om omdat opslag goedkoop is.

[The Zep Man]

Ook al heb je zelf weinig ruimte nodig voor je eigen app, vaak vreten alle extra/3rd party libraries die je nodig hebt een flinke portie ruimte op.

Dan heb je veel ruimte nodig voor je applicatie. Libraries van derden waar je je applicatie van afhankelijk maakt en daarom moet toevoegen zijn ook onderdeel van je applicatie.

[josttie]

Het idee van instant apps is dus dat je een kleine versie van je app uitbrengt met gelimiteerde functionaliteit. Dus die 15MB is prima te redden, mits je project daarvoor is geoptimaliseerd. Alleen dat opsplitten kost wel tijd en resources -> als je bijvoorbeeld veer herbruikbare componenten samenvoegd en wat plaatjes dan moet je dat weer opsplitsen voor je instant app. Mijn gok is dat het ondersteunen van instant apps meer werkt kost dan het oplevert en ik ben het eigenlijk niet tegengekomen, dus bij gebrek aan bedrijven die het willen gebruiken kan je er maar beter mee ophouden. Ik, als iemand die Android apps maakt en graag nieuwe dingen probeert, heb het ook nog nooit gebruikt en heb er ook vanuit mijn bedrijf en onze klanten nooit interesse in gehad.

[GertMenkel]

Een APK kan makkelijk aan die grootte voldoen mits je de moeite neemt de optimalisatietools die al in Android Studio zitten te gebruiken.

Daarnaast zijn Instant Apps ook niet bedoeld om een volledige applicatie te zijn, dus de meeste features en dingen kun je uit de instant apps halen. Het belangrijkste voordeel voor makers ervan zal denk ik zijn dat je gebruikers naar een app kan sturen na het openen van een link, waar ze geen adblockers en andere anti-tracking aan kunnen zetten.

Ik denk dat het concept gewoon niet is aangeslagen. Ik kan me niet heugen dat ik de feature zelf ooit heb gebruikt. Waarom twee versies van een applicatie bijhouden als je met een druk op de knop de volledige versie ook kunt openen? Het is niet alsof een kleine app die bedoeld is om even snel en tijdelijk te werken nu geweldige klantretentie oplevert. Je kunt er een hele hoop leuke gimmicks mee uithalen (denk aan een kaart-app in een attractiepark die zo te openen is als je in de buurt van een beacon komt) maar in de praktijk zie je ze gewoon erg weinig.

[drfisheye]

Mijn werkgever maakt apps met .NET. Daar komen dus ook third party .NET assemblies bij mee. Daar valt voor Android niks aan te optimaliseren, want voor Android zijn dit gewoon blobs. Daarnaast boeit het ook niet om het te optimaliseren, want ruimte is domweg niet een daadwerkelijk probleem.

[pagani]

Gezien Android apps veelal kleiner zijn dan dezelfde iOS apps (https://www.emergetools.c...hat-much-smaller-than-ios) valt dat blijkbaar wel mee (of is het bij iOS nog erger...)

[le1337]

The size number shown in Google Play is the download size. This is the compressed app, whereas Apple shows the install size (uncompressed app)
Android pre-compiles a portion of its app to native code. This native code is stored alongside the app's dex bytecode, increasing our install size footprint.

Dat is eigenlijk wel een rare feature, hoe ze de download grootte zo laten zien. Zeker voor de mensen die altijd een volle telefoon hebben.

En

iOS apps are compiled as fully native vs. Android, which is only partially compiled

Dit vind ik dan wel erg matig aan de Android kant, de Android apps moeten dus bij opstarten? een gedeelte compilen als je apps opent, en zijn dus technisch gezien op sommige aspecten trager (Waarschijnlijk nihil, maar toch) dan ze zouden kunnen zijn voor een beetje opslag...

[Ghoelian]

Dit vind ik dan wel erg matig aan de Android kant, de Android apps moeten dus bij opstarten? een gedeelte compilen als je apps opent, en zijn dus technisch gezien op sommige aspecten trager (Waarschijnlijk nihil, maar toch) dan ze zouden kunnen zijn voor een beetje opslag...

Iirc, en dat is al een poosje geleden dus kan zijn dat dit niet 100% klopt, wordt de rest van de Android app gecompiled bij het installeren. Dit is denk ik zo gedaan omdat er gewoon veel te veel verschillende Android telefoons zijn om dat allemaal vooraf te compilen. Apple heeft een relatief klein productaanbod, dus die kunnen dat prima doen.

Na het updaten zie je vaak dat apps "geoptimaliseerd" worden. Dit is in feite gewoon het re-compilen van de app, maar dan voor de nieuwe systeemversie.

[The Zep Man]

Dat de één iets nog slechter doet maakt niet de ander goed.

[telenut]

Mijn kids spelen games met reclame in, en in die reclame lijk je dan dus plots een ander spel te kunnen spelen. Is dat dan zo een instant app? Blijkbaar niet, want dat zie ik enorm veel...
En uiteraard is het geen succes, iedereen wil dat zijn app op de smartphone van de gebruiker blijft staan. Zelfs al is het voor een pretpark, of vakantiepark.

[kodak]

Dat klinkt meer als instant misleiding gericht op kinderen. Waar Google nooit aan had mogen beginnen en eerder gestopt hoort te worden dan de legale diensten zoals leveren van instant apps.

[watercoolertje]

Het is gewoon interactieve reclame Het is vooralsnog gewoon legaal, maar als je er anders over denkt, klaag ze aan, dan weet je het zeker!

PS ouders mogen kinderen ook gewoon opvoeden en beperken in hun telefoongebruik natuurlijk.

[Reactie gewijzigd door watercoolertje op 13 juni 2025 11:18]

[Ruuddie]

PS ouders mogen kinderen ook gewoon opvoeden en beperken in hun telefoongebruik natuurlijk.

Dit is wel erg kort door de bocht. Je zou dan ook kunnen zeggen: "Gewoon sigaretten op display laten staan, fatsoenlijke ouders leren hun kinderen wel dat ze niet moeten roken"

Edit: ter verduidelijking, ik irriteer me ook mateloos aan die reclames die een half speelbare game geven. Zitten mijn kids een door mij goedgekeurd spel te spelen, spelen ze opeens heel iets anders. En dan gaan ze klagen als hun 'reclame rondje' in de game is afgelopen, en dat ze die game uit de reclame ook willen. Dit moet echt verboden worden!

[Reactie gewijzigd door Ruuddie op 13 juni 2025 12:04]

[GertMenkel]

In theorie kan dat als instant app worden aangeleverd maar volgens mij zijn dat vooral gewoon webbrowser-schermen die een game draaien. In mijn persoonlijke ervaring lijkt Pihole die troep redelijk goed weg te houden.

Instant apps zijn meer voor dingen als URL-handlers (denk aan een mini-NOS-app die opent als je een link van nos.nl aanklikt, of een Walibi-wachttijd-app die je met een klik kunt openen zodra je in de wachtrij staat). Die advertenties klik je over het algemeen nóg sneller weg, en de app-makers die de reclames erin stoppen willen natuurlijk ook niet dat je zomaar hun app verlaat.

Ik denk dat de grootste reden dat het concept mislukt is, inderdaad is dat app-makers willen dat je hun app op je telefoon laat staan. Voor gebruikers zou het superhandig zijn als deze feature overal gebruikt zou worden, maar als bedrijf kun je er geen geld mee verdienen, dus dan zullen weinig mensen er veel moeite in gaan stoppen.

[Reactie gewijzigd door GertMenkel op 13 juni 2025 10:06]

[PaulHelper]

Als ze de reclame 'nodig' hebben dan kan dit niet maar ik heb zeer veel succes gehad met custom DNS, dat kan je ofwel zelf doen met pihole praktijken of een andere custom dns.
Daarnaast, als je profiel correct ingesteld zin. Horen ze wel alleen kinder reclame te krijgen dacht ik maar, het kan natuurlijk een kinder geschikte interactieve reclame zijn.

[telenut]

Custom DNS op devices die gelocked zijn met Google familie. Zal eens moeten uitzoeken of ik makkelijk aan die instelling geraak.

[lasharor]

Instant apps was op zich wel een leuk concept. Vooral voor specifieke toepassingen waar je eigenlijk de app na gebruik niet meer wil behouden. Denk aan een app voor bij een museum of bijvoorbeeld de App die je gebruikt bij rondleidingen.

Ik heb nog altijd veel apps op mijn telefoon staan van musea voor zaken als extra informatie of de audiotour. Die apps gebruik ik na die eerste keer echt nooit meer.

[Macshack]

Maar zijn dit niet gewoon web apps? Kun je niet beter gewoon een website aanbieden waar bezoekers een bezoek kunnen starten etc.

Ik zou denk ik voor een museum geen app maken.

[PaulHelper]

Nee, vrij zeker van niet instant apps hebben/hadden meer mogelijke rechten en systeem toegang dan web apps. Al wordt de web systeem integratie wel steeds beter.

[Macshack]

Maar voor een museum zijn die rechten vaak niet belangrijk.

[lenwar]

Ik heb het altijd een vreemd iets gevonden. In theorie natuurlijk fantastisch, maar laten we eerlijk zijn. De primaire rede voor een bedrijf om een app te maken, is voor reclame en datamining. De app moet zo goed mogelijk en zo veel mogelijk zichtbaar zijn (zodat je sneller naar jouw app gaat dan die van je concurrent), en zoveel mogelijk data van het toestel af kunnen halen voor adverteringsdoeleinden.

Ofwel. Voor de appmakers is er weinig voordeel. Gezien de technologische beperkingen (maximaal 15MB groot e.d.) moeten die mini-apps ook nog is superefficiënt gecode worden. Dit is duurder dan een vracht derdepartijbibliotheken importeren (waar je 10% van nodig hebt als maker). Aangezien alle telefoons toch al gigantisch veel opslag hebben, en de gebruikers het blijkbaar accepteren dat apps idioot groot zijn voor wat ze doen (of het niet eens door hebben), hoeven ze daar dus geen rekening mee te houden.

En daarnaast hebben we ook nog de factor dat veel apps weinig meer zijn dan een schil om een website. Ofwel. Met een PWA kom je ook al een heel end en ben je platformonafhankelijk (theoretisch). (Al heeft dat minder voordeel voor de appmaker dan een reguliere app, omdat een PWA minder data kan minen dan een native app.)

[Joncik91]

Kerkhof comment Wie eerst

[418O2]

Ja stel je voor dat je stopt met iets dat geen tractie krijgt, of dingen probeert zonder garantie op succes.

[Blizz]

Of dat je er zelf niks mee doet, niet goed uitwerkt en het zoals bijna al je andere dingen een stille dood laat sterven…

[Ves]

Jammer, was handig voor apps die je 1x even moest/wilde gebruiken

[iOnoWLIt]

Ik kom App Clips van Apple ook zelden tegen dus ik vraag me af hoelang die ze gaan supporten.

[Ron79]

Ik had er nog nooit van gehoord. Maar misschien ligt dat aan mij.

[purplevendetta]

Als dat betekent dat NOS nieuwsberichten voortaan weer gewoon in de browser openen in plaats van in een app die ik niet geïnstalleerd heb, word ik er alleen maar blij van.

[hcQd]

Je hebt blijkbaar ooit een keer “ja” gezegd toen Chrome vroeg deze site in een instant-app te openen. Vroeger kreeg ik die vraag geregeld, en kijk je helaas ook niet uitzetten, maar heb hem aan een tijdje niet meer gezien.

Zoek in de instellingen van Android op “Google Play instant” en zet het uit. Helaas kun je nog steeds af en toe de vraag krijgen of je de link niet in een instant-app geopend wilt hebben.

[Reactie gewijzigd door hcQd op 13 juni 2025 14:10]