Microsoft spoort ontwikkelaars aan om UWP-apps naar Windows App SDK te migreren

Microsoft spoort UWP-ontwikkelaars aan om hun apps om te zetten naar het nieuwe Windows App SDK-platform. Dat blijkt uit een supportpagina waarin de fabrikant de nieuwe functies van Windows App SDK uitlicht en het migratieproces uitlegt.

Op de webpagina legt Microsoft uit op welke manier Universal Windows Platform-apps om te zetten zijn naar het Windows App SDK-platform en welke voordelen daaraan verbonden zijn. Apps die werken met het Windows App SDK beschikken volgens het bedrijf onder andere over het laatste user interface-platform, zijn backwards compatible tot en met Windows 10 versie 1809 en ondersteunen het .NET 5-framework.

Programma's die gebruikmaken van de Windows App SDK bieden volgens Microsoft een 'consistentere ervaring' op verschillende versies van Windows en beschikken over een verbeterde runtime environment. Volgens ontwikkelaar Rafael Rivera zal de UWP-sdk in de toekomst enkel nog bugfixes krijgen en beveiligingsupdates, al is dit nog niet bevestigd door Microsoft.

Reacties (44)

Dit is waarom niemand Windows 'apps' maakt, en het bij de klassieke vorm houdt...

Windows ce -> Windows Phone, complete rewrite/fix
Windows phone -> UWP, complete rewrite/fix
UWP -> Windows App SDK, complete rewrite/fix

