Programmeertaal Swift krijgt ondersteuning voor Android

Apples Swift-programmeertaal wordt ook gereedgemaakt voor Android. Binnen het Swift-project is een Android Working Group opgesteld die onder meer moet zorgen dat Android wordt ondersteund binnen het platform en dat bijvoorbeeld Swift op Android kan compileren.

Swift krijgt een eigen werkgroep die verantwoordelijk is voor het compatibel maken van de programmeertaal op Android. Swift is sinds 2014 Apples programmeertaal voor iOS-apps, terwijl Android standaard Kotlin gebruikt. Het is weliswaar mogelijk om in Swift ook Android-apps te bouwen, maar daarvoor zijn veel externe tools en library's nodig en de ondersteuning ervoor is minimaal. De werkgroep heeft als belangrijkste doel 'Android toevoegen en onderhouden als officieel ondersteund platform voor Swift'. Dat moet het in theorie voor Apple-ontwikkelaars veel makkelijker maken om Android-apps te maken.

De werkgroep gaat zich op meerdere taken richten. Naast het gereedmaken voor de officiële ondersteuning zodat er geen downstreampatches meer nodig zijn, gaat de werkgroep ervoor zorgen dat de belangrijkste Swift-packages ook Android-termen beter kunnen begrijpen. Apple noemt specifiek Foundation en Dispatch als twee van die packages. Verder gaat de groep kijken welke Android-api's officieel moeten worden geïntegreerd in Swift.

Ook moet de werkgroep gaan kijken hoe zij het beste Swift en de Java-sdk's in Android kan samenvoegen, of hoe zij Swift-library's in Android-apps kan zetten. Er moet tot slot ook ondersteuning komen om Swift-applicaties op Android te debuggen.

De werkgroep vraagt alle potentiële ontwikkelaars zich te mengen in het werk. Daarvoor wordt een onderdeel van het Swift-forum gebruikt bij de communicatie.

Apple bracht Swift in 2014 uit. In de afgelopen jaren voegde Apple al ondersteuning toe voor Windows en Linux, maar nog niet voor Android, dat meer een concurrent voor iOS is dan Windows en Linux dat zijn. Apple noemt geen specifieke reden waarom het Android ook wil gaan ondersteunen.

Update, 30-06 - In het artikel stond dat Kotlin specifiek voor Android is gemaakt, maar Kotlin is slechts door Android geadopteerd als standaardtaal.

Reacties (62)

[Cristan]

Ze moeten haast wel. Jetpack Compose (de standaard manier om voor Android te ontwikkelen) ondersteunt sinds mei iOS.

Software ontwikkelen is duur, en als je met een kleine moeite je Android app ook op iOS uit kan geven, zullen er best wat zijn die dat doen. Als dit de ene kant wel op kan en de andere kant op niet, gaat dit best een nadeel zijn voor Swift.

[ZakKa.dev]

Maar hoe goed werkt dat Jetpack Compose. Wordt dat wel gezien als een legitieme manier om iOS apps te bouwen? Oprecht benieuwd.

[josttie]

Hoe bedoel je legitiem? Je hebt native en cross platform apps. Native is native... logisch dat betekend voor Android dat je Kotlin schrijft (vroeger zou je java schrijven) en op ios schrijf je je apps tegenwoordig in Swift (vroeger in Objective C). Die native talen hebben als groot pluspint dat ze alle nieuwe APIs ondersteunen, maar je moet je apps wel dubbel schrijven.

Dan heb je andere oplossingen, zoals React Native, waar je in javascript een app moet bouwen en dan de native spullen op een omslachtige manier eraan vast moet lijmen. Dus dan de vraag: vind jij Facebook legitiem? Je hebt ook flutter, maar dan moet je Dart leren en zit je in een veel kleinere community.

Maar Kotlin multiplatform kan dus gewoon normale Android apps uitpoepen zonder restricties, en Kotlin is een taal wat naar meerdere platformen kan compileren, waaronder "Native" en daarmee dus een native iOs library kan uitpoepen welke je direct kunt aanroepen vanuit de rest van je iOS project. Hiermee kun je bijvoorbeeld je logica delen tussen apps zonder de performance penalty van andere platformen, en de UI native houden (SwiftUI en Jetpack Compose). Dan heb je dus native performance en klinkt als een legitieme app.

