iOS 14: Xcode auf dem iPad und iPhone?

Apples Entwicklungsumgebung Xcode steht nur für den Mac bereit. Will man Apps für iPhone, iPad, Mac, Watch oder Apple TV programmieren, benötigt man zurzeit zwingend einen Mac. Auch mit einem Windows-PC kommt man nicht weit, da Apple Xcode nur für macOS anbietet – es handelt sich um eine in Cocoa geschriebene Mac-App und ist nicht als Cross-Platform-Projekt angelegt. Zum Hineinschnuppern in die Welt des Programmierens bietet Apple die App "Swift Playgrounds" auf dem iPad und neuerdings auch auf dem Mac an – dies ist aber keine vollwertige Programmierumgebung, sondern ein Lern-Programm.


Jon Prosser, welcher in der Vergangenheit zahlreiche neue Entwicklungen aus dem Hause Apple korrekt vorhersagte, traf nun über Twitter eine neue Prophezeiung: In iOS 14 wie auch iPadOS 14 finden sich Hinweise auf Xcode. Prosser schreibt, dies sei ein starkes Indiz, dass mehr und mehr Pro-Apps ihren Weg auf das iPhone oder iPad finden werden – auch wenn er selbst nicht ganz an Final Cut Pro auf dem iPad glaubt:


Bereits mit iOS 13 glaubten manche, dass Apple eine Xcode-Variante für iOS vorbereitet – doch bei der gefunden App handelte es sich um ein kleines Helfer-Programm, welches Xcode benötigt, wenn ein Programm vom Mac aus getestet wird. Bei dem jetzigen Fundstück in iOS 14 soll es sich aber um etwas anderes handeln, so Prosser – er gibt zusätzlich an, über noch weitreichendere Informationen zu verfügen, welche er zurzeit noch nicht öffentlich machen will.

Xcode auf dem iPhone?
Apples Programmierumgebung ist, wie die meisten Programme zum Entwicklen von Software, sehr komplex und benötigt große Bildschirme, um vernünftig damit arbeiten zu können. Daher ist Prossers Aussage, dass Xcode in iOS 14 für das iPhone vorhanden ist, erst einmal schwer zu glauben. Schon Swift Playgrounds veröffentlichte Apple nur für iPad und Mac, da auf dem kleinen iPhone-Bildschirm das Bearbeiten von Text nur mit Mühe möglich ist.

Momentan ist es eher wahrscheinlich, dass es sich bei den Fundstücken um neue Hilfsprogramme handelt, welche zur Unterstützung von Xcode auf dem Mac gedacht sind – und nicht um ein vollwertiges Xcode.

Kommentare

Raziel121.04.20 08:46
Das wäre für mich die vermutlich größte und interessanteste Neuerung. Ich würde es vermutlich nur privat verwenden, denn beruflich habe ich sowieso schon mein Equipment. Privat allerdings fehlt oft die Motivation mich noch extra zu Hause an den Rechner zu setzen wenn man sowieso schon den ganzen Tag davor sitzt, obwohl ich noch viele Ideen hätte für Apps. Xcode am iPad würde das wohl ändern. Da ich privat sowieso kaum mehr mein Macbook verwende, sondern lediglich iPad und iPhone, wäre das genau das fehlende Puzzleteil für mich.


kann mir gut vorstellen das es eine spezifisch für Swift/SwiftUI optimierte Xcode Variation ist, welche sich an Playgrounds orientiert. Also keine Xcode per se, sondern eine eigene Entwicklung für das iPad. Eventuell stellt sich aber auch nur raus das es ein Programm für das Interface erstellen mittels SwiftUI ist ud man damit eventuell per Drag&Drop was zusammenbaut, aber nie vollwertige Apps damit erstellen wird
+4
LoCal
LoCal21.04.20 08:50
Mir seiner Schreibweise von Xcode sollte er sich aber nicht in bestimmten Entwicklerforen blicken lassen

Auf Xcode auf dem iPad würde ich mich sogar freuen. Seit SwiftUI hatte ich schon mit dem Gedanken gespielt statt einem 16” lieber das kleinere MBP zu nehmen.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+4
Raziel121.04.20 08:53
LoCal
Mir seiner Schreibweise von Xcode sollte er sich aber nicht in bestimmten Entwicklerforen blicken lassen

Auf Xcode auf dem iPad würde ich mich sogar freuen. Seit SwiftUI hatte ich schon mit dem Gedanken gespielt statt einem 16” lieber das kleinere MBP zu nehmen.

Ja absolut. Der Bildschirmbedarf ist doch irgendwie durch den Ersatz der Storyboard massiv gesunken. SwiftUI habe ich sowieso lieben gelernt, so schnell wie man da komplexere Layouts mit Animationen und Interaktionen erstellt, da will ich garnicht mehr zurück ^^
+2
dan@mac
dan@mac21.04.20 10:03
Warum sollte es mehr Pro Apps geben, nur weil man diese dann auf dem iPad direkt statt auf einem Mac entwickeln kann? Macht doch gar keinen Sinn...
+1
ApfelErik21.04.20 10:12
dan@mac
Warum sollte es mehr Pro Apps geben, nur weil man diese dann auf dem iPad direkt statt auf einem Mac entwickeln kann? Macht doch gar keinen Sinn...