Je oude apps blijven wel werken (zolang 't OS ondersteund is) maar constant alles herschrijven is vermoeiend...

[Reactie gewijzigd door ManIkWeet op 19 oktober 2021 13:57]

Herschrijven gaat in sommige gevallen niet eens werken.

Daarnaast zegt de documentatie van Microsoft ook nog eens:

Today in version 1.0 of Windows App SDK, launch speeds, RAM usage, and installation size of WinUI 3 apps are larger/slower than seen in UWP. We are actively working to improve this. We will have more information to share in the future.

Iedere major Windows een nieuwe API is waarom Windows Mobile flopte (naast dat ze veel te langzaam waren omdat ze iPhone en Android niet als concurrent zagen, natuurlijk). Ik ben al enigszins blij dat Windows 11 niet met een nieuwe SDK komt, maar ik mag toch hopen dat UWP de komende tien jaar nog wel draait op moderne versies van Windows.

En ook dit is typisch van Microsoft:

Je krijgt het advies om van 1 API/Framework te switchen naar een ander, nieuwer en beter API/Framework (zeggen ze). Alleen om erachter te komen dat die nieuwe API nog niet compleet is, en dat daardoor sommige dingen nog niet gesupport worden of slechter werken.

Met een beetje pech hebben ze dan ook de eerste API ook al uitgeschakeld
Op Azure / Office 365 is dit heel erg aan de hand.

[Reactie gewijzigd door TazzyD op 19 oktober 2021 14:57]

Ik heb hier dus totaal geen verstand van. Maar vind dit wel interessant. Zij weten toch ook dat wat jij aanhaalt totaal niet wenselijk is voor ontwikkelaars. Wat is dan de achterliggende reden? Gebrek aan visie / strategie of management?

Hoe gaan Google en Apple om met dit soort dingen? Doen zij dit beter?

Hoe gaan Google en Apple om met dit soort dingen? Doen zij dit beter?

In het kort, ja

Maar je kan het ook niet helemaal vergelijken. Windows kan je wel vergelijken met Mac OS in de zin van het is heel oud, kan 1000e dingen en dat moet je dus allemaal in een nieuw jasje gooien. Volgens mij heeft Apple daar 2 momenten gekozen, namelijk de overstap van powerpc naar intel en van intel naar hun zelf ontwikkelde chip. Wat ik daar gaaf aan vind is dat ze daar nogal een big bang aanpak kiezen. Omdat Windows door veel meer software wordt gebruikt is het vergelijken relatief lastig.

Op het vlak van iOS en Android is het heel anders, die ziin nieuw en daar zag je vooral in het begin dat ze niet heel veel functionaliteit bood. Dus ook minder impact bij grotere veranderingen. Ben dus heel benieuwd hoe grote veranderingen daar gaan werken als de OS's ouder worden.

In het kort, ja

Nee, google doet het echt lang niet altijd beter. Zeker op het gebied van APIs voor google diensten kan je met enige regelmaat een nieuwe versie van de api verwachten die niet backwards compatible is en waar je toch naar toe moet migreren. Hier een mooi artikel er over van een ex-google medewerker.

Andere google producten doen het dan wel weer beter, maar het verschilt eigenlijk heel erg van welke google afdeling ze afkomen. Maar zonder meer stellen dat Google het beter doet zou ik zeker niet doen, het is eerder meer pure willekeur.

Microsoft's Windows divisie heeft inderdaad geen visie.

Maar ja, hoe je het ook bekijkt, de Windows divisie is een goedlopende geldkraan voor Microsoft, het geld blijft lekker stromen, ongeacht hoe slecht Microsoft het doet met Windows. Niemand gaat toch de moeite nemen om Linux te installeren, helemaal niet nu Linux met Windows bijgeleverd gaat worden in vorm van WSL.

Windows Store was een plaats voor betrouwbare, veilige UWP en WinJS apps, met 1 klik verwijder je de apps en niks blijft over. Maar nu is de Windows Store een twijfelachtige plek om software te vinden met Win32 legacy meuk, wat full system capabilities heeft.

Dit zijn de apps wat gebruikers niet eens op hun computer willen hebben.

Developers kunnen updates pushen naar je Win32 apps buiten de Microsoft store, met vervelende uninstallers en log files en andere mappen wat achtergelaat worden. En dan heb ik niet eens over mogelijke kwade bedoelingen met Win32.

Met deze visie gaat Microsoft never nooit een succesvolle Windows Store opzetten dat gelijk is aan Apple's App Store en Google's Play Store. En mogelijk zijn Amazon's Android apps op Windows veiliger zelfs dan Win32 apps, we zullen zien.

[Reactie gewijzigd door Qws op 19 oktober 2021 18:33]

Ik ben ook absoluut kwijt wat er aan ontwikkel kits zijn voor windows.
is Windows App SDK nieuw? Hoe is de relatie met .Net en native win32/64? Welke tools moet je hiervoor hebben?

32bit... Moeten we dat nog willen? Wordt het niet tijd dat 100% alleen 64bit gaan ondersteunen zodat op cpu niveau ook al die oude instructiesets de deur uit kunnen en ruimte kunnen maken voor nieuwe dingen?

Moeten we dat willen? Als je een set native api gaat ondersteunen wellicht wel, maar enkel als dat van toepassing is. Voor 95% van je apps maakt het geen ruk uit waarin ze draaien, maar de overige 5% wil je juist wel op optimale perfomance draaien of op een zo groot mogelijk aantal devices. En dan wil je wel snappen welke platformen er zijn.

UWP/Metro was ook vanaf het begin al een misgeslagen plank vond ik. Helemaal all-in op touch met tablets en mobiel, een markt waar MS heel zwak in is, terwijl het de eisen van de desktop markt links liet liggen, waar ze juist zo afhankelijk van zijn. De UWP apps die er zijn gekomen voor de desktop waren nogal inefficient voor het schermgebruik, uitgebreide functies weggelaten a la mobiele appjes enz. Uiteraard was hun doel het uitbreiden van die invloed op de mobiel/tablet markt maar daarmee gelijk de desktopgebruikers een dikke middelvinger geven was niet bepaald slim.

Het was een beetje alsof je stamkroeg besluit dat al die vieze alcohol niks meer is en alleen nog maar alcoholvrij bier inkoopt, 'want de moderne man drinkt geen alcohol meer en dit wordt de nieuwe rage'. Je kan nergens anders naartoe want al je kennissen komen er ook. Af en toe komt er een hipster binnen die het naar zijn zin heeft maar voor de rest heeft iedereen de pleuris in. Wat keus erbij voor alcoholvrij was prima geweest maar alles omgooien niet.

Dat startscherm van W8 was ook zo'n voorbeeld van die tablet push, echt waardeloos op de desktop. Ik ben blij dat UWP nu het veld moet ruimen en dat er weer meer aandacht is voor de desktop/laptop. Ik vond Windows 11 eindelijk een redelijk doordachte UI hebben (alhoewel het jammer is dat je overal nog 'Windows 95 stijl' schermpjes tegenkomt).

Ik zie nu op het werk ook dat we heel veel vrijwilligers hebben die Windows 11 willen testen voor hun werk, terwijl met dat met Windows 8 amper konden vinden. Die is bij ons ook nooit in produktie gegaan. we hebben de hele 8/8.1 cyclus overgeslagen en zijn op 7 blijven hangen tot 10 kwam.

Het zou me niet verbazen als developers hier nu eens wel op in gaan stappen omdat ze niet meer een magische eenhoorn najagen maar werken aan dingen die mensen echt nodig hebben.

[Reactie gewijzigd door GekkePrutser op 19 oktober 2021 19:03]

Uiteindelijk hadden ze wel een mooi systeem in UWP bedacht om verschillende schermformaten goed te ondersteunen, nadeel was dan wel weer dat... Je raad het al... Je je hele ui mocht herschrijven (in XAML, wat een andere was dan de desktop versie, dus alles van stackoverflow.com werkt niet)

Persoonlijk ben ik niet overtuigd van de ui in w11...

• Een simpeler contextmenu in explorer waarin niet eens bijvoorbeeld "edit with notepad++" in staat; extra klik
• startmenu waarin je niet gelijk al je apps krijgt, maar gepinde; extra klik
• taakbalk waarin je niet langer labels van programma's kan tonen, en alle schermen van een programma onder 1 knop vallen; veel extra kliks

Lijkt me ook een hoop tablet achtig simplificatie van de ui; settings daarentegen is wel sterk verbeterd!

Vergeet niet Windows Phone 7 -> Windows Phone 8 rewrite.

Vergeet niet dat Windows 8 UWP en Windows 10 UWP niet hetzelfde zijn...

Is het Windows App SDK-platform niet gewoon een major update (lees: evolutie) van het UWP platform? Dan is het toch logisch dat de meeste apps hierin worden omgezet?

Het is inderdaad vrij normaal. Wanneer je dependencies naar een nieuwe major version gaan bevatten ze vaak breaking changes.
De enige manier waarop je er geen werk aan hebt is door de dependencies niet te onderhouden, echter is dat ook een kwalijke zaak.

Of gewoon tegen de win32 api aan programmeren. Die is zo stabiel dat zelf bij een upgrade van je complete OS je applicatie gewoon nog werkt. Er is teveel tegen de win32 api aangeprogrammeerd dat MS het niet eens durft hier breaking changes in te doen.

Maar zonder hulpmiddelen (zoals C++Builder of WxWidgets) is dat behoorlijk arbeidsintensief.

Je applicatie ieder jaar herbouwen tegen de smaak du jour die MS adviseert is een stuk duurder, nog los van de skillset die je steeds moet aanpassen/uitbreiden zonder daadwerkelijk iets toe te voegen voor de eindgebruiker.

Correct. Microsoft heeft een voorkeurs-API die elke zoveel tijd weer verandert, en Win32. Win32 is waarmee ze bedrijven vasthouden; breek dat en bedrijven gaan serieus naar Linux kijken. Dat maakt Win32 dus ook het betrouwbare platform voor software development.

Idealiter zorg je dat het ook op Wine draait. Dat is een grote subset van de Win32 API; als je programma daar ook draait dan heb je geen subtiele dependency op een ongedocumenteerd detail van de Windows 10 implementatie. Als WIndows 10 en Wine het eens zijn, dan zal Windows 11 óók zo werken.

Dat is een manier om er naar te kijken.

De Win32 APIs hebben wel degelijk bij nieuwe versies van Windows breaking changes gehad. Echter bouwt Microsoft dan weer thunks en dergelijke om alle applicaties werkend te houden. Aangezien zij aan het einde van de dag er op aangekeken worden.

Het is wat werk wat ontwikkelaars moeten verzetten, hier resources aan spenderen is niet altijd logisch.

Ja, was benieuwd naar hoeveel veranderingen dit meebrengt? Is het een makkelijke migratie, of is het een halve app rewrite?

UWP was origineel op COM gebaseerde C++ gebaseerde WinRT, pas na veel vijven en zessen kwam er .NET bij.

Windows App SDK is blijkbaar .NET 5

Wat denk je zelf

[Reactie gewijzigd door marcovtjetje op 19 oktober 2021 15:13]

na 6 jaar vanaf de release (https://en.wikipedia.org/wiki/Universal_Windows_Platform) laat windows uwp weer los of lees ik dit verkeerd en is WinApp de nieuwe UWP /opvolger

en wat heeft dit er mssn mee te maken
nieuws: Beveiliging voor Windows 10 UWP-apps is mogelijk gekraakt - update

[Reactie gewijzigd door xtrme op 19 oktober 2021 13:36]

Het is inderdaad een opvolger met wat breaking changes. Wat exact UWP is was niet helemaal duidelijk, omdat het verschillende componenten waren met verschillende talen en UI frameworks.

Windows App SDK zijn apps die:
- Gebruik maken van WinUI
- Werken met de WinRT runtime in C#, C++ of Rust
- Gedistribueerd worden in MSIX formaat, voor Windows Store of gewoon los

Het zijn meer dan alleen die drie programmeertalen, toch? Volgens mij is de reden dat Microsoft per taal een wrapper kan genereren voor WinRT namelijk dat ze willen dat zo'n beetje elke programmeertaal gebruikt kan worden.

Het lijkt me wel geinig een keer met Rust te experimenteren met WinRT, al denk ik dat de toolchain lang niet zo goed zal werken als de Visual Studio (niet-code) toolchain. Ik vraag me af hoeveel partijen daadwerkelijk native code schrijven op WinRT aangezien C# snel genoeg is voor de meeste applicaties. Misschien dat het nuttig is om zware berekeningen naar native code te sturen, maar de WinRT API heb je daar volgens mij niet voor nodig.

Voor zover ik weet lijkt WinRT een beetje op (latere) DirectX, COM objecten.

Maar je moet natuurlijk wel een linker en runtime hebben die dat platform aankon. Veel animo om zo'n beesten te maken was er niet omdat je het resultaat niet zomaar kan gebruiken, als bij win32. of .NET.

Het moet gesigned worden (MSDN abbonement voor nodig?) en dan via de store of op een complexe gesideload worden.

n.b. ik heb er in win8 tijden eens naar gekeken, kan zijn dat het inmiddels losser is.

Lijkt me stug dat je nog een abonnement nodig hebt. Volgens mij was mijn account een eenmalige betaling van iets van €12.

De optie van sideloading bestaat nu ook niet meer, wat betekend dat je ze gewoon buiten de store om kunt distribueren zonder problemen. Voorheen moest daarvoor een OS instelling gewijzigd worden. Codesigning is dan nog wel nodig, maar voor die eenmalige €12 is dat ook geen punt.

[Reactie gewijzigd door Wolfos op 19 oktober 2021 16:10]

Google is degene die je destijds eenmalig voor een tientje toegang gaf tot de store, maar voor MS is dat iets complexer. Als bedrijf betaal je namelijk +/- $99, als onafhankelijke ontwikkelaar betaal je $19. Ook draag je vijf procent van je omzet af aan Microsoft (een redelijk bedrag vind ik zelf, helemaal in vergelijking met Google en Apple's 15% of 30%). Buiten de store om (als je het voor elkaar krijgt) gaan die prijzen natuurlijk niet op, maar dan moet je alsnog je code laten signen en installatie van appx/wsix-bestanden is moeilijker dan het openen van een .exe.

Eerlijk gezegd vind ik het onzin dat ik zou moeten betalen om een app te laten signen door Microsoft, net als ik het onzin vindt dat Apple dat vereist bij hun store. Als ik op compile druk en er een appx of wsix wordt uitgepoept, wil ik dat met een dubbelklik op andere PC's kunnen draaien zonder accounts en signing en wat dan ook. De pop-ups ("paniek! komt niet van de store! kijk uit!") zijn nog tot daar aan toe, maar het vereisen van signing voor ieder programma vind ik de grootste onzin. Ik wil geen maaltijd voor meerdere personen kwijt moeten zijn aan het feit dat Microsoft zich de baas over mijn computer acht.

[Reactie gewijzigd door GertMenkel op 19 oktober 2021 17:16]

Eerlijk gezegd vind ik het onzin dat ik zou moeten betalen om een app te laten signen door Microsoft, net als ik het onzin vindt dat Apple dat vereist bij hun store.

Apple vereist dat niet alleen voor hun store. Ook los geinstalleerde pakketten moeten ondertekend en 'genotariseerd' worden door Apple, wat betekent dat je een kopie van je app naar Apple moet sturen en zij er een stempeltje op zetten dat het okee is. Je kan er wel omheen maar het is een hoop gedoe met verborgen klikjes en "ja ik weet het heel erg zeker". Net als op Windows dus. Maar dan niet alleen voor MSIx maar voor alle software.

Er is wat voor te zeggen qua veiligheid, als je op een account malware laat ondertekenen wordt binnen no-time je developer account en al je software geblokkeerd.

Maar ik vind dat ik als bedrijfs admin bijvoorbeeld zelf mijn pakketten moet kunnen tekenen in plaats van het alleen door Apple te kunnen laten doen. Ze hebben nog wel eens een rare reactie op sommige apps die ik instuur terwijl er niks raars in zit. Het blijft een volledig automatische check. En wat ik naar onze eigen computers wil sturen moeten we immers zelf weten.

[Reactie gewijzigd door GekkePrutser op 19 oktober 2021 20:46]

Dat zijn de talen met officiele bindings in ieder geval.

Ik vraag me af hoeveel partijen daadwerkelijk native code schrijven op WinRT aangezien C# snel genoeg is voor de meeste applicaties.

Sterker nog, C# kan native gecompileerd worden. Denk dat dat meer is voor als je al een heleboel native code hebt en daar een frontend voor wil maken.

[Reactie gewijzigd door Wolfos op 19 oktober 2021 14:27]

Klopt volgens mij niet helemaal, als ik https://docs.microsoft.co...ows/apps/windows-app-sdk/ lees kun je van die componenten gebruik maken, maar dat hoeft niet

Ik heb een paar jaar geleden een simpel UWP programma’tje geprogrammeerd (nooit uitgebracht, geen abonnement daarvoor), en heb tot nu toe geen instructies kunnen vinden voor hoe je dat naar WinUI 3 omzet.

Ik snap niet hoe je je serieuze programma’s aan Windows kan toevertrouwen.

[Reactie gewijzigd door novasurp op 19 oktober 2021 22:54]

Ik snap niet hoe je je serieuze programma’s aan Windows kan toevertrouwen.

Ik wel. Dat heet win32. .NET Framework 3.5 en 4.x worden ook nog steeds goed ondersteund, en wijzigen eigenlijk niet meer.

[Reactie gewijzigd door The Zep Man op 19 oktober 2021 17:32]

Win32 api voelt vaak legacy aan.

Veel apps maken gebruik van Win32 api maar dan krijg je de Windows XP applicatie user-experience. Apps wat ongevraagd in de background draait, apps wat zomaar config bestanden in je documenten plaats. Je hebt geen idee wat voor rechten de app heeft.

UWP is veel fijner, als een app geen toegang heeft tot de filesystem of internet, dan weet de gebruiker dat.

Win32 is krachtig en je kan er vrijwel alles mee, maar van de gebruiker perspective is het zeker niet fijn.

Win32 api voelt vaak legacy aan.

Als iemand die enkel Windows aanraakt voor productief gebruik: no problemo!

Inderdaad. Voor applicaties die je niet wilt updaten is .NET Framework nog steeds de beste optie. Deze worden geüpdatet als deel van Windows en er zijn nauwelijks nog veranderingen.

toch wel vreemd dat ze een "consistentere gebruikservaring" denken te bereiken door weer een nieuwe variant te introduceren. Zolang oude meuk niet een update krijgt wordt het IMHO alleen maar rommeliger

inderdaad, zomaar 1 praktijkvoorbeeld: de schizofrene Control Panel schermen

De ellende is dat ze nog steeds niet het voor elkaar hebben om al die functionaliteit onder te brengen in de nieuwe userinterface. Dat is eigenlijk alles wat in de Microsoft Management Interface zit, zoals spullenboel zoals apparaatbeheer, policies, user management, WMI, etc. En dan nog wat andere schermen die men niet heeft kunnen overzetten (om niet te verklaren reden). Ik heb heel veel het gevoel dat ze gewoon niet weten waar ze bij Microsoft mee bezig zijn qua UI. Iedere paar jaar verzinnen ze weer wat, moet alles weer aangepast worden. Ik snap software leveranciers wel, die denken ook laat maar, want over een paar jaar is het vast weer obsolete en dat is de echte reden waarom het maar niet storm loopt met UWP en dadelijk ook Windows App SDK.

[Reactie gewijzigd door captain007 op 19 oktober 2021 15:51]

en dat is de echte reden waarom het maar niet storm loopt met UWP en dadelijk ook Windows App SDK.

, was ook omdat ze Windows Phone gedumpt hadden waardoor UWP zijn soort van multiplatform voordeel verloor (spijtig dat MS het niet wat langer in leven had gehouden nu Surface tablets en touchscreen laptops populairder zijn).

Dat is echt erg, kijk alleen eens naar de stijl van de icons... Van ouderwets-weinig kleuren (= de vergeten applicaties), tot isometrisch-old-school, dan weer plat, tot gedetailleerd en voor de afwisseling minimalistisch. Net alsof de volgende verantwoordelijke "het beter ging doen" (en random 27% van de icons opnieuw heeft gestyled en er daarna geen zin meer in had... of vervangen werd door iemand het het beter ging doen).

Om nog niet te spreken van het feit dat die schermen nu zo belachelijk met zinloze info gevuld zijn dat je als windows2000-windows 7 "poweruser" je te pleuris zoekt waar ze bepaalde features nu weer verstopt hebben. Achja, met windows 11 komt er nog een laag overheen.

Worden de UWP Controls (Richeditbox, Textbox, Polyline etc) ook op de schop gegooid of is dit vergelijkbaar gebleven?

Ben ook wel beniewd hoe dit Xamarin's UWP deel beinvloed.