Apple fastholder kursen på “Liquid Glass” – men kravet er endnu ikke officielt
Et nyt referat fra en Apple-udviklerworkshop peger på, at Apples “Liquid Glass”-designsprog ikke bare er kommet for at blive, men kan blive et krav for apps, når næste store værktøjskæde (Xcode) rammer en kommende generation af iOS.
Det er vigtigt, fordi designkrav fra Apple hurtigt kan flytte hele økosystemet: Fra hvordan tredjepartsapps ser ud, til hvor meget arbejde der skal lægges i at holde UI’et “platform-native”. Men lige nu er der en afgørende detalje: Påstanden er ikke en offentlig Apple-melding, og navngivningen (iOS 26/27 og Xcode 27) kan ikke bekræftes som officiel i Apples nuværende produktlinje.
Hvad der bliver påstået
Ifølge AppleInsider bygger historien på en gengivelse af en Apple Developer-workshop, hvor budskabet skal have været, at udviklere vil blive pålagt at bruge “Liquid Glass”, når en fremtidig Xcode-version (kaldet “Xcode 27” i historien) lanceres. Logikken er klassisk Apple: Når designretningslinjer først er sat, bliver de typisk forstærket over et par års værktøjs- og OS-opdateringer, indtil de bliver standarden, man ikke længere kan vælge fra.
Det matcher også et kendt mønster: Apple kan justere API’er, templates og standardkontroller i Xcode/SwiftUI, så de “rigtige” UI-komponenter bliver lettest at bruge – og de gamle veje bliver gradvist mere besværlige (eller ender med at udløse App Store-advarsler, hvis man går for langt).
Det vi kan faktatjekke – og det vi ikke kan
Historien omtaler “iOS 26” som lanceret ved WWDC 2025 og “iOS 27” som næste skridt. Apple har historisk brugt fortløbende versionsnumre (iOS 17, iOS 18 osv.), og der er på nuværende tidspunkt ikke en bredt bekræftet, officiel Apple-kommunikation, der validerer et spring til “iOS 26” eller navnet “Liquid Glass” som et officielt, brandet designsprog på iOS.
Derfor bør læserne behandle disse navne som enten en fejlcitering, intern jargon eller en spekulativ/alternativ navngivning i kilden – ikke som verificerede Apple-fakta. Tilsvarende kan vi ikke bekræfte, at Apple har meldt offentligt ud, at et bestemt visuelt designsprog bliver “mandatory” i en specifik iOS-version.
Det mere robuste takeaway er derfor: Apple ser ud til at ville stramme grebet om et nyt, mere transparent/glas-agtigt UI-udtryk i sine nyere designs – og det kan få konsekvenser for tredjepartsudviklere, hvis værktøjerne og App Store-krav skubber dem i den retning.
Hvad betyder det for udviklere og brugere?
Hvis Apple ender med at gøre et nyt designsprog reelt obligatorisk, vil det især kunne mærkes på to områder:
For udviklere: Mindre frihed til at afvige fra systemets look-and-feel uden ekstra arbejde. Apps, der har bygget stærke, unikke designidentiteter, kan blive presset til at “ligne iOS” mere – eller betale prisen i form af flere specialløsninger, custom controls og mere testarbejde.
For brugere: Mere ensartet UI på tværs af apps (typisk en Apple-fordel). Men også en risiko for, at den visuelle “glas”-æstetik bliver overbrugt, hvilket kan påvirke læsbarhed, kontrast og tilgængelighed – især hvis gennemsigtighed og blur prioriteres over klarhed.
💡Pro TipTjek “Reduce Transparency” under Indstillinger > Tilgængelighed > Skærm og tekststørrelse: Hvis et glas-agtigt UI bliver mere udbredt, kan den indstilling hurtigt gøre apps mere læsbare.
Min vurdering
Det mest interessante her er ikke ordet “mandatory”, men mekanismen. Apple behøver sjældent at udstede et enkelt, hårdt ultimatum. De kan i stedet gøre det nye design til default i SwiftUI, gøre systemkontrollerne mere “opinionated”, og belønne den, der følger med, med mindre vedligeholdelse.
Hvis denne workshop-gengivelse er korrekt, lyder det som et signal til udviklere om at stoppe med at vente på en retræte og i stedet planlægge migreringen. Men indtil Apple selv dokumenterer et krav i officielle guidelines eller release notes, bør det behandles som et velinformeret rygte – ikke en endelig dom.
Hvad du skal holde øje med
De konkrete indikatorer kommer typisk i tre former: opdaterede Human Interface Guidelines, nye standardkomponenter i SwiftUI/UIKit, og ændringer i App Store Review (f.eks. hvis Apple begynder at afvise UI, der “føles” for langt fra platformens normer). Når de tre peger samme vej, er retningen sjældent til at misforstå.