Er meint wahrscheinlich, dass Xcode jetzt den Anfang macht und dann weitere „Pro“ Apps, beispielsweise Logic Pro, folgen könnten. Hoffentlich behält er damit recht 😃
+3
milk
milk21.04.20 10:12
Raziel1
SwiftUI habe ich sowieso lieben gelernt, so schnell wie man da komplexere Layouts mit Animationen und Interaktionen erstellt, da will ich garnicht mehr zurück ^^
Zumindest nicht, solange man in der Hello-World-Phase ist. Wenn man sehr spezifische Sachen umsetzen will, dann stößt man doch recht schnell an die Grenzen von SwiftUI. Die Implementierung von UINavigationController war beispielsweise so wacklig, dass wir (Firma) zu UIKit zurückgekehrt sind. Aber in ein, zwei Jahren wird SwiftUI sicher ein ziemlicher Knaller sein.
-1
Raziel121.04.20 11:15
milk
Raziel1
SwiftUI habe ich sowieso lieben gelernt, so schnell wie man da komplexere Layouts mit Animationen und Interaktionen erstellt, da will ich garnicht mehr zurück ^^
Zumindest nicht, solange man in der Hello-World-Phase ist. Wenn man sehr spezifische Sachen umsetzen will, dann stößt man doch recht schnell an die Grenzen von SwiftUI. Die Implementierung von UINavigationController war beispielsweise so wacklig, dass wir (Firma) zu UIKit zurückgekehrt sind. Aber in ein, zwei Jahren wird SwiftUI sicher ein ziemlicher Knaller sein.

Also wir bauen hier aktuell ne umfangreiche App und haben bisher keine Probleme. Im Gegenteil, alles geht extrem schnell. So schnell das ich mir hier oft direkt das erstellen von Prototypen/Designvorlagen spare, weil ich schneller bin es direkt in SwiftUI zu testen und dann anderen für Feedback zur Verfügung zu stellen. Klar gibt es immer mal irgendwelche Merkwürdigkeiten, aber die gab es auch noch all den Jahren gleichfalls beim Storyboard bzw den bisherigen Wegen.

Storyboards etc war man halt schon gewohnt. Komische Verhaltensweisen kannte man und dachte auch nicht mehr groß darüber nach. Jetzt ist halt alles neu. Umgekehrt würden wahrscheinlich viele das selbe über die bisherigen Methoden sagen. Klar das eine oder andere gibt es noch nicht bei SwiftUI, wie die Collection View. Aber andererseits ist SwiftUI ja so konstruiert, dass man alle bisherigen Views ganz normal verwenden kann. Im Fall der Collection View kann diese halt dann wie bisher erstellt und in SwiftUI verwendet werden.

Unsere bisherige Erfahrung ist jedenfalls, das es bereits jetzt problemlos einsetzbar ist und es vieles deutlich beschleunigt hat. Aber je nach dem, was man macht kann die Erfahrung natürlich abweichen. Da SwiftUI aber UIKit quasi normal mitnimmt, gibt es nichts auf das man verzichten muss und hat die Vorteile beider Welten.
+1
Bananenbieger21.04.20 12:01
milk
Zumindest nicht, solange man in der Hello-World-Phase ist. Wenn man sehr spezifische Sachen umsetzen will, dann stößt man doch recht schnell an die Grenzen von SwiftUI. Die Implementierung von UINavigationController war beispielsweise so wacklig, dass wir (Firma) zu UIKit zurückgekehrt sind. Aber in ein, zwei Jahren wird SwiftUI sicher ein ziemlicher Knaller sein.
Zumindest unter watchOS ist SwiftUI ein Segen und ermöglicht viele Dinge, die mit WatchKit überhaupt nicht zu realisieren waren.
+1
milk
milk21.04.20 12:06
Bananenbieger
Zumindest unter watchOS ist SwiftUI ein Segen und ermöglicht viele Dinge, die mit WatchKit überhaupt nicht zu realisieren waren.
Spannend! Was denn zum Beispiel?
0
LoCal
LoCal21.04.20 14:22
milk
Zumindest nicht, solange man in der Hello-World-Phase ist. Wenn man sehr spezifische Sachen umsetzen will, dann stößt man doch recht schnell an die Grenzen von SwiftUI. Die Implementierung von UINavigationController war beispielsweise so wacklig, dass wir (Firma) zu UIKit zurückgekehrt sind. Aber in ein, zwei Jahren wird SwiftUI sicher ein ziemlicher Knaller sein.

Ich finde solche Vorhaltungen ja immer sehr … peinlich.

Wir bauen sehr komplexe UIs mit SwiftUI und waren in UIKit wahre Monster, mit SwiftUI ist wurde alles wesentlich schlanker und vor allem verständlicher. Das Nichtvorhandensein von einem äquivalent zu CollectionViews sehe ich als grosses Problem, ansonsten ist SwiftUI sehr weit ausgereift.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
milk
milk22.04.20 11:36
LoCal
Das Nichtvorhandensein von einem äquivalent zu CollectionViews sehe ich als grosses Problem, ansonsten ist SwiftUI sehr weit ausgereift.
Ich habe mich vor kurzem mit zwei Apple-Entwicklern aus dem SwiftUI-Team unterhalten. Sagen wir einfach, die beiden teilen deine Einschätzung nicht. Und erzählten auch, dass SwiftUI durch Druck des Managements veröffentlicht wurde, während es intern bestenfalls ein Alpha-Release war. Was man ja auch daran sehen konnte, dass keine drei Monate nach der WWDC die Session-Videos wertlos waren, weil sich die APIs geändert hatten. Sie rieten von der Verwendung bis auf weiteres ab.

Du magst das gern "... peinlich" finden, ich bin seit dem Ärger mit den immer wieder inkompatiblen Swift-Versionen sehr vorsichtig mit neuem Zeug von Apple. Mein Arbeitgeber sieht das zum Glück genauso, passt also ganz gut.

Und wenn es irgendwann ausgereift ist, dann werden wir das auch einsetzen, aber halt nicht vorher.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.