Sinds mei heb je ook Compose Multiplatform stabiel op iOS. Dat is dus native op Android, en behoorlijk performant op iOS, en kun je je hele UI delen. Je kunt ook SwiftUI elementen embedded als je het echt nodig hebt, dus het is vrij handig. Ikzelf vind dit de allerbeste oplossing: weinig tot geen concessies op Android, schrijven in een echte programmeertaal (en niet Javascript), gebacked door grote bedrijven met een hele stevige UI library, en de vrijheid om zelf te kiezen wat je wel native of multiplatform wilt hebben.

[ZakKa.dev]

Bedankt voor het uitgebreide antwoord. Met legitiem bedoelde ik of developers het serieus nemen als een goede manier om iOS apps te bouwen. Dus zonder, of weinig beperkingen vergeleken met andere methodes.

Wat meer context vanwege mijn interesse: Ik zit al lang te spelen met de gedachte om puur uit interesse een keer ook aan app-ontwikkeling te doen. Zelf alleen een JS/TS achtergrond.

[Reactie gewijzigd door ZakKa.dev op 29 juni 2025 14:24]

[josttie]

Het leuke als je kotlin kiest: ze hebben goede ondersteuning voor backends vanuit Jetbrains. Niet alleen de samenwerking met de makers van Spring, maar ze hebben ook nog Ktor en die is best makkelijk te implementeren. Dan kan je met Compose Multiplatform naast je mobiele apps, ook gelijk een desktop en webapp maken (met wasm, is nog in alpha maar je kan er al zeer goed mee rondspelen).

Met Swift heb je voornamelijk apple platform ondersteuning, de rest is meh (hobbyistenwerk). Dus even een backendje of een website in Swift schrijven zit er niet bij.

Daarnaast, met kotlin kun je uit de voeten met een windows of linux besturingssysteem, zolang je geen iOS wilt targeten. Ikzelf heb op mijn windows laptop 1 project met daarin de backend, alsmede voor de frontend android, web en desktop apps. Ik gok dat vanuit JS/TS Kotlin wellicht natuurlijker aanvoelt dan Swift (maar dat is alleen een gok). En zoals gezegd: het is makkelijker om dan ook gelijk een simpel backendje in elkaar te draaien.

[JoannisO]

Swift support ook backend development. Wij hebben ten slotte een Server Workgroup die hier volledig op focussed.

[Bolle117]

Dan zou ik expo.dev proberen, het framework voor react native met first class een support , zelfs een file based app router die je mss wel van nextjs of nuxt kent. Voor hobby projecten zou je hun expo application Services (EAS) kunnen gebruiken om iOS apps te builden, dan kan je het ook gewoon op een Windows ontwikkelen.

Veel apps zouden gewoon websites met CRUD functies moeten zijn. Heb je geen puur native performance voor nodig

[ZakKa.dev]

Collega's waren hier ook enthousiast over, ziet er goed uit. Op windows ontwikkelen is voor mij persoonlijk niet nodig.

[erikieperikie]

Dit is een zeer relevante vraag. Over Kotlin Multiplatform (KMP) weet ik dat het vaak vanuit Android naar iOS-ontwikkelaars wordt gebracht. Dat brengt natuurlijk de nodige vragen, kritische blikken en onbegrip met zich mee in grotere ontwikkelteams. Dat vereist een sterk staaltje verwachtingenmanagement en goede samenwerking. Echter, de technologie is er ook gewoon nog niet helemaal. Het werkt met haken en ogen. Hoe de Swift stack, tools en packages waarmee een iOS app wordt gebouwd werken versus hoe een Androidbuild in mekaar zit, is gewoon Apples met peren vergelijken. Het resultaat van een een KMP library kan bijvoorbeeld een onmogelijk te debuggen binary zijn die de hele Kotlin standard library bevat. Als de iOS app nog een tweede KMP lib wil gebruiken, dan is dat wederom zo'n dikke binary. Zo gaat het wel erg hard met de appgrootte, als je niet uitkijkt. Hier is wel een oplossing voor (umbrella module), maar hoe je die dan weer toepast is veel proberen met vallen en opstaan. En de schaalbaarheid hiervan is dan weer de vraag.

