Programmeertaal Swift verschijnt voor Windows

Versie 5.3 van Apples programmeertaal Swift is verschenen en daarmee zijn ook de images voor de Swift-toolchain voor Windows verschenen. Programmeurs kunnen daarmee applicaties voor Windows in Swift ontwikkelen.

Naast de Swift-Toolchain voor Apples Xcode en voor Ubuntu, CentOS en Amazon Linux, staat Windows 10 vanaf versie 5.3 in het rijtje van ondersteunde platformen voor Swift. Het gaat om een port van het hele ecosysteem, inclusief compiler, standaardlibrary en corelibraries dispatch, Foundation XCTest.

Ontwikkelaars kunnen geheel in Swift applicaties op Windows maken en daarbij de bestaande libraries van het Windows-platform inzetten. Saleem Abdulrasool geeft een voorbeeld van een met Swift ontwikkelde rekenmachine voor Windows, waarbij naast de Swift-Toolchain ook Visual Studio 2019 ingezet is, zodat van CMake, Ninja en de Windows 10 SDK gebruikgemaakt kon worden. Ontwikkelaars konden al de Swift-compiler in Windows Subsystem for Linux 2 gebruiken.

Abdulrasool is voor een groot deel verantwoordelijk voor de officiële Windows-build van het Swift-project. Hij is lid van het Swift Core Team en ontwikkelaar bij Google Brain. Swift is een programmeertaal die Apple in 2014 uitbracht als vervanger voor Objective-C. Bij het verschijnen van versie 2.2 in 2015 werd Swift opensourcesoftware met een Apache 2.0-licentie.

Reacties (108)

[Wulfklaue]

Een paar opmerkingen over Swift op Windows ( en Linux ). Ja, Swift draait op Windows maar ... net zoals bij Swift op Linux, is het eerder een beperkte aanbod.

Als je een taal wilt gebruiken, wil je toegang tot de resources van die taal. Namelijk de compiler, libraries, tools, community en eco systeem.

Wat je hier ziet in de release, is eerder de eerste 2 punten. Het probleem met de Swift community is dat bijna alle resources gefocused zijn op Apple hun interne marktje. Met als gevolg dat vragen en antwoorden zich eerder moeten beperkten tot abstracte code.

* SwiftUI? Apple enkel ding. Je wilt GUI gebruiken op Linux/Windows, vergeet het om enige support te krijgen want dit zijn vrijwilligers bijdragen van een zeer beperkte group. Als Electron voorgeschoteld word door sommigen als oplossing voor GUI op cross platform, ...

* Ontwikkelingsomgevingen? Zo goed als onbestaand op de andere platformen ( Linux en ook Windows ). Je beste keuzen buiten een paar syntax plugins is SourceKit-LSP ( wat een beta plugin ). Er is echt gewoon niets te vinden buiten LSP en een hoop verouderde plugins die nauwelijks ondersteund worden. XCode is heer en meeste als het neerkomt op informatie met als gevolg dat tutorials verwarrend kunnen overkomen als je niet draait op het Apple platform.

* Eco Systeem? Proficiat want zowat 95+% van alle taal plugins zijn geschreven met enkel Apple hun Eco systeem in gedachte. Met als gevolg dat je valt in de niet ondersteunde problemen als je draaide op Linux ( waar de Swift compiler al jaren op draait ). Windows support voor de packages is op dit moment letterlijk 0.00001%. Je kan argumenteren dat het zal groeien maar als je echt een professioneel product wilt maken en niet een paar simpele hello world CLI applicaties, dan wil je toegang tot een stabiele en ondersteunde markt voor je platform.

Heel wat code is gewoon niet ontworpen om platform agnostic te zijn:

#if os(Linux)
import Glibc
#else
import Darwin
#endif

Dit is wat je vind in cross platform programma's. En nee, niet enkel voor de Glibc vs Darwin libraries. Nu moet je hopen dat die zeldzame cross platform code, dat de ontwikkelaars al hun code updaten voor Windows ( en testen ). Dat is niet cross platform maar gewoon specifieke libraries om te kunnen werken op dat platform.

Laat staan de CMake "oplossingen" dat je moet samenstellen gewoon om met de package manger te kunnen werken.

* Bugs? Well ... Swift voor Windows is het werkt van een kleine groep vrijwilligers ( 1 persoon specifiek dat JAREN bezig geweest is met het implementeren van alle aanpassingen ). Geen enkel bedrijf in de wereld zal hun toekomst gaan linken aan een taal, waar op je platform, je afhankelijk bent van een paar niet betaalde vrijwilligers die het doen in hun vrije tijd.

Als ik de stabiliteit bekijk van Swift op Linux, was het niet moeilijk om de compiler te doen crashen met vrij simpele programma's. En weeral ... Swift op Linux is al jaren een "ondersteund" product. Het grote probleem is dat er enkele IBM werknemers waren, dat origineel veel tijd stak in Swift/Linux ( toen Swift uitkwam ) maar die zijn er al lang geleden mee gestopt.

Apple heeft jaren de cross-platform capaciteiten van Swift genegeerd en je ziet het in de code dat ontwikkelaar schrijven. Puur Apple platform gericht. Het feit dat Swift voor Windows uitkomt, heeft even veel impact als Swift voor Linux had. Maar weinig mensen dat ermee werken en nog minder dat echt grote programma's erop bouwen. En dit is de eerste release ... verwacht nog hopen met exotische bugs naar de toekomst voor de boel echt stabiel is.

