Xcode 11 vs Xcode 12

[gustavmega]

Hallo,

auf dem MacMini 2012 läuft im Moment MacOS Mojave mit Xcode 11.3.1.
Soweit ich weiß Xcode 12.3 läuft erst ab MacOS Catalina. Und einen Upgrade auf Catalina möchte ich nicht so gerne machen. Meint ihr, dass ein Update auf Xcode 12 nicht unbedingt nötig wäre und kann und soll bei Xcode 11.3.1 bleiben?

 

[oneOeight]

Bleib doch.
Mit jedem Update entfernt Apple auch die Unterstützung für ältere macOS Versionen.
Das 10.15 SDK sollte ja dabei sein.

 

[lisanet]

Mit jedem Update entfernt Apple auch die Unterstützung für ältere macOS Versionen.

man kann ohne Probleme das target-OS in Xcode einstellen. Es ist nicht notwendig ein altes SDK installiert zu haben um für alte OS-Versionen lauffähige Programme zu erstellen.

 

[pmau]

man kann ohne Probleme das target-OS in Xcode einstellen. Es ist nicht notwendig ein altes SDK installiert zu haben um für alte OS-Versionen lauffähige Programme zu erstellen.

Das ist technisch richtig, in der Praxis führt das aber zu Problemen. Mit dem target SDK wird nur eingestellt, welche Funktionen nicht verwendet werden (können).
Das fertige binary enthält aber Code, der auf die neuen Frameworks optimiert wurde.
Die Header Dateien sind nämlich nicht alt und beeinflussen den Code, besonders in Swift.

Das kann man googeln. Es gibt deshalb genug Gründe ein altes macOS mit original passender Xcode Version zu haben. Dann baut man nämlich mit den originalen Frameworks.

https://firefox-source-docs.mozilla.org/widget/cocoa/sdks.html

 

[capmilk]

Es ist auch kein Problem, die SDKs aus alten Xcode-Versionen in ein neues Xcode zu kopieren und dem Xcode dann über eine angepasste plist-Datei zu sagen, dass es diese SDKs gibt. Dann kann man problemlos auch den korrekten Code für ein altes Target SDK erstellen. Ich kenne mehrere Entwickler, die hauptberuflich so arbeiten.

Was die Frage des TE @gustavmega angeht: Wenn du kein neues Xcode brauchst, etwa um neue Devices zu unterstützen, dann kannst du natürlich bei Xcode 11 bleiben. Vielleicht noch zu bedenken: Apple lässt Uploads in den App Store nach kurzer Übergangszeit nur aus aktuellen Xcode-Versionen zu, musst du selber wissen, ob das für dich relevant ist.

 

[lisanet]

Das fertige binary enthält aber Code, der auf die neuen Frameworks optimiert wurde.

optimiert ja, aber weiterhin lauffähig. So what?

Edit:

selbst wenn gegen ein altes SDK gelinkt wurde, wird auf einem neueren System die neuere dylibs verwendet. Es wird also trotz altem SDK der neue Code verwendet. Die "alte" dylib ist ja gar nicht mehr vorhanden auf neueren Systemen. Welchen Vorteil soll es dann bringen?

 

[capmilk]

Welchen Vorteil soll es dann bringen?

Der Vorteil, wenn man gegen ein altes SDK kompiliert, ist dass das entstandene Programm auch auf entsprechend altem MacOS läuft. Solange da keine Sachen verwendet werden, die später von Apple entfernt wurden, läuft das kompilierte Programm in alten und neuen Umgebungen. Für manche Branchensoftware ist das relevant.

 

[lisanet]

Das kann man googeln. Es gibt deshalb genug Gründe ein altes macOS mit original passender Xcode Version zu haben. Dann baut man nämlich mit den originalen Frameworks.

https://firefox-source-docs.mozilla.org/widget/cocoa/sdks.html

Dort wird genau das beschrieben, was ich sage: die Verantwortung liegt beim Entwickler. Er wird darauf hingeweisen und kann genau diese Dinge lösen. Man muss es halt machen.

Dieses ganze Thema trifft aber ausschließlich auf vorhandene Software zu. Nur hier sind diese Anpassungsthemen vorhanden. Wenn neue Software entwickelt wird, kann diese mit neuem Xcode ohne Probleme gegen ältere SDKs gelinkt werden und somit auch für ältere System zur Verfügung gestellt werden. Und das geht zur Zeit zurück bis zu SnowLeopard.

Hier noch die Zitate aus der website von Firefox, nicht das nu nnoch jemand anfängt was anderes zu behaupten:

es werden Versionen ab 10.11 unterstüzt:
For local builds, all SDKs from 10.11 to 10.15 are supported.

Das SDK von Catalina untersützt noch SnowLeopard builds.
The second aspect, available deployment targets, is usually not worth worrying about: SDKs have large ranges of supported macOS deployment targets. For example, the 10.15 SDK supports running your app on macOS versions all the way back to 10.6.