Voor je eigen projecten om mobiele ontwikkeling te leren en proberen, ook met een serieus doel, en met zowel Android als iOS als doel, is het perfect. Je leert vnl. 1 goede taal, Kotlin (en over enkele jaren dus mogelijk Swift) en je kunt hier helemaal mee uit de voeten.

De voornaamste reden dat deze technologie steeds vaker wordt gebruikt is omdat Kotlin echt een goede taal is, die wordt ontwikkeld en onderhouden door echt grote partijen en communities. En dat betekent dat problemen zoals de voorgenoemde vaak voor lief worden genomen, want er komen eigenlijk altijd (on)officiële oplossingen voor. Daarom ben ik ook blij dat Swift ook voor Android kan gaan werken: Swift is ouder en verder ontwikkeld dan Kotlin. Dat heeft voordelen. Nadeel is, maar dat kan veranderen, dat Swift eigenlijk geen server/web targets heeft, maar Kotlin wel. Met Kotlin zou je echt bijna elke hardware van software kunnen voorzien.

[Salvatron]

voor zover ik weet moet je wel een apple computer hebben om een app te maken voor apple

[JoannisO]

Dit is niet meer het geval. Dankzij diverse efforts kun je Swift gebruiken vanaf jouw Linux of Windows machine, en tegenwoordig zelfs (Free)BSD. Er zijn diverse editors naast Xcode beschikbaar, waaronder VSCode, nvim en emacs

[jj71]

Zo te zien gaat dit alleen maar over het gebruiken van de programmeertaal Swift om Android apps mee te bouwen.

Dat betekent niet dat je ook alle API's die je normaal gesproken op iOS zou gebruiken, en ook bijvoorbeeld SwiftUI voor het opbouwen van de user interface, nu ineens kunt gebruiken om Android apps mee te bouwen.

Dus je kunt nu niet even makkelijk je iOS app geschreven in Swift met SwiftUI en alle andere Apple frameworks gebruiken om even naar een Android app te compileren.

Ik neem aan dat om een Android app met Swift te schrijven, je nog steeds de API's van Android zult moeten aanroepen.

Dus wat betreft code schrijven is het dan wel makkelijker voor iemand die Swift kent, maar het wordt niet ineens heel simpel om apps te porten van iOS naar Android.

[JoannisO]

Dit klopt, wel zijn 80% van alle Linux packages al beschikbaar voor Android.

[brielsefie]

Android gebruikte origineel java als programmeer taal.
Kotlin is een door webbrains jetbrains ontwikkelde taal die meer en meer aanhangers kreeg en pas sinds 2017 in android ondersteund wordt.
Momenteel is kotlin de populairste taal voor android ontwikkeling, maar Kotlin is niet een "android eigen taal".

edit:

Webbrains vervangen door jetbrains zoals @Don Key terecht opmerkte

[Reactie gewijzigd door brielsefie op 29 juni 2025 11:06]

[SilentLucidity]

Kleine toevoeging: op Android compileert Kotlin ook gewoon naar Java Virtual Machine (JVM) code, net als Java.

[THETCR]

Doet Kotlin dat per definitie al niet? Het is toch bedoeld ter vervanging van de JDK vanwege Oracle hun beleid Er zijn genoeg bedrijven die Kotlin gebruiken om REST API's te bouwen.

[GertMenkel]

Kotlin wordt meestal naar JVM bytecode gecompileerd maarje kunt het ook naar directe machinecode compileren of bijvoorbeeld naar JavaScript en/of WebAssembly

Kotlin is geen vervanging van de JVM of JDK. Het werkt eerder samen met Oracle dan dat het de concurrentie aangaat.

[THETCR]

Jetbrains was er vrij duidelijk over dat ze het als alternatief wouden aanbieden vanwege de licentie praktijken van Oracle.


Overigen is het omzetten naar JavaScript of WebAssembly geen compileren maar transpileren.

[Don Key]

kleine correctie: Jetbrains (geen webbrains)

[brielsefie]

Inderdaad. zondag morgen... brains willen nog niet mee.

[SilentLucidity]

Een van de bekendere IDE's van Jetbrains is Webstorm... Misschien kwam de verwarring daar wel vandaan 😉

[MadEgg]

Precies, ik werk dagelijks in Kotlin maar doe niets met Android. Het is een alternatieve compiler voor de JVM waardoor je Java libraries zonder problemen kunt gebruiken maar wel heel veel syntactic sugar hebt van Kotlin die tot eenvoudigere code leidt.