Het is jammer. Swift is een mooie taal maar vanuit cross-platform is de ondersteuning nog slechter dan talen van kleine groepjes.

Swift voor Windows is letterlijk Alpha software ( en Swift voor Linux kan je best catalogiseren als Beta software ). There be dragons here folks! Er zijn genoeg zelfde generatie talen waar je cross platform kan ontwikkelen zonder dezelfde issues. Go, Rust, ...

Het is voor iedereen om zelf de beslissen hoeveel ze van hun tijd willen steken maar ik heb mijn lesjes al jaren geleden geleerd met Swift for Linux...

[Immutable]

Ik hoor het al, QT is nog steeds heer en meester qua multiplatform in combinatie met C++. Niks komt daar dichtbij.

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[Ruudvoijen]

Ik denk dat .net framework 5 daar aardig in de buurt gaat komen. Daarnaast is het uno platform ook al een mooi platform om in c# cross platform in te zetten.

[Tweakers Fanboy]

Bedoel je .NET 5 (zonder Framework)? Volgens mij zal Microsoft pas bij .NET 6 komen met MAUI voor multi-platform apps en .NET 5 bevat een preview versie daarvan. Ik kan me zo geen andere dingen bedenken die gaan veranderen op GUI gebied.

[Reactie gewijzigd door Tweakers Fanboy op 2 augustus 2024 20:37]

[ATS]

C++ en tegenwoordig natuurlijk QML, maar verder heb je gelijk.

(Het is overigens Qt, niet QT. QT is QuickTime.)

[Bodevinaat]

Ik gebruik zelf al jaren Xojo. Multiplatform. Native apps op Win/macOS/Linux en web. Compileren voor win/mac/linux op Windows of andersom. Fijne community, veel externe tools/libs beschikbaar. Low cost.

[Immutable]

-

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[Renssanting]

>Als Electron voorgeschoteld word door sommigen als oplossing voor GUI op cross platform, ...

Dat is het toch ook al, en met veel succes?

[jj71]

Ja natuurlijk, maar Wulfklaue bedoelt natuurlijk dat er nauwelijks een manier is om met Swift zelf een Windows of Linux GUI applicatie te maken.

Electron = een browser-achtig ding in een window waar je je GUI in JavaScript of TypeScript programmeert. Werkt goed, maar is geen native Swift-oplossing.

[Wulfklaue]

> Dat is het toch ook al, en met veel succes?

Electron is een oplossing dat niet native is aan de taal. Als we Electron gebruiken als Cross-platform, dan kan je zelf PHP als een cross-platform GUI toepassing omschrijven. Ik denk dat niemand zich dat toewenst *haha*.

Voor Swift native GUI, is de enige GUI oplossing ofwel:

* Via de oude Objective-C libraries ( Apple platform specifieke UI )
* Via de nieuw SwiftUI ( weeral puur geschreven voor Apple hun platform only ).

[ATS]

Electron is een rampenplan. Veel en veel te resourcehungry. We krijgen regelmatig klanten die beginnen met ene Electon oplossing en dan vastlopen omdat het gewoon niet lekker draaiend te krijgen is op hun platform. Zelfs een simpele chat app (Rocket.Chat) trekt vrijwel een hele CPU core dicht zonder dat er wat intressants gebeurt in de client.

[Renssanting]

Tja, dat zal wel aan de implementatie liggen. Ik heb nog nooit van Rocket.chat gehoord. Zelf gebruik ik RamBox voor macOS, wat gewoon een shell lijkt te zijn voor meerdere van dit soort Electron Apps, en zelfs met 3 slack instances, en eentje voor discord haalt dat gezamelijke proces nog geen 5% cpu load.

[flowerp]

> op Apple hun interne marktje

Zo klein is dat marktje toch ook weer niet? C# heeft zich overigens ook altijd voornamelijk op MS hun interne "marktje" gericht. Pas laatste jaren komt daar langzaam wat verandering in.

[MSalters]

C# is zakelijk veel ingezet, en dat is een markt waarin significante bedragen worden uitgegeven aan in-house development. De concurrent is dan vaak Java (op Linux). Apple is op die markt lang niet zo groot, al was het alleen maar omdat OSX Server dood en begraven is.

[laptopleon]

Het moet ergens beginnen. Het is hoe dan ook een opvallende stap.

Ik zou het vreemder vinden als Tweakers eerst zou wachten tot… ja, welk criterium zou Swift precies moeten halen op Windows voor het vermeldenswaardig is?

[henk1994]

Als we nu ook Swift beschikbaar maken voor Android hebben we een nieuwe uniforme programmeertaal waarmee cross platform ontwikkeld kan worden.

[Exirion]

Er is jaren geleden al veel speculatie geweest over overwegingen van Google om Java te vervangen door Swift. Inmiddels is Swift als taal wat stabieler aan het worden, in die zin dat er niet bij elke versie een waslijst een wijzigingen is die bestaande code breekt. Wie weet dat Google de stap nog eens zet, maar ik zie het eigenlijk niet zo snel gebeuren.

Overigens is je aanname te kort door de bocht. Een taal leren is maar een klein deel van de learning curve voor het ontwikkelen op een bepaald platform. De platformspecifieke frameworks/libraries/APIs vergen de meeste tijd om goed in thuis te raken en alle in/out en bugs te ontdekken. Swift in plaats van Java zal daar niks aan veranderen.