Apple stellt die Infos über geändertes runtime Verhalten zur Verfügung und gibt gleichzeitig für "alt-kompilierte" Anwenungen nach wie vor das alte Verhalten auch in neueren Systemen wieder:
When a new version of macOS is released, existing APIs can change their behavior. These changes are usually described in the AppKit release notes:
...
Sometimes, these differences in behavior have the potential to break existing apps. In those instances, Apple often provides the old (compatible) behavior until the app is re-built with the new SDK...

es liegt nun am Entwickler, auf die neuen APIs anzupassen

... expecting developers to update their apps so that they work with the new behavior, at the same time as they update to the new SDK.

Klar kann man nun als Entwickler sagen: das will ich nicht machen, weil ich keine Zeit habe / keine Lust habe / keine Ahnung habe.

Aber zu behaupten es wäre notwenig, ein altes SDK zu installieren ist schlichtweg falsch.

 

[lisanet]

Der Vorteil, wenn man gegen ein altes SDK kompiliert, ist dass das entstandene Programm auch auf entsprechend altem MacOS läuft. Solange da keine Sachen verwendet werden, die später von Apple entfernt wurden, läuft das kompilierte Programm in alten und neuen Umgebungen. Für manche Branchensoftware ist das relevant.

Genau das ist identisch möglich, wenn du mit einem aktuellen Xcode lediglich das deplyment target änderst.

Auch dann wird diese Software auf dem alten, als auch auf dem neuen System laufen. Du kannst sogar warnings einstellen, dass dir Xcode sagt, wenn du zufällig neuere APIs verwendest die auf dem deployment target nicht vorhanden sind. Es gibt keinen Grund, sich ein altes SDK zu installieren, außer man möchte sich unnötige Arbeit machen, die keinerlei Vorteile bringt.

 

[oneOeight]

Klar kann man nun als Entwickler sagen: das will ich nicht machen, weil ich keine Zeit habe / keine Lust habe / keine Ahnung habe.

Die Möglichkeit in einem Code Methoden/Funktionen von dem vorhanden sein von Frameworks abhängig zu machen, gibt es ja schon lange mit dem relativen Linken.
Nutzt halt nur keiner.

 

[cyberfeller]

Weil Apple das nicht mag

 

[lisanet]

Weil Apple das nicht mag

??? Wir reden doch von weak linking, oder nicht? Das soll Apple nicht mögen?

 

[capmilk]

Genau das ist identisch möglich, wenn du mit einem aktuellen Xcode lediglich das deplyment target änderst.

Wenn dir das 10.9 SDK reicht, dann ist das möglich. Frag nicht warum, aber es gibt Projekte, die gegen ältere SDKs kompilieren, und bei denen reicht das eben nicht. Das ist aber zugegeben ein recht akademischer Fall.

Will sagen: Du hast recht.

 

[lisanet]

Frag nicht warum, aber

tja, schade. Wäre doch sehr interessant. So ist es halt ein Totschlagargument.

Will sagen: Du hast recht.

Danke.

 

[capmilk]

[Warum Leute für ein SDK < 10.9 entwickeln.]
Wäre doch sehr interessant. So ist es halt ein Totschlagargument.

Ein Grund, auf Basis des SDK 10.7 zu entwickeln ist, um mit den OpenStep-Spezifikationen konform bleiben zu können. 10.7 hat sich da bewiesen als ein gesunder Kompromiss aus altem OpenStep und "modernem" Cocoa, ohne dass man zu viele Weichen im Code hat. Die Konformität zu OpenStep wiederum ermöglicht ein Deployment auf Windows.

 

[lisanet]

Ein Grund, auf Basis des SDK 10.7 zu entwickeln ist, um mit den OpenStep-Spezifikationen konform bleiben zu können. 10.7 hat sich da bewiesen als ein gesunder Kompromiss aus altem OpenStep und "modernem" Cocoa, ohne dass man zu viele Weichen im Code hat. Die Konformität zu OpenStep wiederum ermöglicht ein Deployment auf Windows.

und da reicht ein deployment target auf 10.7 in Verbindung mit -Wpartial-availability nicht aus? War mir nicht bekannt und muss ich mal nachforschen, da mich die konkreten Code-Hindernisse schon interessieren würden.

Hmm, das ist aber nun ein Beispiel, dass der Sourcecode auf OpenStep (GNUStep?) kompatibel bleibt, oder ist etwa OpenStep binarärkompatibel? Auf Windows doch sicher nicht. Wenn es um SourceCode-Kompatiblität geht, dann ist das aber doch was anderes als das was hier gerade angesprochen wurde, da hier Binärcode, der unter aktuellem Xcode mit altem deployment target auch auf alten Mac OS X Versionen lauffähig ist.