[youri_ajax]

Kotlin is ook prima als “native” taal te gebruiken, wat uiteindelijk niks met de JVM te maken heeft.

[MadEgg]

Je hebt gelijkt, dat lees ik nu net. Heb je daar ervaring mee? Ben wel benieuwd hoe dat werkt dan, in alle Kotlin die ik tegenkom zitten Java libraries uitgebreid verwerkt, dat wordt lastig als je geen JVM hebt lijkt me?

[bzzzt]

Java code kan ook prima naar native code worden vertaald, met bijvoorbeeld GraalVM van Oracle zelf.

Daarmee win je opstarttijd en geheugen, maar je verliest de mogelijkheid dynamisch code te laden en genereren. Het verschilt per applicatie of die trade-off het waard is.

[MadEgg]

Ja, die ken ik uiteraard. Dat is vooral een optimalisatie. Je draait het dan niet in een JRE maar self contained. Maar dat maakt het wmb niet minder JVM.

[youri_ajax]

Ja maar hier word Kotlin NIET via java naar native code vertaald. Dat gebeurd zelf door de Kotlin compiler.

Kotlin native heeft dus niks met Java of verwante zaken te maken.

[youri_ajax]

Als je Kotlin "native" wilt gebruiken, kan je zo ver ik weet dus geen JVM libraries gebruiken.

Je hebt een web framework voor Kotlin, wat Ktor heet. Je hebt een ORM wat Exposed heet, volgensmij beide door Jetbrains ontwikkeld (wat ook Kotlin ontwikkeld natuurlijk).

Zelf heb ik niet super veel ervaring met Kotlin native, hier en daar een simpel API'tje mee opgezet en dat was het.

[Afgeleide]

“Apple noemt geen specifieke reden waarom het Android ook wil gaan ondersteunen.” Dit is niet per se een beslissing van Apple, de community van Swift gebruikers heeft ook invloed. Zie ook https://forums.swift.org/t/is-this-apple-initiative-or-community-initiative/80717.

Er bestaat ook een Swift voor Windows project, voornamelijk gepusht door The Browser Company (niet Apple) die de Arc browser schrijven in Swift.

[Blokker_1999]

Alleen heeft de community op zich geen invloed in de beslissingen die Apple neemt. Je kan niet zeggen dat omdat een deel van de community er al jaren om vraagt en ze het nu ineens gaan doen, dat dit simpelweg gebeurt op vraag van die community.

Er zal ongetwijfeld meer mee spelen wat Apple heeft doen beslissen om nu toch de mogelijkheid te gaan voorzien. Misschien zien ze dat de groei van iPhone aan het stoppen is wereldwijd en willen ze op deze manier hun marktaandeel op gebied van services verder laten groeien door het eenvoudiger te maken voor de eigen ontwikkelteams om voor Android te ontwikkelen.

[xFeverr]

Ik denk dat het anders ligt: ze willen heel graag dat je gewoon native apps maakt. In ieder geval voor iOS. Daar hadden ze het nog over bij de platform state of the union, dat native apps gewoon altijd beter werken.

Op deze manier kunnen ze weer een hindernis weghalen voor bedrijven die liever niet twee losse teams of apps maken voor twee platformen. En dan is het iOS in ieder geval native.

Dan moeten ze ook hun best doen om het goed op Android te laten werken. Want anders gebruikt niemand het.

[Lord Anubis]

Apple heeft een vinger in de pap, maar iedereen mag swift overzetten naar een andere omgeving en Apple bemoeit zich daar niet mee.


Er zijn , helaas enkele doodgebloede, projecten aanwezig. Het is wel mooi dat Apple zeer actief en positief zich er mee bezig houd en met sommige side projecten. Iedereen kan meeliften met Apples inbreng maar terzijde zijn er libraries die te specifiek zijn voor de Apple OS’sen en niet open zijn of ooit zullen worden. De taal zelf is 100% vrij te gebruiken.

[JoannisO]

Apple heeft deze beslissing niet gemaakt, dit is een community effort. Ik heb dat initiatief opgezet, in het begin met Marc van skip.tools en Finagolfin die de meest gebruikte Swift for Android SDK maakt. Apple zit ook in de workgroup, en helpt zeker mee. Maar dit is geen Apple effort.

[camper69]