[Reactie gewijzigd door Exirion op 2 augustus 2024 20:37]

[Tripwire999]

Gaat denk ik niet meer gebeuren nu Kotlin de tweede taal is voor Android

[Nightscope]

Het is niet de tweede taal, het is de eerste taal voor Android geworden. Java is de tweede taal. Dat de meeste libraries nog van of in Java geschreven zijn, maakt Kotlin niet een tweede keus, althans volgens Google.

[ItsFlokkie]

Maar je kunt wel Kotlin Libaries maken die in Swift ingeladen kunnen worden. Tenminste dat heb ik wel eens voorbij zien komen. Dus in theorie kun je een libary maken in Kotlin die in Windows + iOS (Swift) en Android (Kotlin) gebruikt kunnen worden.

Edit:

Kan zomaar zijn dat het alleen onder iOS werkt

https://kotlinlang.org/do...tive/apple-framework.html

[Reactie gewijzigd door ItsFlokkie op 2 augustus 2024 20:37]

[.oisyn]

Een taal leren is maar een klein deel van de learning curve voor het ontwikkelen op een bepaald platform.

Maar het gaat niet om het leren van de taal. Het gaat om een eenmalige implementatie van alle business logic, zodat je niet alles opnieuw hoeft in te typen in een andere taal, met de nodige bugs als gevolg.

Overigens kan dat allang met talen als C++ of Java.

[Exirion]

Mijn punt is dat als Google voor Swift zou kiezen, ze waarschijnlijk gewoon blijven vasthouden aan hun eigen APIs. Dus ja, het is winst als een taal op meerdere platformen ondersteund wordt, maar voor echte cross platform development ben je er dan nog lang niet.

[.oisyn]

Dat is zeker waar, maar het zou, afhankelijk van de applicatie, vele malen meer werk zijn als je alles opnieuw in moet typen. De interface met non-crossplatform API's verwerk je achter abstracties zodat dat deel erachter makkeljk vervangbaar is.

[P_Tingen]

Een taal leren is maar een klein deel van de learning curve voor het ontwikkelen op een bepaald platform. De platformspecifieke frameworks/libraries/APIs vergen de meeste tijd om goed in thuis te raken en alle in/out en bugs te ontdekken. Swift in plaats van Java zal daar niks aan veranderen.

True; ik probeer c# op te pakken als extra ontwikkeltaal. De syntax is nog niet zo lastig en boeken als "learn c# in 24 hours" lukt dat ook wel. Het hele universum erachter aan framework is iets meer werk...

[jj71]

Maar waarom zou Google dan voor Swift willen kiezen voor Android?

Als ze van Java af willen (wat ik me kan voorstellen omdat ze ruzie hebben met Oracle over de Java libraries) dan lijkt het me meer logisch dat ze voor één van hun eigen talen kiezen: Go of Dart.

[GertMenkel]

Let wel dat het alleen de taal betreft, niet het SwiftUI-framework waar veelvuldig gebruik van wordt gemaakt. Je kunt dus hello world in je console krijgen, maar verwacht geen uitgebreide applicaties te ontwikkelen in een IDE als Xcode (of een beter).

Als je op taalniveau cross-platform wil ontwikkelen heb je daarvoor altijd nog Kotlin, Dart, C(++), JavaScript, Rust, Python en meer voor. Swift is een leuke toevoeging, maar zonder libraries verwacht ik niet dat het erg aan zal slaan voor dit doel.

