Der Abend des 22.06. ist hier aber sowas von rot im Kalender markiert!

News kommt gleich....

Maniacintosh
Warum High Sierra? Was kann Mavericks schon nicht mehr?

Also wenn Mark Gurman so deutlich darüber schreibt, dann dürfte es eine ausgemachte Sache sein!

Apple hat schon mehrmals die Prozessor-Architektur gewechselt. Diesmal allerdings das erste Mal unter T.C. Deswegen wird alles schneller gehen und mit mehr Fehlern behaftet sein. Entwickler, die sich ausschließlich auf das Betriebssystem und seine Frameworks abstützen, müssen Ihre Software nur neu Übersetzen -- und dann die Fehler finden. Wer eine Programmiersprache verwendet, der Apple keinen Segen erteilt, hat Pech gehabt. Das dürfte vor allen Dingen für diverse Script-Sprachen gelten. Das Herausfinden der Compilerfehler überläßt Apple der Entwicklergemeinde. Die Möglichkeiten vom Objective C werden drastisch eingeschränkt.

Da hast Du recht. Für die Interpreter gilt jedoch das Gleiche wie für die Apps. Ich dachte aber auch an die Plattform übergreifenden Entwicklungsumgebungen wie Qt und Java und habe das alles in einen Topf geworfen.

Wie schnell man aus dem Raster fallen kann, hat Bombich grade mit seinem Carbon Copy Cloner erlebt. Noch ist nicht klar: It's bug or it's feature?

Wer eine Programmiersprache verwendet, der Apple keinen Segen erteilt, hat Pech gehabt.

Das Herausfinden der Compilerfehler überläßt Apple der Entwicklergemeinde.

Die Möglichkeiten vom Objective C werden drastisch eingeschränkt.

Zeit zu switchen...
Zu Linux

Assertion: The Cocoa frameworks are going away with this transition.

I find it very unlikely that Cocoa is going away anytime soon. Cocoa is largely written in Objective-C, and since Apple has been heavily investing in Swift the idea is that Cocoa must be going away.

Cocoa is the framework that drives pretty much every app on MacOS. Without NSWindow, without NSView, you've got no apps on the Mac. Apple could completely rewrite Cocoa in Swift, but that would be a monumental waste of resources and would take many years to accomplish. Apple famously keeps its teams small, so I don't see them spending the time to do this, only to say 5 years from now "Hey- it's all in Swift now! Isn't that great? Sorry we didn't get anything done in the meantime and here's a whole new set of bugs you'll be discovering as well".

"But wait! What about SwiftUI?" you might say. SwiftUI is barely one year old. Look at how long it's taken Swift to get to a point where it's not incredibly painfully to use. SwiftUI is most likely on a similar track, and regardless, many parts of SwiftUI also sit atop Cocoa.

Assertion: Objective-C is going away with the ARM transition, and it'll be Swift only from here on out.

Objective-C isn't going anywhere anytime soon. Too much of MacOS and too many important applications rely on it. Heck- the Cocoa frameworks are written in Objective-C! Objective-C is still incredibly important to Apple, even if the marketing department doesn't like to mention it.

And again, Swift code on MacOS completely relies on Objective-C.

Assertion: ARM Macs will exclusively run Catalyst apps.

The thinking goes, since major apps like Microsoft Word and Photoshop already have versions on the iPad, it would be a piece of cake for them to recompile and run on MacOS as Catalyst apps.

This would be a serious downgrade for users of these apps on MacOS, and would be a major departure from the way the apps currently behave on MacOS. And even with Catalyst, it's still a lot of work for an iPad app to look and feel like a Mac app. You're still going to need a team to make sure everything ports correctly, in addition to adding all the missing functionality that your users would expect to be there. I just don't see this happening either.

Zeit zu switchen...
Zu Linux

Den ganzen Artikel gibt es hier:

Vielleicht doch eher der Kehrwert 0,1%

Wellenbrett
Falsche Frage piik ist gelinde gesagt noch nicht ganz so überzeugt davon

Spass bei Seite: Es ist natürlich nicht sicher, dass Apple umstellt – allerdings ist aufgrund der Vielzahl unabhängiger Berichte zu dem Thema aus in der Vergangenheit sehr glaubwürdigen Quellen die Wahrscheinlichkeit sehr hoch.

Nur aus Interesse: warum hat ein Wechsel der Prozessorarchitektur für Dich einen Wechsel des Betriebssystems zur Folge?

Wie soll Apple denn Programmiersprachen einschränken können?

Ich bin zwar nicht angesprochen, aber ich mache mir ähnliche Gedanken. Auch wenn diese Transitions bei Apple erstaunlich gut laufen, sind sie unter dem Strich halt doch immer mit „Schmerzen“ verbunden - logisch, so eine grundlegende Änderung muss mit der Kompatibilität brechen. 68k-Emulation, Classic-Umgebung, Rosetta, Carbon alles alte Zöpfe, die Apple gerne abschneidet. Und die Schmerzen, die jede Transition macht, habe ich bei einem Wechsel zu Linux oder Windows zwar auch, nur da gab es diese ganz großen massiven Brüche (bisher) nicht und sind auch nicht zu erwarten, also hab ich nur noch einmal eine Transition und dann Ruhe... Bei Apple kann ich in spätestens 10 Jahren mit dem nächsten großen Bruch rechnen.

Daneben kommt halt die Problematik auf einem ARM-Mac kein Linux oder Windows in einer VM laufen lassen zu können. Wenn jemand die passende Virtualisierungssoftware anbietet, geht das mit ARM-Linux oder ARM-Windows alles ja noch, aber eine ARM-Windows ist verhältnismäßig witzlos und auch ARM-Linux wird häufig nicht nützlich sein, wenn es darum geht eine x86-Linux-Umgebung zum testen zu haben.