Apple heeft de centen om het voor elkaar te kunnen krijgen. Best subjectief, maar ik denk dat een meerderheid van de ontwikkelaars echt liever met Kotlin werkt dan met Swift.

[Mavamaarten]

De reactie onder collega's hier was universeel: oei waarom zou je dat willen? Wij beginnen hier en daar KMP (Kotlin Multiplatform) te gebruiken en de iOS devs zijn over het algemeen zelfs stiekem fan van Kotlin. Niet per se omdat ze daar veel liever mee willen werken, maar omdat Swift wel wat quirks heeft.

[- peter -]

Ik begrijp wel dat KMP met Objective C bridged ipv Swift. Dit kan misschien ook bruikbaar zijn voor Kotlin daarmee, dat t wel interopt met Swift. Ook voor zaken zoals structured concurrency loop je volgens mij nu tegen beperkingen aan. Ben benieuwd.

[jacobras]

Voor nu inderdaad naar Objective-C (wel met annotaties voor betere interop met Swift, versterkt door tooling als SKIE van TouchLab), maar direct Swift export is in preview (nog gelimiteerde functionaliteit) en krijgt binnen afzienbare tijd een eerste publieke release (zie roadmap https://kotlinlang.org/docs/roadmap.html)

[readefries]

Oh, da's wel nice! Ben benieuwd hoe dat uitpakt, ik vond ontwikkelen voor iOS in Swift erg fijn! En een verademing t.o.v. Objective-C, maar kon me nooit echt thuisvinden in het ontwikkelen op Android. Ook al vind ik dat platform veel fijner.

[DarkBlaze]

ik heb dat juist andersom, jaren een PWA/mobile app op basis van ionic onderhouden voor mijn hudige werkgever maar alles wat ook maar iets met xcode deed was was om te janken zo slecht.

[readefries]

Hahaha, snap helemaal dat je xcode k vind. Al moet ik zeggen dat het wel beter is geworden. Je zou Appcode van Jetbrains kunnen proberen, dat is een stuk fijner. Visutal Studio code kun je ook prima inrichten om Swift app te ontwikkelen.

Ik doelde meer op de taal ansich, hoet het b.v. met optionals omgaat, nested types en generics. Of hoe je met enums en return types nette fout afhandeling kan maken in asynchroniteit. Deze mis ik b.v. in C#

[xFeverr]

AppCode is dood sinds 2,5 jaar.

[readefries]

Haha, o echt. Dat is jammer. Was een fijne tool.

[Lord Anubis]

Dat ligt dan aan XCode. Je kan ook de terminal gebruiken of tegenwoordig AI 😜

[svenk91]

Apple bracht Swift in 2014 uit. In de afgelopen jaren voegde Apple al ondersteuning toe voor Windows en Linux, maar nog niet voor Android, dat meer een concurrent voor iOS is dan Windows en Linux dat zijn.

Niet voor iOS, maar wel voor MacOS waar Swift ook wel een prominente plek heeft (zij het minder dan op iOS en afgeleiden als iPadOS).

Als iemand die alleen hobbymatig wat programmeert vond ik Swift altijd een fijne taal, maar werd altijd erg beperkt doordat alles vooral op het Apple ecosysteem is toegespitst ondanks dat het op papier open is. Ik ben bang dat het nu too little too late is.

[readefries]

Swift is vanaf het begin zowel voor iOS als macOS geweest en waar het nu toch al jaren de standaard is i.p.v. Objective-C.

[svenk91]

Klopt idd, maar naar mijn beeld (die misschien totaal niet klopt) is Swift een stuk prominenter op iOS. Waar in iOS veel apps van de grond af met Swift zijn gemaakt zie je op MacOS dat meer apps in een andere taal zijn gemaakt. Op de desktop zie je toch meer multi-platform codebases (voor Windows, Linux en Mac) maar alleen maar de schil eventueel wat Swift gebruikt.

[readefries]

Ah zo bedoel je. Op iOS heb je ook veel mogelijkheden om het zonder swift te doen, maar je merkt het daar wel meteen in de apps is mijn ervaring. Zowel bij PWA als Xamarin Native/Maui. Ik vind dat Flutter apps nog het beste aanvoelen.

Op macOS heb ik dit gevoel minder, doordat je een muis en toetsenbord gebruikt voor interactie dat is wat indirecter en in mijn belevind daardoor wat minder gevoelig voor het raar of onnatuurlijk overkomen van apps. Nu ik dit type bedenk ik me, dat ik bij macOS apps soms ook kritisch was maar dat het daar steeds beter wordt. Als ik kijk naar hoe fijn ik Visual Studio Code vind en vind aanvullen in een TypeScript applicatie (ja ik ben biased)

[PrimusIP]

idem. Ik ook hobbymatig in verleden. Ik vind het ook best een fijne taal. Het heeft iets van de simpelheid van Python maar dan wat efficiënter qua geheugen.

Daarentegen vind ik xcode een ramp. Het is zwaar en Apple heeft er een handje van de boel overhoop te gooien, terwijl de nieuwe manier vervolgens nog verre van compleet is.

[Exodai]

Op wat voor manier is Xcode een ramp dan? Draai hier Xcode 26 Beta en bevalt goed hoor. Vooral de laatste paar jaar is Xcode best goed te gebruiken. Doet echt niet onder aan andere IDE's

[PrimusIP]

- Apple komt aanzetten met Swift UI maar zeker de eerste jaren was het knap gebrekkig. Maar ze pushen het ondanks dat wel sterk. Het idee is best fijn trouwens, maar zo enorm beperkt.

- Het is best een enorm zwaar programma qua ram, processor kracht en helemaal qua data opslag. Als ik een professional zou zijn (wat ik niet ben) zou ik niet in xcode willen zitten wanneer ik niet iets met de GUI aan het doen ben of aan het testen ben.

[Exodai]

- Apple komt aanzetten met Swift UI maar zeker de eerste jaren was het knap gebrekkig. Maar ze pushen het ondanks dat wel sterk. Het idee is best fijn trouwens, maar zo enorm beperkt.

Maar dit heeft dus niks met Xcode te maken. Maar met Apple en hun keuzes. Maar Xcode werkt ook gewoon zonder SwiftUI of de bijkomende rottigheid.

- Het is best een enorm zwaar programma qua ram, processor kracht en helemaal qua data opslag. Als ik een professional zou zijn (wat ik niet ben) zou ik niet in xcode willen zitten wanneer ik niet iets met de GUI aan het doen ben of aan het testen ben.

Ik ben een "professional" en ik heb echt nergens last van. Zelfs de huidige Beta van Xcode 26 gebruikt op het moment van schrijven 1 GB hier in een Vapor applicatie. En CPU 0,5%. En ik ben al heel de dag aan het werk.

Het enige dat best veel RAM kan gebruiken is dedicated tooling maar Xcode als IDE zelf valt echt reuze mee.

[JoannisO]

Steeds meer van Apple's frameworks, ook die in iOS zitten, worden in het open ontwikkeld. Distributed actors bij voorbeeld, poweren veel interne tools binnen Apple's OSes en cloud diensten. Idem ditto met diverse andere opensource tools.

[ZakKa.dev]

Er zijn zoveel manieren om vanuit 1 codebase voor meerdere platforms te ontwikkelen. React native, xamarin. Kotlin Multiplatform, flutter. Nu hebben we er nog een bij, benieuwd naar de ontwikkeling.

[JoannisO]

Ik denk dat je Swift nog het meeste als tegenhanger van Kotlin Multiplatform moet zien. Met als grootste verschil; het is één ecosysteem. Kotlin is een taal, twee ecosystemen. Dat maakt het moeilijk om jouw JVM libraries mee te nemen.

[ZakKa.dev]

Ah dat is wel een belangrijke nuance die ik inderdaad over het hoofd zag. Ik ben inmiddels begonnen aan het leren van React Native, ben benieuwd.

[Exodai]

Op zich best cool. Ik gebruik zelf Swift voor Apple development en bouw er sinds een jaar of 4 ook al mn APIs en backends mee door het serverside swift framework Vapor
https://vapor.codes

[Reactie gewijzigd door Exodai op 29 juni 2025 12:35]

[JoannisO]

Gaaf! Zit je ook in de Vapor discord?

[Exodai]

Paar jaar geleden wel maar niet meer. Geen behoefte aan eigenlijk.

[Salvatron]

ik ken dat hele swift niet

[mutley69]

Welke garanties biedt dit op lange termijn? Apple kennende: Geen. Google kennende: Geen.

Fijn om lezen, we wachten wel af.