JetBrains brengt alfaversie van Kotlin Multiplatform Mobile uit

JetBrains heeft de alfaversie van de Kotlin Multiplatform Mobile-sdk uitgebracht. De tools en functies van de sdk moeten het makkelijk maken om op basis van dezelfde code zowel Android- als iOS-apps te maken.

Kotlin Multiplatform Mobile stelt ontwikkelaars in staat een enkele codebase te hanteren en alleen platformspecifieke code te gebruiken waar het nodig is, zoals voor de gebruikersinterface van Android of iOS of voor platformspecifieke api's.

De alfaversie van Kotlin Multiplatform Mobile of KMM bevat onder andere een plugin voor Android Studio waarmee ontwikkelaars in Kotlin geschreven gedeelde code kunnen schrijven, draaien en debuggen, zonder dat ze hoeven te wisselen van integrated development environment. De KMM-plugin is via de Marketplace in de software te downloaden.

KMM is volgens JetBrains makkelijk te integreren in bestaande projecten voor mobiele apps, mede dankzij de wizard, en voor iOS-development verwijzen de makers bijvoorbeeld naar de interoperabiliteit van Kotlin met Objective-C en Swift en de integratie van de dependency manager van CocoaPods.

Wanneer de bèta- en stable-release volgen is niet bekend. JetBrains roept ontwikkelaars op feedback te geven op de alfarelease.

Reacties (64)

[jimshatt]

Erg interessant! Als web developer heb ik altijd al eens met mobile willen spelen, maar om voor beide platformen te ontwikkelen was Xamarin de enige optie (voor zover ik weet). Meer keuze is altijd beter.

[Aaargh!]

om voor beide platformen te ontwikkelen was Xamarin de enige optie

De beste optie blijft altijd nog om 2 native apps te ontwikkelen. Al die cross-platform tools geven toch een sub-optimale UX.

[WoutervOorschot]

Xamarin geeft een mooie crossplatform UX hoor, die gebruikt native elementen dus zie je niks van. Alle web-naar-app platformen zijn haast allemaal suboptimaal inderdaad, vooral in de details.

Enige wat je kunt doen is bijv op iOS tabbladen geven en op android een hamburgermenu (of de keuze geven).

[armageddon_2k1]

Klopt, maar het mooie van Kotlin Multiplatform is dat je ook kan besluiten 1 common library te maken waar je alles afhandelt afgezien van de UI. Je native code voor de apps kan die common library dan gewoon aanroepen.

[MiesvanderLippe]

Ja als je een app voor bij een website maakt zit de logica toch al centraal. Dan heb je vooral platform specifieke code.

[elmuerte]

Helemaal correct. Het gaat niet er om dat de mobile applicatie dezelfde UX heeft op verschillende platformen. Het gaat er om dat de mobile applicaties dezelfde UX heeft als de andere applicaties op dat platform.

[xFeverr]

Ligt er aan. Je kan ook gewoon UIKit op iOS en de platformlibraries gebruiken op Android in een Xamarin-project. Dan is de UX gewoon 100% native (en dus niet multiplatform).

[NLkaiser]

Maar nog zul je met kotlin multi platform de ui platform specifiek moeten maken. Misschien is flutter meer iets voor jou https://flutter.dev

[Ed Vertijsment]

Keuze zat hoor, zoals Ionic (web) of React-Native (JS(X)/Native).

[supersnathan94]

,maar dat is dan dus ook niets anders dan web. Daarmee mis je dus een hele hoop platform specifieke zaken die wel belangrijk kunnen zijn. Voor apps a la webshop of thuisbezorgd niet zo erg, voor wat heavy duty performance dingen (foto/film bewerking) wel.

[cornedor]

React native wordt wel met JavaScript ontwikkeld, maar rendering e.d. wordt daadwerkelijk met native API's gedaan. Ook zijn heel veel platform specifieke API's beschikbaar, en dit kan worden uitgebreid door extra extensions te maken.

[supersnathan94]

Ja klopt je kunt inderdaad native API’s aanspreken (vandaar het native deel in react native), maar! React native werkt met bindings op native UI elements die het aanpast naar jouw custom styling. Dit zorgt er bijvoorbeeld voor dat gedrag per platform anders kan zijn (omdat de native ui element ander gedrag heeft), maar zorgt er ook voor dat er best wel veel performance blijft liggen doordat er eigenlijk geen custom element wordt gemaakt, maar een restyle van een native element. Zo zijn er nog wat meer dingen.


Daarnaast heeft react native geen multithreading support en geen parallel processing dus is het lastig complexere dingen uit te voeren javascript draait immers maar single threads. Async await is dan ook de enige manier om api calls te doen zonder continu tegen deadlocks aan te lopen en dat is gewoon een perfomance hell.

[coen254]