Wenn der AppStore Zwang kommt, wäre das kein Problem.

Warum sollte ein AppStore-Zwang die Wahl der Programmiersprache einschränken?

Die Frage war nicht, ob es die Wahl einschränken sollte, sondern ob dies möglich sei. Wenn Apple nur noch Swift für macOS anböte, und man keinerlei anderen Compiler mehr über den AppStore installieren könnte, müsste man zwangsweise Swift nutzen. D.h. möglich wäre eine solche Einschränkung durchaus, ob sie kommt ist eine ganz andere Frage.

Wellenbrett
Ich kenne ihn nur bezüglich seiner Haltung zu ARM-Macs, die er hier recht oft kundtat.

Wenn Apple nur noch Swift für macOS anböte, und man keinerlei anderen Compiler mehr über den AppStore installieren könnte, müsste man zwangsweise Swift nutzen.

Nein. Solange Apple irgendeinen Compiler zulässt, kann man vereinfacht gesagt mit diesem Compiler wieder einen zweiten Compiler für jede beliebige Programmiersprache erstellen.

Nein. Solange Apple irgendeinen Compiler zulässt, kann man vereinfacht gesagt mit diesem Compiler wieder einen zweiten Compiler für jede beliebige Programmiersprache erstellen.

Java ist im Moment sogar für Entwickler zwingend erforderlich, denn Apples Software, um Apps im App Store einzureichen (der sogenannte "iTMS Transporter"), ist ein Java-Programm.

Apple versucht in Xcode, das so gut wie möglich zu verbergen und die Java-Laufzeitumgebung wird versteckt installiert.

Sie wird nicht "versteckt" installiert, sondern sie ist schlicht Teil des App-Bundles. Das ist auch ein normales Paradigma.
Der Grund warum der iTMS-Transporter in Java geschrieben ist dürfte schlicht daran liegen, dass der iTunes/App-Store auf WebObjects basiert und das ist seit Version 5.0 in Java geschrieben.
Der Uploader dürfte schlicht von dem Team stammen und wenn man die Historie genauer anschaut: Der AppStore basiert auf den iTunes Store, der anfänglich nur für die Musikindustrie zugänglich war und da musste man ein plattformunabhängiges Tool für den Upload anbieten.

Dann müßte Apple also in Zukunft eine Java-Laufzeitumgebung für ARM mehr oder weniger versteckt installieren, damit der iTMS-Transporter weiterhin funktioniert;

oder den iTMS in Swift oder welcher Sprache auch immer neu schreiben. Wenn dazu etwas vor dem 22.06, öffentlich werden sollte, wäre es für die Prognose was an dem Tag passiert relevant...

Das ist Unsinn, denn dann könnte man den Mac nicht mehr zur Software-Entwicklung nutzen. Und dann wiederum wäre auch der Swift-Compiler überflüssig.

Und wo soll dabei das Problem sein? Also warum sollte Apple nicht Java für ARM anbieten? Zumal es Java für die ARM-Architektur schon gefühlt ewig gibt.

Auch das wäre für Apple überhaupt kein Problem zumal Apple scheinbar gerade sehr aktiv an der API von iTunes/AppStore arbeitet.

Und zu guter letzt und das ist der springende Punkt: Welchen macOS/iOS-Dev interessiert in welcher Sprache die Anwendung zum Upload in den AppStore geschrieben wurde? Genau so gut wie keinen, denn man kommt damit nicht mehr direkt in Berührung: Der von Apple bevorzugte Weg ist, dass das aus Xcode passiert.
Ok, ich habe nun so Sachen wie Fastlane unterschlagen … aber auch da, es spielt keine Rolle, denn da wird eine Anwendung aufgerufen … in welcher Sprache die geschrieben ist, ist egal.

Wozu sollte man den Compiler verteilen? Das ist nicht nötig, um ihn zu nutzen.

Weil man ihn sonst nur über SourceCode übersetzen bekommen könnte.

Nur was nützt das alles, wenn Du z.B. eine Qt5 Applikation portieren wolltest, aber Apple diese nicht über den AppStore verteilen würde?

Das war nicht die Frage. Es ging darum, dass es Verschwörungstheoretiker gibt, die denken, Apple könnte die Nutzung von Programmiersprachen auf einem System "beschränken", mit dem man programmieren kann.

Ja, verstehe ich. Der Bedarf Windows oder Linux auf dem Mac zu virtualisieren ist da.

Ist das wirklich noch so?

Die Mac-Platform ist, auch dank des iPhones, mittlerweile so groß geworden, dass 90% der Anwender mit Mac-nativen Apps auskommt.

Technisch bin ich zu wenig in der Materie um bewerten zu können, ob ein ARM-Chip einen lohnenswerten Benefit bringen wird, aber ich gehe mal davon aus, dass es so sein wird

Dazu mal eine Frage an die Profis: würden ARM-CHips die Portierung von iOS-Apps hin zu macOS-Apps vereinfachen?

Also mathematisch ist der Kehrwert von 99.9% gleich 1.001001 also größer als 1. Aber Mathematik beiseite, glaubst Du, die massiven Gerüchte für einen Prozessorarchitekturwechsel sind falsch?

Natürlich ist das so: Apple hat 100% Kontrolle über seine Chips und einen Preisvorteil. Den werden sie aber nie und nimmer weitergeben. Sprich: Apple hat Vorteile und die Nutzer zahlen die Zeche.

Ich denke, da irrst Du Dich.

Apple hätte enorme Investitionen zu tätigen, die mindestens im Milliardenbereich liegen.

Die bisherigen Entwickler würden bei Weitem nicht reichen, sie bräuchten tausende neue.

Das war nicht die Frage.