Op cross-platform app-ontwikkelingsvlak heb je voor zover ik weet al jaren dingen als React Native (JavaScript), Kotlin Native (Kotlin), Flutter (Dart) en Microsoft Xamarin (C#). Ik verwacht alleen niet dat Apple veel moeite gaat steken in het ondersteunen van andere platformen in hun libraries.

[johnkeates]

Alleen de UI en macOS specifieke dingen zitten er niet echt in, maar dat is tenzij je end-user apps maakt niet de belangrijkste factor.

Machine learning gaat bijv. best lekker in Swift.

[SG]

Je mist dus windows UI libaries voor swift en de swap van Metal naar directx12 en Vulkan. Vraag mij af of Swift ook C++ kan aanspreken op windows platform.

Het probleem voor mij is het is zo nieuw voor windows en mijn interresse in hobby game ontwikkeling dat er weinig samples en guids zijn er voor . Tov C++.
Na DX12 ben aan spitten in Vulkan C++ samples.
Op Mac xcode ben ik al met swift bezig en niet zozeer met Metal.

[MSalters]

"C++ op Windows" is een wat verwarrende term. Je hebt daar meerdere compilers. Visual Studio is de hele grote, maar je hebt bijvoorbeeld ook Intel (commercieel). Swift op Windows zal compatible zijn met de C++ implementatie die gebruikt is om Swift zelf te compileren.

[johnkeates]

Dat maakt denk ik alleen uit als je een GUI frontend applicatie maakt. Er zijn erg veel andere soorten applicaties die geen GUI gebruiken maar wel geschreven moeten worden (bijv. in Swift).

Ik denk dat er wel een FFI voor Windows functionaliteit in zit of wel een aanknopingspunt heeft maar dat iemand anders nog een wrapper voor win32 dll calls en com enz. moet oppoetsen.

[PageFault]

Wat zijn de voordelen? We hebben al zoveel uniforme cross platform talen.

[henk1994]

Schijnt een prettige taal te zijn. Op dit moment kun je geen Java applicatie of C# applicatie schrijven die je op Windows, Linux, MacOS, Android en iOS kan draaien. Enkel JavaScript icm Capacitor of Cordoba komt in de buurt, maar dat haalt het niet bij een native applicatie.

[peverix]

Met Dotnet core en Xamarin kun je dit allemaal in c# doen

[StefanJanssen]

En binnenkort kan het ook met .NET en AvaloniaUI.

[Immutable]

Waarbij elke Widget apart op elke platform geimplementeerd moet worden. Waarbij als je dus een "custom" widget wilt hebben, je die voor elke platform moet implementeren. Troep dus.
Dat heb je niet bij Flutter bijvoorbeeld. (De hele render pipeline van Flutter is 1 van de meest goed doordachte GUI toolkits) geniaal.

[StefanJanssen]

Hier ben ik het gedeeltelijk met je eens. Een UI component moet zich gedragen naar de standaarden per platform. Dit is iets wat ik bij bij Flutter en React toch flutter vind werken. Zo'n custom component is ontwikkeld voor 1 platform en het werkt op ze allemaal, helaas voldoet het dan nog niet aan de standaarden van elk platform. Als ik kijk naar gebruiksvriendelijkheid voor de user boeit het me niets dat het op iOS het net iets anders werkt dan op Windows zolang de functionaliteit maar hetzelfde is.

In mijn ervaring zijn er zelden volledig custom componenten nodig waarbij je low level draw calls moet aanroepen en mocht dat het geval zijn wil je wel zeker weten dat het voor elk platform werkt zoals het hoort.

Dat is iets waar ik mij zelf bij erger bij elk product van google ongeacht het platform ze forceren overal Material Design, wat redelijk werkt voor mobiel, maar op widescreen desktops totaal niet werkt.

[Immutable]

Het mooie is dat Material Design maar een design language is. Het is juist zo krachtig dat je daar je eigen design language kan neerleggen. De widgets zijn niet gemaakt op een ultra low level drawcalls, maar juist op een hoger niveau. Dat is de kracht van o.a. Flutter & QtQuick(Tesla gebruikt dat).

Daarmee kun je vertrouwen op high performance en abstracties die de fundamentele zaken lekker laag houden, maar waarbij je toch de vrijheid hebt om artistiek te zijn en compleet je eigen widget bibliotheek op te bouwen welke op elke platform werkt met 1 code base. Is bijvoorbeeld een standaard widget niet goed genoeg? Pak de opensource code wat toch al behoorlijk high level is... want widgets zijn opgebouwd uit fundamentals en pas je die aan.

QML bijvoorbeeld:
import QtQuick 2.0

Rectangle {
id: page
width: 320; height: 480
color: "lightgray"

Text {
id: helloText
text: "Hello world!"
y: 30
anchors.horizontalCenter: page.horizontalCenter
font.pointSize: 24; font.bold: true
}
}

Je kan uit al die fundamentele objecten compleet nieuwe widgets bouwen. Het is een krachtige compositie waarbij je en vrijheid hebt, en performance. Best of both worlds zeg maar.(Ga maar eens in een Tesla zitten, best smooth interface toch?)

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[Eeki]

En met UNO ook nog in webassembly

[Immutable]

Waarbij een mono-runtime op je client draait bovenop webassembly, en daarboven op je C# bytecode. Wat echt SUPER TRAAG is. Want ze hebben geen echte vertaalslag van C# direct naar Webassembly zoals Rust en C++ doet. (Wat veel beter is)

Maar moet zeggen, dat UNO wel de meest belovende is die ik heb gezien voor C#. Lijkt meer op Flutter dan de andere systemen. Gebruikt onderliggend ook Skia, met de fundamentals op een ander niveau dan alle andere C# Gui toolkits...

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[Ablaze]

Het is relatief traag maar .NET 5 wasm is al stukken sneller dan Core 3.x en MS is bezig met een AOT compiler.

[Immutable]

AOT zou een groot verschil geven idd.

[imuller]

En nu gaat Microsoft nog een stapje verder met .NET MAUI (Multi-platform App UI) https://devblogs.microsof...et-multi-platform-app-ui/

[peverix]

Een zoveelste poging van MS om Universial apps te kunnen maken.

[Laurens-R]

Niet de zoveelste poging. Waar UWP een nieuw concept was, is dit gebaseerd op proven cross platform technology in de form van Xamarin welke verder verwerkt zal worden in de volgende versie van .net. Xamarin is een veelgebruikte cross platform toolchain om apps mee te maken op basis van C# en .net.

[Egocentrix]

Een naam die ze (al dan niet bewust) hebben 'geleend' van een andere UI-toolkit: https://itsfoss.com/microsoft-maui-kde-row/

[twilex]

Eigenlijk is het helemaal geen naam maar een omschrijving die ze hebben afgekort.
Weinig creatief en weinig zeggend.

[twilex]

Pakkende aansprekende productnamen zijn helaas niet bepaald Microsoft's sterkste kant.

[Immutable]

Ik zie continu van die GUI toolkits wat gewoon meer een bibliotheekje is met wat widgets etc. Wat ik altijd verwacht van een goede GUI Toolkit is hele low level fundamentals waarmee je zelf custom zelf widgets kan opbouwen op een makkelijke manier en dat ze ook performant zijn zijn. (Zie Flutter van Google, en QtQuick van QT.)

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[qless]

Dart en flutter ook, werkt erg plezierig

[Ablaze]

Het werkt maar het programmeert lang niet zo snel als de drag & drop en RAD UI ontwikkelmethodes met automatische binding die we al sinds de jaren '90 met Windows desktop development gewend zijn.

[qless]

Zodra je wat thuis bent in de widgets gaat het snel, en met de hot-reload is totaal sneller dan met andere talen, voor ios/android devices. Ook is het handig dat de widgets op compile time al meer checks hebben dan met standaard xml design van Android. (Nu heb ik de nieuwe swift interface design voor ios nog niet zelf geprobeerd)

[Martinspire]

Het kan wel, maar het probleem is vooral MacOS en iOS, de rest heeft zat talen die makkelijk op andere platformen uit te rollen zijn. Het is vooral Apple die nooit wil meewerken.

[nils83]

Beetje kort door de bocht, een andere persoon met "Apple" badge zou bvb kunnen stellen dat Google niet wil meewerken door Swift te omarmen. Uiteindelijk is Swift gewoon opensource gemaakt door Apple.

De waarheid zal wel ergens in het midden liggen...

[Chinco]

Ik ken wel voorbeelden dat Apple niet meewerkt, eigenlijk geen voorbeelden die wel goed gaan.

BT: eigen implementatie boven op of naast de standaard
Laadpoort: geen usbC
Safari: niet meer voor Windows. Edge wel voor iOS
Swift: waar het artikel over gaat

En zo zijn er nog heel veel meer dingen te noemen waaraan te zien is dat Apple (meestal bewust) op een eiland opereert. Daarvan ligt de waarheid echt niet in het midden.

Let op dat ik er geen waardeoordeel aan geef, voor we weer in fanboyisme belanden.

Nou vooruit, de draadloze lader kan ik gebruiken voor beiden.

[webster]

BT: Apple volgt juist prima de standaard. Wat is er niet standaard dan?
Als het over aptX gaat: dat is een fabrikant-specifieke codec, die alleen in Qualcomm chipsets te vinden is.

Laadpoort: Apple heeft juist één van de beste USB-C PD implementaties in de markt, dus wat is het probleem?

Safari: niet meer voor Windows omdat geen hond het gebruikt. Geen rare beslissing lijkt me.

Een eis voor MFI certificatie is notabene dat een protocol (USB, BT, PD, Qi, ...) volgens de officiële specificatie is geïmplementeerd.

Qi is wel een apart geval, maar ook weer niet. De 5W laadmode gaat 100% volgens de standaard. Hun snellaadvariant met 7.5W is wel een eigen uitbreiding. Maar iedere telefoonfabrikant doet dat. Slechts een enkele telefoon gebruikt de officiële EPP spec voor >5W laden).