Je kan in React Native gewoon combineren met native code als je iets nodig hebt dat mist in RN zelf.

[supersnathan94]

Maar dan ben je dus weer platform specifiek bezig en heb je alle hassle van meerde disciplines weer terug waardoor je weer beter native kunt gaan (omdat je dan niet nog een ander discipline hebt. Je ziet grote bedrijven als AirBNB dan ook weer overstappen naar dergelijke oplossingen (zoals Felgo). Je hebt namelijk anders alsnog native developers nodig. Leuk leesvoer daarover:

https://www.simform.com/r...itations-app-development/

https://felgo.com/cross-p...t-react-native-comparison

Uiteindelijk is het weer yet another platform. In frontend land zie je dat er om de zoveel tijd weer een nieuwe contender is die weer het meest populair is.

[coen254]

Je hebt dan inderdaad nog wel native devs nodig, maar minder. Ook heb je alsnog gewoon een codebase voor beide apps.

[supersnathan94]

Exact en dat kan dus juist ook met frameworks zoal felgo en wat Jetbrains hier nu presenteert, maar dan beter (want anders zou het niet "the next best thing" zijn).

[Ed Vertijsment]

O zeker, ik zeg enkel dat er wel meerdere tools zijn.

[Martinspire]

Voor heavy performance zou ik sowieso geen library pakken maar gewoon native gaan werken voor het web in WebGL. En dat is eigenlijk weer een eigen tak van sport

[supersnathan94]

Tsja en dan zit je met de vierde discipline in je stack waarbij android en iOS ook nog eens anders met webGL omgaan. Safari ondersteund bijvoorbeeld niet alles en als je veel RAM gaat gebruiken wordt JIT compiling kennelijk uitgeschakeld. WebGL is niet per se heel handig op mobile devices. SO staat vol met vrij specifieke compatibility issues

[Martinspire]

Wellicht, maar het is wel de beste cross-platform manier om een technische en zware applicatie te gebruiken via mobiel en desktop op een enkele codebase. De meeste zaken die je van Android of IOS wilt gebruiken, kun je inmiddels ook wel via het web doen. Dan hoef je niet eens een app te compileren en in de store te zetten (wat duur en omslachtig is), maar gewoon een enkele website bij te houden.

Als je platform specifieke zaken moet doen, heb je sowieso de kennis van android en ios nodig, maar er zijn niet zo heel veel zaken die je anders niet kunt doen (en welke de privacy van je gebruikers niet te grabbel gooien). Daarbij hoef je ook niet al te veel de native UI te verwerken, want mensen verwachten op het web toch wel wat anders met een eigen design. Scheelt je dat ook meteen weer in 3-voud te moeten oplossen.

[Reactie gewijzigd door Martinspire op 23 juli 2024 11:58]

[supersnathan94]

Nee dat is het dus niet, dat probeer ik dus aan te geven. De Ondersteuning van webGL op iOS bijvoorbeeld is niet echt fantastisch en als je echt veel RAM gaat gebruiken stopt de boel letterlijk met werken.

Daarbij hoef je ook niet al te veel de native UI te verwerken, want mensen verwachten op het web toch wel wat anders met een eigen design.

Volgens mij snap je dan niet helemaal hoe react native werkt. Die bind jouw custom UI namelijk op de native UI elements die het OS je bied. Onderwater zijn het wel native knoppen.

[Martinspire]

Dat het voor jouw project niet lekker werkte, is jammer maar betekent niet dat het voor iedereen dan niet geschikt is. Ik heb 2 projecten gedaan in het verleden met WebGL (waar een specifieke programmeur voor was om dat deel te doen) en de performance was juist erg indrukwekkend. Maar goed, dan heb je ook iemand in dienst die weet wat ie doet en draait het mooie 60fps.

Als je vele gigabytes aan RAM nodig hebt voor je applicatie dan zit er wellicht wel meer fout, waarbij het dan niet meer uitmaakt welke techniek je gebruikt, want het is dan sowieso traag.

En leuk dat de button dan onderwater OS is, veel websites doen hetzelfde met bv checkboxes. Dat doet niets af aan het feit dat je gewoon 1 design hebt. Daarmee is dus je teststraat een stuk simpeler. Voor de gebruiker maakt het dus weinig uit, want diens verwachting is al wat anders en qua onderhoud hoef je dus ook minder te doen (omdat je geen apps hoeft te publiceren).

[supersnathan94]

Ik heb het niet over mijn project ik heb het over de algehele support in de browser zelf.

en de performance was juist erg indrukwekkend

ja want de "lastige dingen" worden door safari niet ondersteund. Als ze niet een beepaald niveau van performance kunnen geven doen ze het er gewoon helemaal niet in. Je bent daardoor heel snel beperkt in welke opties je hebt.

Als je vele gigabytes aan RAM nodig hebt voor je applicatie dan zit er wellicht wel meer fout, waarbij het dan niet meer uitmaakt welke techniek je gebruikt, want het is dan sowieso traag.

Bij vele gigabytes op webapp wordt je gewoon direct gekicked dus dat hoef je niet eens te proberen. WebGL kan op iOS nooit enkele GB's verbruiken. Browsertabbladen mogen daar niet eens bij in de buurt komen.

Dat doet niets af aan het feit dat je gewoon 1 design hebt. Daarmee is dus je teststraat een stuk simpeler. Voor de gebruiker maakt het dus weinig uit, want diens verwachting is al wat anders

Nee want het gedrag van die knoppen is dus anders afhankelijk van het OS.

en qua onderhoud hoef je dus ook minder te doen (omdat je geen apps hoeft te publiceren).

Als je geen app publiceert mis je dus bepaald belangrijke features. Dingen die tweakers ook niet heeft, zoals pushnotificaties. als je dat niet gebruikt cw niet erg vind dan is dat prima, maar voor een site met nieuws is het ontzettend dom om dat niet mogelijk te maken. Zeker gezien het aantal notificaties wat ik op een dag binnenkrijg zou push notificatie weer heel handig zijn. Maarja, web only.


Daarnaast moet je net zo goed gewoon een build straat hebben en dat onderhouden dus dat is gewoon onzin.

[Reactie gewijzigd door supersnathan94 op 23 juli 2024 11:58]

[Martinspire]

Nogmaals, als je vele gigabytes aan het gebruiken bent voor je "app" dan moet je toch eens nadenken wat je aan het doen bent, want daar is zo'n apparaat gewoon niet voor geschikt. Juist bij web kun je zaken wel of niet tonen en het meeste werk bij een server leggen ipv de client. Dan heb je gewoon je applicatie architectuur verkeerd staan want het is niet goed afgesteld tot je clients.

Web knoppen zijn gewoon anders dan native, maar dat doet niets af aan de functionaliteit. Het ding is alleen dat het op elke browser gewoon hetzelfde werkt, zeker nu alles Chromium aan het worden is, waardoor de overige verschillen minimaal zijn. Als je anno 2020 nog steeds last hebt van browser issues (bv doordat je oude meuk wilt blijven ondersteunen), dan is dat echt je eigen schuld.

Verder ben ik benieuwd wat voor belangrijke features je mist als je iets op het web gaat doen ipv native apps, dan zit je gewoon met hele exotische zaken te werken waarvan het al duidelijk was dat je dat niet met web ging bereiken en waarbij ook al wel duidelijk was dat een cross-platform oplossing sowieso ondermaats ging presteren. Push notificaties kan tegenwoordig ook gewoon via het web op Android. Dat iOS het niet ondersteund is natuurlijk een dingetje van Apple, maar via een simpele hybrid app zou je dat ook zo kunnen inbouwen. Ding is alleen dat niemand die dingen accepteert, maar het kan wel gewoon. Tweakers zou dat ook kunnen toevoegen, maar volgens mij weten ze dat niemand zit te wachten op dergelijke popups.

En dat je een build straat nodig hebt, lijkt me logisch maar als je ook nog eens applicaties moet compilen, door de acceptatie van Apple en Google heen moet, dan is het uitrollen van nieuwe features gewoon een stuk langzamer dan 1 keer op de knop drukken voor een nieuwe website. Als je met apps zit, dan moet je toch altijd wachten tot dat hele proces gedaan is, voordat je alles kunt publiceren.

Je hoeft mij niet uit te leggen dat Apple lastig doet en liever geen webapps op diens platform wil, omdat ze er niks aan kunnen verdienen of hoe Safari de nieuwe Internet Explorer aan het worden is. Maar feit blijft dat voor veel bedrijven publiceren voor web gewoon een stuk makkelijker is dan te gaan lopen kloten met apps. Als je wat unieke applicaties hebt waarbij je vele gigabytes aan data moet verwerken aan de client-side (dat zijn er echt maar heel weinig) of hele aparte device API's wilt aanroepen, ja dan is een app gewoon makkelijker, maar dan ga je niet lopen kloten met cross-platform programmeren, dan doe je het gewoon per platform specifiek. Ook in 2020 zijn apps overrated. Ik heb de afgelopen jaren met wat indrukwekkende webapps gewerkt en de performance die je kunt behalen met veel data is gewoon prima. Als dat niet goed werkt, dan ligt het veelal aan de achterliggende architectuur of opzet van de toepassing. Het web als platform de schuld geven is altijd erg makkelijk, maar zo kun je op elk platform wel klagen over performancelimitaties.

[Reactie gewijzigd door Martinspire op 23 juli 2024 11:58]

[supersnathan94]

Nogmaals, als je vele gigabytes aan het gebruiken bent voor je "app" dan moet je toch eens nadenken wat je aan het doen bent, want daar is zo'n apparaat gewoon niet voor geschikt. Juist bij web kun je zaken wel of niet tonen en het meeste werk bij een server leggen ipv de client. Dan heb je gewoon je applicatie architectuur verkeerd staan want het is niet goed afgesteld tot je clients.

We hebben het hier ook helemaal niet over gigabytes. Te veel ram is niet gelijk het maximum aan ram wat het apparaat heeft. Nee dat wordt voor een specifieke applicatie gewoon bepaald.

Juist bij web kun je zaken wel of niet tonen en het meeste werk bij een server leggen ipv de client. Dan heb je gewoon je applicatie architectuur verkeerd staan want het is niet goed afgesteld tot je clients.

Dat ligt er dus aan wat voor App je hebt. Again voor simpel data tonen zit de frontend logica volledig in de client, en dat is niet erg, want daar hebn je performance en resources zat voor. iPhones zijn behoorlijk snel mbt javascript performance dus dat is het probleem niet.

En dat je een build straat nodig hebt, lijkt me logisch maar als je ook nog eens applicaties moet compilen, door de acceptatie van Apple en Google heen moet, dan is het uitrollen van nieuwe features gewoon een stuk langzamer dan 1 keer op de knop drukken voor een nieuwe website. Als je met apps zit, dan moet je toch altijd wachten tot dat hele proces gedaan is, voordat je alles kunt publiceren.

Ja tuurlijk, maar dat heeft toch niks met "meer onderhoud" te maken? Je doorloop tijd is alleen wat hoger. compileren duurt echt geen uren meer hoor. Overigens is acceptatie testen d.m.v. testflight wel een van de dingen die goed is uitgewerkt en daar hoef je dan niet je gebruikers mee op te zadelen die echt live bezig zijn.

Als je wat unieke applicaties hebt waarbij je vele gigabytes aan data moet verwerken aan de client-side (dat zijn er echt maar heel weinig) of hele aparte device API's wilt aanroepen, ja dan is een app gewoon makkelijker, maar dan ga je niet lopen kloten met cross-platform programmeren, dan doe je het gewoon per platform specifiek.

En dat was precies mijn punt 5 posts geleden. Ieder platform heeft zo zijn voor en nadelen en sommigen kunnen daar mee leven en anderen niet en die zoeken dan een ander platform.

[Wafje]

Flutter is een populair alternatief.

[vgroenewold]

Ja, is dat niet zo'n beetje DE tool om cross platform voor iOS en Android te programmeren? Ik zit er al een tijdje naar te kijken. Ik zou zelf alleen Kotlin liever gebruiken als taal, omdat het redelijk lijkt op Swift.

[Boy]

Flutter heeft enorme tractie en community gekregen idd! En ik heb al een paar apps ontwikkeld erin. Werkt erg fijn! Dart is ook prima hoor, Kotlin is inderdaad fijner (ik ben Android dev van oorsprong).

Maar KMM gaat volgens mij ook groot worden en dat wil ik ook graag gaan uitproberen.
Ik denk dat ik in toekomst per project ga beslissen of ik KMM of Flutter ga doen / aanraden.

[vgroenewold]

Nice. Ja, dat was de reden dat ik Flutter wilde gaan leren. Maar nu twijfel ik weer. Dart wordt niet echt veel gebruikt buiten Flutter heb ik het idee.

[Boy]

Flutter is in ieder geval erg leuk om te leren, hot reload maakt het ontwikkelen supersnel en het declaratief opzetten van UI is echt goed!

Krachtig qua animaties, ik raad het je wel aan om eens te gaan spelen ermee

[vgroenewold]

Check, ga ik doen dan. Wat voor mij in deze wat onduidelijk is (en dat zal altijd wel zijn als je nieuwe talen aanleert) of Kotlin niet een grotere toekomst tegemoet gaat. Dus, gezien het voor mij een investering is in deze, zou Kotlin samen met KMM dan niet verstandiger zijn...

[Boy]

Misschien wel...je moet dan wel wat meer in Android dev gaan kijken hoe dat werkt, wat de UI moet je in Android zelf doen.

Ik heb dat "probleem" ook met KMM, ik moet iOS dev gaan ontdekken om daarmee aan de slag te kunnen

[vgroenewold]

Klopt ja, dat is weer iets meer een nadeel ten opzichte van Flutter. Daar heb je dacht ik veel meer een gedeelde UI die je kan testen op een Android simulator. Ik heb inmiddels geen moderne Mac meer, dus dat wordt ook lastiger, een Mac server huren misschien dan... beetje kostbaar alleen als je nog niet verdient met ontwikkelen.

[Boy]

Of een tweedehands Mac mini.

[coen254]

React Native is een erg populaire en volwassen optie. Javascript (vooral Typescript) is ook super populair en veelgebruikt. Als je eerder webapplicaties ontwikkeld hebt is het een eitje om te beginnen met react native en Expo.

[MacD]

Het probleem voor mij met Flutter is Dart.

Het is een vieze programeertaal die je gek maakt met ge-neste braces. Bah.

Het lullige is dat Flutter, als Google een maand of twee had gewacht, ipv Dart met Kotlin had kunnen werken ... maar de afdeling binnen Google was drangerig en wilde voortgang ... en dus kozen ze Dart.

Gemiste kans.

[Boy]

Ow, heb je daar een bron van? Dat is wel erg interessant!

[MacD]

Niet een officiele die je kan linken ofzo. Heb het wel van Flutter experts die met het Flutter team spraken tijdens I/O.

But I'm just a guy on the internet, natuurlijk.

En ik kan niet teveel in het openbaar zeggen, vind ik ... als je het echt belangrijk vind, DM maar

[supermidget]

Ben zelf ook enthusiast over Flutter, omdat ze ook werken aan support voor web + desktop. Web werkt al redelijk goed, desktop is nog in Alpha, maar als het eenmaal zover is kun je eindelijk alles bouwen met 1 framework.

[YopY]

Denk dat "de" tool van het moment React Native is, maar Flutter wint snel aan invloed. Het is ook (helaas?) een van de weinige praktische toepassingen van de Dart programmeertaal.

[vgroenewold]

Ja dat idee had ik al. Dan verwacht ik eigenlijk dat Flutter met name veel gebruikt wordt in het bedrijfsleven (whatever works als het maar snel kan ). Maar om nu Dart te leren als nieuwe taal alleen maar voor Flutter vind ik niet heel interessant. Ik heb toch besloten op Kotlin over te gaan, daar lijken meer toepassingen voor te zijn inmiddels.

[mrcreatech]

Als web developer is Cordova dan misschien een makkelijke eerste stap richting mobile. Die wrapt je website simpelweg en roept de specifieke device APIs aan waar nodig. Dan zit je ook niet vast met een bepaald framework, waarbij je dat bij een React Native of Vue Native natuurlijk wel hebt.

[ApolloDrm]

Met Cordova/Phonegap heb ik ook goede ervaringen.

Misschien interessant - ik gebruik nu al een paar jaren als bovenliggende omgeving Monaca (www.monaca.io) voor mijn cross-platform app ontwikkeling, dat is gebaseerd op Cordova/Phonegap, en je kan er "vanilla" in bouwen of projecten met React / Angular / Vue / etc.

Het is een omgeving die ook een IDE biedt, je kan in hun IDE (web applicatie) bouwen of zelf lokaal. Je kan je project ook builden in hun omgeving, en via handige tools (deploygate.com bijvoorbeeld) testbuilds publishen naar je Android/Apple device. Als je de juiste keys etc instelt dan kan je ook rechtstreeks publishen naar de app store.

In de basis is het gratis, wil je meer features (meer dan 3x per dag builden, custom cordova plugins) dan moet je betalen.

[Bartmanz]

Ik heb een tijdje met Monaca lopen stoeien maar heb de toegevoegde waarde niet echt kunnen vinden (de gratis variant) tegenover lokaal ontwikkelen.
De beperkingen in plug-ins waren voor mij de reden om weer lokaal verder te gaan.

[Martinspire]

Helaas gaat het met cordova/phonegap niet zo best. Phonegap Build gaat er bijvoorbeeld mee stoppen (om makkelijk je app te compilen en in de store te zetten). Ionic gaat daar wel mee verder, maar die zijn imo vrij prijzig voor hobbyprojecten. Daarnaast gaat de ontwikkeling van Cordova/Phonegap niet zo hard en zijn de tools imo wat verouderd. Ionic doet dat veel beter, maar zoals gezegd betaal je daar ook wel voor.

De vraag is overigens wel: moet je een app nog wel willen, websites werken nog gewoon prima voor menig doel en er zijn steeds meer API's voor het web beschikbaar. Je ziet steeds meer gebruikers apps verwijderen. Tweakers heeft ook geen app meer bijvoorbeeld. En voor veel diensten hoeft het ook helemaal niet.

Ikzelf ook, ben een tijd geleden de lijst met geïnstalleerde apps eens doorgelopen en verwijderd wat ik niet meer gebruikt had in de laatste jaren of waarvan je de dienst prima via web kunt benaderen. Blijft er nog maar weinig over. En dan draait er ook minder op de achtergrond, waardoor je batterij een stuk langer mee gaat.

[Reactie gewijzigd door Martinspire op 23 juli 2024 11:58]

[TheKingOfHoney]

Als web developer heb ik altijd al eens met mobile willen spelen

Je zou dan ook eens kunnen kijken naar Expo. Het is een laag bovenop React Native. Verder is Flutter ook een optie.

[diondokter]

Ah, dit is dus een soort xamarin alternatief, maar dan in kotlin en met de jvm? Al dacht ik ook een keer meegekregen te hebben dat ze bezig waren met native kotlin waarbij dan geen jvm zit. Is het voor iOS gebaseerd op dat?

[josttie]

Nee. Kotlin is een programmeertaal dat veelal op de JVM draait, maar ook naar native en javascript compileert. Dus de grap is dus dat met Kotlin multiplatform (wat al langer bestaat, maar ik heb geen idee wat er anders aan is dan kotlin multiplatform mobile) je heel veel code kunt delen en alleen de platform specifieke delen platform afhankelijk maakt, maar je kunt die alsnog veelal in Kotlin schrijven.

Bijvoorbeeld: Ik maak een Android app en een React web applicatie. Dan schrijf je alle logica in een common sourceset, en dan heb je een Android sourceset en een javascript source set.
De Android UI schrijf je met behulp van bijvoorbeel Jetpack Compose en het web gedeelte schrijf je ook in Kotlin met React. De gecompileerde projecten zijn puur gecompileert voor de platformen en je hebt dus toegang tot alle apis op elk platform, ZONDER een laag ertussen.

En dat is het verschil tussen hybrid frameworks, die hebben vaak 1 enkele codebase voor zo ongeveer alles, dus ook voor de UI. Die UI is dus een eenheidsworst geschreven met alle limieten van het hybriede framework. Alles wat dan alsnog platform specifiek is zit er een of andere javascript laag tussen wat performance bottlenecks geeft.

[josttie]

Type het anders even uit, want ik snap je botte reactie werkelijkwaar niet. Wellicht heb ik de verkeerde term gebruikt, Kotlin "transpileert" naar Javascript (volgens https://kotlinlang.org/docs/reference/js-overview.html ). Dus mijn kotlin code -> javascript code. Dus vanuit dat kun je dus react libraries aanspreken, of bijvoorbeeld de react kotlin wrapper binnen hengelen en het allemaal Kotlin only aanspreken als developer.

Dus mijn punt: Ik schrijf mijn logica in Kotlin. Dan schrijf ik een Android app en een javascript app die die logica compleet deelt, maar daarbij dus wel hun eigen UI framework draaien.

Dus waar ga ik dan zo de mist in? Misschien kun je van je luie reet afkomen en het even uittikken.

Daarbij is het nooit specifiek voor Android bedoeld maar meer als Java tegenhanger. Android heeft het als eerste grote jongen wel omarmd. Als ik even Wikipedia mag quoten:

Kotlin (/ˈkɒtlɪn/)[2] is a cross-platform, statically typed, general-purpose programming language with type inference. Kotlin is designed to interoperate fully with Java, and the JVM version of Kotlin's standard library depends on the Java Class Library,[3] but type inference allows its syntax to be more concise. Kotlin mainly targets the JVM, but also compiles to JavaScript (for e.g. frontend web applications using React[4]) or native code (via LLVM), e.g. for native iOS apps sharing business logic with Android apps.[5] Language development costs are borne by JetBrains, while the Kotlin Foundation protects the Kotlin trademark.[6]

Klinkt erg als wat ik eerst opschreef.

[Delblanco]

Ik had graag gezien dat je de moeite had genomen om "te verbeteren" want ik zover ik hier lees heeft @josttie de klepel horen klingen en weet hij waar de klepel hangt. Misschien net even een verkeerde term gebruikt maar dat vergeef ik hem omdat hij het zo toegankelijk maakt voor tweakers die geen senior developer zijn.

Wij draaien nu een project in Kotlin Multiplatform waarbij het doel is om zo veel mogelijk code te gaan delen tussen de verschillende clients: iOS, Android, Web en in mindere mate de Backend. Tot nu toe is alle business logic gedeeld en heeft elk platform zijn eigen UI en UX. Zie het als een bak lego waarbij elk blokje een klein stukje functionaliteit is: data laden, bewerken, refresh, notificaties, sorteren, filteren, zoeken, etc. Elk platform heeft andere karakteristieken en maakt op basis van deze reeds beschikbare legoblokjes een eigen scherm. Per platform kan je kiezen welke frameworks je gebruikt:
- Android -> Jetpack Compose of klassieke Activities / Fragments / Views
- iOS -> SwiftUI of ViewControllers
- Web -> React / Vue... wel of geen TypeScript.
- Backend -> Spring boot

Na eerdere cross platform / hybride oplossingen was ik erg sceptisch maar KMP heeft ons redelijk verbaast in de mogelijkheden.

Het was origineel een alternatief voor Java op Android

Not quite. Jetbrains heeft kotlin in eerste instantie gemaakt voor de ontwikkeling van Intellij IDEA en begon daarmee rond 2010. Pas in 2017 heeft Google dit een 'first-class citizen' gemaakt

Het compileert niet naar javascript

Op dit moment is eerder 'transpile' dan 'compile'. Echter voor de toekomst lijkt het toch echt meer een compiler te worden: https://kotlinlang.org/docs/reference/js-ir-compiler.html

[BoomSmurf]

Volgens mij kun je voor iOS nog niet de volledige app in Kotlin doen, voor Android wel.

Verder zijn er drie varianten van Kotlin: JVM, Native, en JS. Voor Android zal de JVM versie gebruikt worden, voor iOS de Native versie. Er zitten wel degelijk verschillen tussen de drie implementaties, zowel in hoe bepaalde code werkt (geheugen, threads) en hoe volwassen de toolset is (Native en JS lopen achter op JVM). Je kunt veel code delen maar het is geen write once run anywhere.

Dit is niet zo heel verschillend van de core van een mobiele app in C schrijven en die delen tussen je iOS en Android apps, met aparte code voor de UIs van beiden, wat vaker gedaan word. Alleen dan nu met Kotlin.

Dit kon ook al gewoon, volgens mij is deze release vooral om het makkelijker te managen te maken?

[Reactie gewijzigd door BoomSmurf op 23 juli 2024 11:58]

[josttie]

Kotlin heeft nooit het idee gehad voor write once, run everywhere omdat dat nooit ergens perfect werkt. Wat ze wel inzien, is dat je alles wat logica is kunt hergebruiken omdat dat veelal niet zoveel verandert. Dus de manier van een multiplatform project opzetten is ook gedaan om het allemaal heel erg makkelijk te maken om code te delen tussen verschillende platformen, zonder performance hit. Het is vele malen makkelijk om met KMP code te delen dan om een mobiele app in C te gaan schrijven. Je kunt ook bijvoorbeeld code delen tussen backend en frontend, en ook met een mogelijke web applicatie. Dat kun je al niet met een c library. Ik denk dat als je een goede en schaalbare architectuur hebt je op zn minst 50% van code kunt hergebruiken op verschillende platformen (als je bijvoorbeeld alleen naar frontend kijkt, backend zal vaak wel andere logica hebben). Die 50% steek je in je zak, aangezien het een moeiteloze 50% is en je verder gewoon een native UI hebt en een native ervaring, wat je domweg niet haalt met een C library. In mijn eigen hobby project lijkt het erop dat die 50% een understatement is en het is echt gigantisch makkelijk om code te hergebruiken tussen een web applicatie en een android applicatie. Ook heb ik een common KMP module waar zo ongeveer de hele API met alle DTO's tussen frontend en backend zit, alsmede sommige basale utils en architecturele componenten. Dan loop je nooit meer out of sync tussen frontend en backend, en in alle projecten trek je het in 1 seconde naar binnen.

[BoomSmurf]

Ik wilde ook niet stellen dat het met C zo makkelijk (en snel) te doen is als met Kotlin hoor, zeker niet. Nog voor de tijden van frameworks als Xamarin was dit de enige manier om je core logic te delen (C++ core met C glue naar ObjC en JNI naar Java), vandaar de vergelijking van iemand die die tijd (helaas) meegemaakt heeft. Wellicht dat we iets langs elkaar heen praten maar een aantal dingen waarvan jij lijkt te stellen dat het met C(++) niet kan, kunnen wel degelijk. Ik zou ze zeker niet adviseren want het is een maintenance nightmare, zeker vergeleken met Kotlin, maar toch.

Dat write once run everywhere a la Xamarin e.d. nooit het idee was bij Kotlin moge duidelijk zijn. Maar dat bijvoorbeeld basic constructs als multithreaded coroutines niet hetzelfde werken in Native en JVM vind ik persoonlijk jammer (maar wel begrijpelijk). Misschien is dat ondertusen ook weer wel zo - het is alweer een tijd terug dat ik met Kotlin Native gespeeld heb en dat stond toen nog in de kinderschoenen.

Mijn post was ook zeker niet bedoeld om Kotlin te bashen, ik ben groot fan. Maar dat wil niet zeggen dat alles perfect is en niet meer beter kan. Ik loop dagelijks tegen pijnpunten aan.

[Reactie gewijzigd door BoomSmurf op 23 juli 2024 11:58]

[Snowfall]

Ik heb voor dit een tijdje https://scade.io gebruikt. Is een platform waar je Swift kan gebruiken voor iOS en Android applicaties. Werkt als je weet hoe t werkt ook best goed.

Ik Ontwikkel tegenwoordig alleen nog exclusief voor iOS maar voor mensen die iOS developer zijn en geen zin hebben kotlin of Java te leren ook een leuk alternatief.

Edit.

Er zijn tegenwoordig zoveel crossed platform alternatieven. Misschien leuk keer artikel over te maken op tweakers. Zou graag bijdragen mocht zoiets ooit gepland worden. Anders keer leuk om met andere developers hier op tweakers om zoiets op te zetten.

[Reactie gewijzigd door Snowfall op 23 juli 2024 11:58]

[Kenhas]

Ben zelf een beetje aan het spelen geweest met Xamarin omdat ik zeer regelmatig met Visual Studio werk en beetje binnen hetzelfde systeem wou blijven. Maar door dit artikel komen er tal van namen tevoorschijn die ik eigenlijk niet ken, zoals bijvoorbeeld hetgeen jij naar linkt.

Zou zo'n overzicht ook wel eens willen zien. Maar veel van die zaken gaan natuurlijk beïnvloed worden door persoonlijke voorkeur.

werkt als je weet hoe het werkt

Is dat niet een beetje met alles zo?

[Snowfall]

Ben zelf een beetje aan het spelen geweest met Xamarin omdat ik zeer regelmatig met Visual Studio werk en beetje binnen hetzelfde systeem wou blijven. Maar door dit artikel komen er tal van namen tevoorschijn die ik eigenlijk niet ken, zoals bijvoorbeeld hetgeen jij naar linkt.

Ik heb Xamarin heel even gebruikt. Maar ik vind C# echt vreselijke programmeertaal. Ligt me echt niet. Maar uiteindelijk maakt t volgens mij weinig uit wat je gebruikt. Zolang t maar werkt en je t fijn vind werken. (Op Electron na. )

Zou zo'n overzicht ook wel eens willen zien. Maar veel van die zaken gaan natuurlijk beïnvloed worden door persoonlijke voorkeur.

Maakt toch niet uit? Zo krijg je juist verschillende ervaringen uit andere hoeken

Is dat niet een beetje met alles zo?

Haha hoevaak ik wel niet mensen hoor jammeren en een taal de schuld zie geven als iets niet werkt xD.

[xFeverr]

Dat hoor je niet vaak dat men C# een 'echt vreselijke programmeertaal' vindt. Zal wel aan mijn omgeving liggen, want ik vindt het een prachtig taaltje

Ook Swift mag er zijn, is een hele leuke taal om in te werken. Je tip voor SCADE ga ik eens bekijken, klinkt interessant.

De dagen dat Objective-C de hoofdtaal waren op het Apple platform ligt gelukkig achter ons, dag is iets wat ik zou kwalificeren als een 'echt vreselijke taal'.

[Reactie gewijzigd door xFeverr op 23 juli 2024 11:58]

[rko4u]

Ik mis een beetje de info in welke taal er geprogrammeerd moet worden (of waar het op is gebaseerd). Het lijkt java te zijn. Dit is dus de java tegenhanger voor xamarin?

[jurriaan]

kotlin is de taal

[rko4u]

De naam van een voor mij nieuwe taal zegt mij als C# developer niets, maar gezien er gebruik wordt gemaakt van jvm en de code bekijkend op de site, lijkt het java gebaseerd. Xamarin is ook niet helemaal gelijk aan dotnet.

[erikieperikie]

Kotlin kan inderdaad naar JVM bytecode compileren, maar bijvoorbeeld ook transpileren naar JavaScript, en KMM, waar dit artikel over gaat, compileert naar native code die kan draaien op Android en iOS. Zo probeert JetBrains met Kotlin en general purpose taal te creëren.

[Tripwire999]

Ik ben op werk al aan het testen met de Alpha versie. Afgezien van de setup die nog wel ns mis gaat werkt het eigenlijk best goed al. Ben nu een bestaande iOS (Swift) & Android (Kotlin) app aan het omzetten naar een common library in Kotlin Multiplatform. Hierin zit dan de Database (SQLDelight) en de API calls (Ktor) en eventueel nog wat andere dingen als theme kleuren e.t.c. Het mooie in vergelijking andere hybrid frameworks is wat je alleen je business logic schrijft in Kotlin en niet de UI. Als het goed uitgewerkt word kan dit een hoop development tijd schelen! Ik voorzie dat dit heel groot kan worden (en dat hoop ik ook)

[Reactie gewijzigd door Tripwire999 op 23 juli 2024 11:58]

[tyball]

Quasar framework ( Vue.js) geeft je 1 code base voor:
- websites( SSR, PWA, SPA)
- mobile ( capacitor ,cordova)
- desktop ( electron),
- chrome extensions (BEX):

https://quasar.dev/

Een echte aanrader.

[Reactie gewijzigd door tyball op 23 juli 2024 11:58]