Eine App für alle Plattformen - was bedeutet es für die Apple-Welt, wenn wirklich Super-Universal-Apps kommen?
Keine Hybrid-Oberflächen zu erwartenWer seine App darauf auslegt, dass es eine Mac- und eine iOS-Version gibt, kann jetzt bereits große Teile des Codes unverändert lassen. Wirklich aufwändig ist die Entwicklung des plattformspezifischen UI-Codes, damit die Mac-App eben wie ein Mac-Programm aussieht, wohingegen die iOS-Version per Touch und auf kleineren Displays bedient wird. 1:1 Oberflächen zu übernehmen funktioniert normalerweise nicht - Mac und iPad können sich noch in gewissen Bereichen Oberflächen teilen, Mac und iPhone (oder oft auch iPad und iPhone) bringen jedoch andere Anforderungen mit.
Apple ist sich der Tatsache bewusst, dass unterschiedliche Plattformen auch unterschiedliche Programmoberflächen benötigen. Apple-Programme, die es für Mac und iOS gibt, weisen jeweils plattformspezifische Oberflächen auf. Wenn Apple tatsächlich Vorkehrungen zur einfache(re)n Entwicklung von Hybrid-Apps trifft, wird mit höchster Wahrscheinlichkeit nicht einfach das weitgehend identische Interface ausgespuckt. Darunter litte die Qualität von Software so stark, dass auch der Plattform an sich Schaden zugefügt würde.
Unserer Auffassung nach wird Apple den Weg gehen, dass sich ein Framework stärker als bislang um die Oberfläche der App kümmert und dem Entwickler viel mehr abnimmt. Ein Ansatz wäre, dass der Oberflächencode eher beschreibend arbeitet - und die UI-Elemente dann je nach Plattform sinnvoll platziert werden. Pixelgenaue Positionierung wäre nicht mehr Aufgabe des Entwicklers, stattdessen muss er festlegen, was die Funktionen, Aktionen und Werkzeuge sind und wie die Priorität geartet ist (was also immer bereitstehen muss und was nicht immer zu erscheinen hat). Apple setzt intern bereits auf das noch nicht öffentlich verfügbare "UXKit" - möglicherweise ist dies Grundlage kommender UI-Frameworks.
Neue UI-Frameworks wären an der ZeitDie Cocoa-Klassen zur Programmierung der Benutzeroberfläche auf dem Mac stammen noch aus NeXT-Zeiten. Das Alter ist nicht per se schlecht, allerdings wurden diese Klassen über die Jahre häufig angepasst, um neue Funktionalitäten und Darstellungsformen zu ermöglichen. So erweiterte Apple beispielsweise Buttons („NSButton“) um mehr und mehr Stile - entfernte gleichzeitig ältere Stile nicht, so dass es dort für Entwickler schwer zu erkennen ist, welche Stile eigentlich noch verwendet werden können. In der Knopf-Klasse finden sich zum Beispiel immer noch viele Funktionalitäten, die auf Apples mit 10.3 eingeführten und mittlerweile wieder eingestellten Brushed-Metal-Look hinweisen. Die Klassen sind enorm angeschwollen und schleifen viele Altlasten mit.