[mjz2cool]

BT: Ik weet niet wat daar mis mee is, het werkt in ieder geval gewoon goed. Ik mis alleen aptX ondersteuning, al vraag ik me af wat daar het voordeel van is, wanneer ik mijn koptelefoon (met aptX ondersteuning) gebruik met een telefoon die het wel ondersteunt.
Laadpoort: Gelukkig geen usb c, maar nog steeds lightning. Dat vind ik nog steeds fijner dan usb c.
Safari: Apple is toch niet verplicht om het op andere platformen uit te brengen? Dat Edge er wel is voor Mac OS en iOS maakt niet zoveel uit. Ik ben ook blij dat Apple eindelijk een andere standaard browser toestaat, dat ik Edge nu ook op mn telefoon als standaard kan gebruiken.
Swift: Hoezo werkt Apple daar niet mee?

[Martinspire]

Ik bedoel meer dat de SDK's nog steeds exclusief voor MacOS blijven, waardoor je geen applicaties kunt ontwikkelen en ook geen app kunt testen. Dát is de belemmering, niet de programmeertaal of het OS waar je op wilt ontwikkelen.

[graverobber2]

Bij java zou dat wel moeten, want de JVM doet alle vertalingen voor jou.
Het probleem is dat er niet uniform met bepaalde zaken omgegaan worden, zoals API's om bepaalde apparatuur aan te spreken (denk Camera op iOS vs op Android), hoe de UI opgemaakt wordt, etc...

[Wolfos]

De JVM draait niet op iOS.

[dashorst248]

Met Gluon en GraalVM kan je Java code geschikt maken om te draaien op iOS. https://gluonhq.com/java-on-ios-for-real

[PageFault]

Java toch wel? De JREs zijn voor al die dingen beschikbaar, wellicht Android een vreemde eend in de bijt, maar Java apps heb ik vaker gemaakt voor Windows en macOS (toen nog classic, dus wel effe geleden). Linux kwam toen net om de hoek kijken, dus daar me niet aan gewaagd in die tijd.

[Pasteis]

Schijnt een prettige taal te zijn. Op dit moment kun je geen Java applicatie of C# applicatie schrijven die je op Windows, Linux, MacOS, Android en iOS kan draaien. Enkel JavaScript icm Capacitor of Cordoba komt in de buurt, maar dat haalt het niet bij een native applicatie.

Python is toch ook cross platform?

[ATS]

Probeer eens C++ (en QML) met Qt. Werkt op al die platformen (en meer).

[Gropah]

Zijn er echt zo veel? Zeker als je volwassenheid meeneemt?

Je hebt Xamarin, maar dat word nauwelijks gebruikt en matig ondersteund door MS (voor zo ver ik weet). Er zijn veel manieren om javascript te laten draaien op iOS en Android, maar dan mis je vaak de performance omdat het of single threaded is of een verkapte webbrowser. Met kotlin zijn ze nu bezig om dat goed werkend te krijgen, ik weet dat ze met flutter/dart ook wat interessants hebben neergezet bij Google, maar ook dat is nog in ontwikkeling.

Dus ja, misschien is het er wel weer nog een, maar er is veel in ontwikkeling en het moet nog maar blijken welke het beste is. Zolang dat dat nog niet duidelijk is, vind ik het geen rare zet.

[DoubleDot]

Matige ondersteuning door MS? Ze hebben Xamarin gekocht in 2016.
https://blogs.microsoft.c...build-apps-on-any-device/

Mensen die graag in C# programmeren hebben met Xamarin een mooie mogelijkheid om cross-platform apps te bouwen en is volgens mij allesbehalve nauwelijks gebruikt. React Native is wel serieus wat marktaandeel aan het afsnoepen.

[StefanJanssen]

En zelfs voor de overname waren MS Xamarin en Unity3D al aan het praten over C# en de toekomst van .NET.

Daarnaast is er nu ook AvaloniaUI wat een opensource UI framework is voor .net (core).
Met implementaties voor Windows, MacOS en Linux en binnenkort ook Android en iOS.

[Immutable]

Als ik een high level custom Widget maak in AvaloniaUI werkt deze met exact dezelfde code op alle platformen automatisch?
Of ben je dan compleet afhankelijk van de beschikbare widgets, welke vaak nooit 100% de usecase afdekken en waarbij je vastloopt e.d.

[Reactie gewijzigd door Immutable op 2 augustus 2024 20:37]

[Nolimit89]

Xamarin wordt nauwelijks gebruikt en matig ondersteund door MS? Hoe kom je daarbij...?

[Maurits van Baerle]

Er worden veel iOS apps in native Swift ontwikkeld dus het zou het voor developers makkelijker kunnen maken om hun apps naar Android te porten.

[xFeverr]

Maar dan moet je het wel goed voor elkaar hebben. Zaken als UIKit en andere frameworks ga je niet op Android krijgen. Als je dat allemaal goed gescheiden hebt hoef je in theorie alleen nog maar de android UI te bouwen. (of daar moet weer een cross platform framework voor komen, maar dan zal je je UIKit gedeelte moeten herschrijven.)

[SG]

Je kan het zo zien C++ en Objective-C hebben zooi legacy mee . En in de software industrie is legacy code heel belangrijk. Oud zooi moet nog steeds compileren.
Houd in dat op oude manier en aanbevolen nieuwe manier code kan inkloppen. Dat maakt de taal bloated voor nieuw komers en hoop manieren op in verstrickt te raken.
Voor C++ is er D een nieuwe taal die breekt met Legacy.
Swift is dat voor Objective-C
From scratch een taal opzetten zonder de legacy ballast.

Dat maakt de taal cleaner syntac logischer en minder bloated.
Omdat Apple Swift hard pushed op eigen platform is de adoptie ook sneller daar. En nu het ook voor Windows beschikbaar is kan het ook alternatief voor C++ zijn.
Daar is gewoon een alternatief voor C++ en D

[ATS]

C++ is wel uniek dat het weldegelijk ontwikkelt, zonder dat het daarbij die legacy achter laat. C++20 is in feite alweer een heel andere taal dan C++11, wat op zichzelf een enorme stap was t.o.v. 98. De laatste laren is er heel steady progressie in de ontwikkeling van de taal en de standard library, en je ziet dan ook dat de taal weer aan een opmars bezig is qua marketshare.

Zoals je zegt: die "oude zooi" is ook "tried and tested"; code waar vele jaren werk en ervaring inzitten, waarin vele corner cases zijn geadresseerd. Die kan je wel modernizeren, maar die wil je niet weggooien.

[h3x4d3c1m4l]

Als je het al kunt, zou je er vanaf dan ook Android-apps mee kunnen maken. Het leren van een nieuwe taal en/of framework is iets waar je best ff mee zoet bent.

Ik was zelf bijvoorbeeld heel blij met het opensource worden van Xamarin en Xamarin Forms, want dat was bekend terrein voor mij (C#, XAML). Vanaf dan kon ik naast Windows-apps ook Android-apps maken.

[Maurits van Baerle]

Ik ben niet zo bekend met Android. Zou je dan een compiler nodig hebben die bytecode aflevert die op de Dalvik VM zou kunnen draaien?

[daellat]

Dalvik is al een heel tijdje vervangen, tegenwoordig gebruik je ART https://en.wikipedia.org/wiki/Android_Runtime

[Maurits van Baerle]

Ah, OK. De vraag blijft, zou je dan een compiler nodig hebben die Swift code compiled naar bytecode die naar ART gestuurd kan worden? Is dat haalbaar?

[gedonie]

Op zich zal dat het grootste probleem niet zijn. Maar de UI ervoor wel. Een UI kun je veel minder makkelijk porteren van IOS naar Android. Om nog maar te zwijgen over het feit dat de look and feel van apps op IOS totaal anders is dan die van Android.

Dus ja je kunt een gedeelte van een app porteren en compileren naar ART binaries, maar of je dan iets bruikbaars hebt is nog maar de vraag.

[Tripwire999]

Check Kotlin Multiplatform Kotlin is bijna hetzelfde als Swift en met Kotlin Multiplatform kan je shared frameworks voor onder andere iOS & Android
https://kotlinlang.org/docs/reference/multiplatform.html

[Reactie gewijzigd door Tripwire999 op 2 augustus 2024 20:37]

[Tassadar32]

Met Kotlin kan je ook al naar iOS dus die optie is er al.

[Sokoo]

Ooit gehoord van .net core?

[twilex]

Helemaal niet nodig.
Er kan al voor alle gangbare platformen worden ontwikkeld in C#.
Voor die platformen is ook het .NET (Core/Mono) platform beschikbaar, dus niet alleen maar een taal.

Wordt cross-platform development met Swift goed ondersteund?
Gebruiken Swift programma's echt de native look & feel van Windows?

Met al het protectionistische gedoe van Apple zitten we toch zeker niet op een Apple programmeertaal op Windows te wachten....

Swift for Android?
Swift for Linux? Oh, blijkbaar bestaat (of bestond) dit inderdaad.
Ontwikkelen voor iOS zonder dat Apple daarvoor juridisch de inzet van Apple hardware vereist?

Swift voor Windows, is dat voor diehard Apple developers die ook wel eens wat voor Windows willen maken maar slechts Swift beheersen?

[Reactie gewijzigd door twilex op 2 augustus 2024 20:37]

[Anoniem: 336502]

Als je een multi/cross platform framework wilt voor iOS en Android neem dan flutter op basis van Dart erg compleet met veel packages.

[Reactie gewijzigd door Anoniem: 336502 op 2 augustus 2024 20:37]

[Snowfall]

Swift werkt naast Apple producten ook op Linux heel erg goed.

Ik gebruik Swift nu dik 2 jaar als serverside taal voor APIs en voor het bouwen van websites. Van m’n eigen leer platform waar ik mensen leer om swift te gebruiken is ook werkelijk alles in swift geschreven. Admin app, backend dashboard, Rest api, website, iOS en tvOS app.

Als je Swift al kent is t schrijven voor Ubuntu of het schrijven van rest apis echt een peulenschil.

APIs en websites die ik voor klanten bouw bouw ik tegenwoordig ook in swift en ze zijn echt onder de indruk van de performance gain en het lage resource gebruik van swift.

En Android apps bouwen in swift is ook al mogelijk met bijvoorbeeld scade

HTTPS://scade.io

Swift word ook omarmt als Python alternatief voor machine learning. Zelfs Google Tensorflow heeft een swift variant waar je geen enkele regel Python hoeft te gebruiken voor t trainen en gebruiken van machine learning modellen

https://www.tensorflow.org/swift

[Reactie gewijzigd door Snowfall op 2 augustus 2024 20:37]

[BikkelZ]

APIs en websites die ik voor klanten bouw bouw ik tegenwoordig ook in swift en ze zijn echt onder de indruk van de performance gain en het lage resource gebruik van swift.

De meeste server-side talen zijn ook gewoon behoorlijk traag. Ik moet altijd geloven van mensen dat JavaScript helemaal de bom is tegenwoordig maar zet er een echte programmeertaal tegenover - desnoods Java - en het verschil in performance wordt gewoon pijnlijk duidelijk. Er zijn wel wat programmeertalen die niet precompiled zijn die ook snel kunnen zijn (bijvoorbeeld PHP code die niet lijdt aan OO of Erlang / Elixir).

[Snowfall]

Nou ik ben dus opgegroeid in de tijd dat PHP de standaard werd voor serverside applicaties. Toen werd NodeJS populair ook een tijdje gebruikt. Nu ben ik zelf op Swift overgestapt en ik vind zowel PHP als NodeJS gewoon langzaam aanvoelen vergeleken met bijvoorbeeld Swift. Vooral als je bijvoorbeeld kijkt naar de gebruikte systeem resources vind ik Swift toch wel een verademing. De eerste versie van mijn website bijvoorbeeld gebruikte meer dan 3 GB RAM wanneer er veel traffic was. Deze was in Node geschreven. Tweede versie die nu online is is geschreven in Swift en gebruikt bij dezelfde hoeveelheid traffic gemiddeld 500 MB. (Derde versie lanceert in oktober en ik ben ervan overtuigd dat ik de magische 300 MB grens kan halen) Is een sport geworden bijna haha.

Nu heb ik 2 maanden geleden een Django applicatie van een Video sharing website in Swift geschreven voor een klant. Systeem gebruik was meer van gehalveerd.
Dit bedoelde ik meer met performance gain. Niet perse dat t sneller aanvoelt.

Nu heeft serverside Swift ook wel zn nadelen. Weinig packages nog en de meeste code om te kunnen interacten met bijv betaal providers moet je bijna altijd zelf schrijven.

[vespino]

Nu nog apps kunnen aanbieden zonder Mac en we zijn er!

[MiesvanderLippe]

Dit heeft niet zoveel te maken met Cacao of de andere iOS / MacOS frameworks. Laat staan dat er een iOS emulator/debugger is voor Windows. Je kan de taal gebruiken, maar net als dat C# niet gebruikt wordt voor MacOS / Linux apps schiet je hier niet zoveel mee op.

[StefanJanssen]

C# word wel degelijk gebruikt voor MacOS en Linux apps?

[twilex]

Waarom het vraagteken?

[MiesvanderLippe]

Omdat dit het lijstje Mono projecten is met een GUI;

https://www.mono-project....#open-source-applications

[twilex]

Dat verklaart nog steeds niet het vraagteken en het is bovendien onduidelijk waarom je verwijst naar alleen een overzicht van projecten met een GUI.

(Door het vraagteken wordt je post een vraag i.p.v. een stelling.)

[Reactie gewijzigd door twilex op 2 augustus 2024 20:37]

[Immutable]

Allang onderzoek naar gedaan, er is gewoon geen goede GUI toolkit voor C# dat multiplatform is. Niets wat dicht bij QtQuick, Flutter of JavaFX e.d. in de buurt komt.

[StefanJanssen]

Waarom niet? Ik stel hier dat OP het mis heeft, tenzij ik OP niet begrepen heb. Het vraagteken mag, ondanks dat het niet heel gebruikelijk is, gebruikt worden voor statements. Als dit gebruikt wordt houdt dit in dat er iets niet duidelijk is.

[mjz2cool]

https://docs.microsoft.com/en-us/dotnet/core/install/linux
https://www.mono-project.com/

[juiced01]

Dat zou tóp zijn!

[Martinspire]

Kun je inmiddels al met Swift op Windows programmeren om een iOS app te ontwikkelen? Of zit dat nog steeds achter XCode vendor lock-in?

[PdeBie]

Nee dus
Craimasjien in 'nieuws: Programmeertaal Swift verschijnt voor Windows'

[Craimasjien]

Let wel dat je ondanks dit nog steeds geen apps kunt bouwen voor iOS, macOS, watchOS of tvOS. De taal is er, de compiler is er, maar de SDKs/frameworks/libraries voor het ontwikkelen van apps voor Apple's platformen blijft alleen exclusief beschikbaar voor macOS gebruikers.

[Reactie gewijzigd door Craimasjien op 2 augustus 2024 20:37]

[McGraffix]

Ligt het aan mij, of starten de laatste tijd veel artikelen meteen met in-depth beschrijvingen, details en info die wellicht duidelijk is voor een insider, maar minder voor geïnteresseerden? Ik merk dat dan pas in de laatste alinea een introductie van het onderwerp wordt gegeven. Zoals hier: pas aan het eind wordt mij duidelijk wat Swift is en staat er enige achtergrond-info. Tuurlijk, leuk als je dat al wist, maar niet iedereen is breed belezen en er zijn genoeg newbies en tech-volgers die niet 'diep' in de IT zitten. Kan Tweakers dat omdraaien of in ieder geval een beetje op letten, aub? Dank 😊!

[Jogai]

Onderdeel van de nieuwe koers, zie plan: Tweakers en Hardware Info bundelen krachten, voor de echte techliefhebber

[McGraffix]

Die bundeling is prima - ik lees Hardware Info ook dagelijks - maar 'liefhebber' staat voor mij niet gelijk aan 'specialist'. Het gaat mij meer om duidelijkheid. Kijk, als ik al iets over een onderwerp weet lees ik ook wel door, maar niet iedereen weet alles over alles. Een goed artikel introduceert het onderwerp eerst, al is het summier, en gaat dan verder met de details/het nieuws/ de diepte in. Dat bedoelde ik

[WWJD]

In de titel staat ook al wat Swift is
Juist die extra diepgang maakt het een fijn artikel..

[TweakerVincent]

Ik hoef echt geen alinea waarin uitgelegd wat Swift is. Blij dat dat niet gebeurd.

[ATS]

Je zou gebruik kunnen maken van die stippeltjes-onderstreep functie die Tweakers heeft voor uitleg, of inspiratie opdoen bij De Correspondent die uitvouwbare secties heeft die extra uitleg geven. Onderbreekt je verhaal niet, maar geeft wel meer uitleg of details voor wie dat wil.

[TweakerVincent]

Zoiets zou mooi zijn idd!

[Anoniem: 428562]

Source code staat op github maar helaas geen binary.

Weet iemand hoe groot deze calculator binary is ?

[BikkelZ]

Ik sta niet te trappelen om met cross-platform Swift aan de gang te gaan. Het is een fijne taal om redelijk performante en correcte code te schrijven maar het is allemaal erg op Apple gericht. Persoonlijk zou ik C# gebruiken aangezien dat gewoon meer tractie heeft door middel van .Net Core, Xamarin en Unity. Je mist natuurlijk een hoop leuke dingen uit Swift en nullability support is er maar een beetje aan vast geprutst maar je kunt best veel code delen tussen projecten zonder enorm rare dingen te hoeven doen. En ik vind dat je voor je front-end code sowieso gewoon native moet gaan.

[mutley69]

Dit lijkt me een correcte formulering - waarbij ik bedenk dat je dan beter geen swift gaat gebruiken. U sluit uzelf daardoor meer op in één enkel platform. Ik heb daar ooit collega's voor gewaarschuwd - en die bleven op een 4GL-platform - dat ineens omschakelde van ondersteuningsOS - ze lieten één platform vallen. Het gevolg was een ramp. Einde ontwikkeling.