Liebes Forum,
dieser Thread schließt sich einem Diskussionsstrang aus einem Artikel von sonorman an, diesem hier:
Wir möchten uns hier nicht nur über Symptome auslassen und darüber beschweren, was alles schief läuft (das ist in den Kommentaren zum Artikel gut dokumentiert), sondern mögliche Ursachen für die vermeintliche Schieflage bei Apple in punkto Qualität diskutieren.
Zum Einstieg habe ich den ursprünglichen Beitrag von nane, meinen Kommentar dazu und eine Replik zu nanes Beitrag von Windwalker hier schon einmal zusammengefasst.
Auf eine schöne Diskussion!


Daraufhin mein Kommentar:
Und hier der Kommentar der schließlich diesen Thread anregte:

Mein Beitrag zum Thema, recycelt:

Diese Aussage dokumentiert in meinen Augen, wie "weit" wir schon gekommen sind. Der Ursprung des Fehlers ist nicht mehr beim Verursacher zu suchen. Es sind vielmehr die äußeren treibenden Kräfte, die dafür verantwortlich sind.

Man muss es sich auf der Zunge zergehen lassen: Schuld ist nicht Apple mit seinen versagenden Institutionen im Bereich der Qualitätssicherung. Nein, Apple trifft keine Schuld. Denn Apple ist das Opfer.

Apple ist das Opfer, welches der Anwender vor sich her treibt. Denn Apple muss auf die Anwender reagieren, die einen Innovations-Druck auslösen. Unfassbar, diese Fehleinschätzung der Realität!

Wenn wir von einem "innovativem Druck des Anwenders" sprechen können, dann hiervon: Es scheint die Grenze dessen erreicht zu sein, was Apple meint, gegenüber dem Kunden durchsetzen zu können. Innovativ ist jetzt, dass der Anwender die Schnauze gestrichen voll hat. Sein "innovativer" Ansatz lautet jetzt: Baut mir Produkte, mit denen ich arbeiten kann.

Das ist tatsächlich innovativ. Diese Aussage vernahm man bislang nur hinter vorgehaltener Hand. Apple – vom Anwender zu Innovation getrieben (ich lach mich schlapp!) – muss sich jetzt der Situation stellen, dass diese Anwender nicht mehr alles mit sich machen lassen. Ein Fehlerchen hier, ein Fehlerchen da – geschenkt. Aber Epic Fail auf der ganzen Linie (dazu auf Wunsch gerne von mir mehr) – das reicht uns jetzt, Apple!

Vielleicht kann mal ein Softwareprogrammierer etwas zu den Bugs sagen! Nicht alle scheinen zeitintensive Probleme zu sein.

Ich denke auch, daß nicht der User den Innovationsdruck auslöst, ist und war es nicht Steve Jobs, der sinngemäß gesagt hat, daß man Produkte entwickeln soll, von denen der Anwender noch gar nicht weiß, daß er sie haben will?
Den Innovationsdruck haben sich die Firmen selbst auferlegt und werden noch von ihren Aktionären angetrieben, da kann der Anwender nur staunen und sich einreden, man würde Produkte für ihn herstellen.

Thema Innovations-Druck:
Apple ist seit Gründung der Vorreiter der technologischen Innovation im IT Bereich. Apple hat es immer verstanden, durch Innovationen und technische Neudefinitionen die Kunden bei der Stange zu halten und auch neue Kunden zu gewinnen. Grundsatz des Erfolges von Apple ist, dass man technologische Innovationen sehr weit vereinfacht, schöner als andere Hersteller verpackt und dafür "etwas" mehr Geld verlangt.

Damit dieser Grundsatz funktioniert, muss das Marketing von Apple mit extremen Formulierungen, sehr geschickten Darstellungen und auch Tricks arbeiten. Wir alle wissen, dass das Marketing von Apple funktioniert und zwar so gut, dass daraus seit ein paar Jahren auf verschiedenen Geschäftsfeldern ein Problem entsteht. Die Erwartungshaltung der Kunden ist durch das ständige aufbauschen des Marketings so hoch, dass die Kunden inzwischen schon zur Hälfte gähnen, wenn Apple etwa ein iPhone X vorstellt. Daraus entsteht ein enormer Innovations-Druck auf Apple, für den Sie selbst verantwortlich sind und aus dem Sie jetzt irgendwie auch wieder herauskommen müssen. Man darf gespannt sein, wie sie das hinbekommen.

Und dieser Druck auf allen Ebenen, den wir Kunden auf Apple ausüben, entstehen natürlich auch viele Fehler, Fehler die auch von den Medien haarklein und schnell aufgebracht werden und die den Druck auf Apple weiter erhöhen. Unterm Strich kämpft Apple also seit geraumer Zeit gegen die Geister, die sie selbst gerufen haben.

Leider muss ich dem widersprechen. Ein "funktionierendes" Marketing ist keineswegs ein Marketing, das es nötig hat, sich irgendwelcher (dein Zitat:) Tricks zu bedienen. Ein funktionierendes Marketing führt auch nicht zwingend zu einem Problem.Das Gegenteil ist richtig: Ein gutes Marketing zeichnet sich dadurch aus, dass es nicht auf "Tricks" aufbaut. Und ein gutes Marketing ist dann gut, wenn es konzeptionell so angelegt ist, dass daraus im Laufe einiger Jahre keine Probleme erwachsen können.

Apple ist nicht darauf reduzierbar, was da im Bereich des Marketings "gut" oder "schlecht" angedacht und umgesetzt wird oder wurde. Apple steht im Wettbewerb und muss sich mit anderen Anbietern vergleichen lassen. Mit guten Produkten, mit guter Leistung und mit nachvollziehbaren Argumenten, warum sein Produkt X zum Preis Y eine akzeptable Entscheidung darstellt, obwohl ein Hersteller B zum erheblich günstigeren Preis das leistungsfähig identische Produkt Z liefern kann.

Bislang war diese Argumentationskette in sich schlüssig. Es gab lästige Ausnahmen – aber unter dem Strich sprach doch sehr viel für Apple. Leider verdichten sich diese Ausnahmen zur Regel. Und dies ist nicht dem Marketing geschuldet. Der Fisch stinkt vom Kopf her.

Meiner Meinung liegt die Schieflage bei Apple daran, dass Apple die User mit schwachsinnigen cloud-anbindungen beglückt, also vor allem den Kunden abhängig machen will. Genau seitdem macos in vielerlei Hinsicht mit icloud verzahnt ist, leidet die Qualität des Grundsystems. Klar ist allein schon der betrieb einer solchen cloud extrem aufwendig.

Diesen "innovations druck" erschafft Apple sich selbst. Auch hat Apple selbst entschieden, jedes Jahr ein pseudo-update zu veröffentlichen. Apple hat auch wenig Konkurrenz im Apple kosmos. Oder sollte sich Apple Microsoft zum Vorbild genommen haben? Warum kopieren von einem schlechten Beispiel? Nein, apple macht das natürlich, um geplante Obsoleszenz durchzusetzen.

Nun wurde Shazam gekauft, und ich ahne Schlimmes. Die Qualität von macos wird daran noch mehr leiden. Es wird nun im System noch einen weiteren System-Dienst / Launch-Agent geben, der für Shazam zuständig ist. Seht Ihr hier auch das konzeptionelle Problem? Sehr spezielle Funktionalität wird als Standard in das System integriert. Deaktiviert man diese nicht-system relevanten Dienste, so wird die Console häufig mit Fehlermeldungen gefloodet, weil bestimmte Systemkomponenten garnicht in Betracht ziehen, dass der Shazam-Dienst nicht läuft. Das heisst, es wird zum system-relevanten Dienst gemacht, ohne dass es nötig wäre. Internet-Dienste sind immer komplex und auch anfällig. Je grösser die Abhängigkeit davon, desto mehr Fehler werden auftreten.

Erklärt mir auch einmal bitte, was der Sinn ist, dass Handoff nur in der icloud funktioniert? Ich benutze handoff doch nur, wenn mein anderer Computer in der Nähe ist? Diese ganzen "Hallo, ich bin da" Funktionen würden wesentlich besser, schneller und autarker im lokalen Netzwerk laufen. Zumindest sollte das so sein, wenn iCloud deaktiviert wird. Dieser Fall trifft auf sehr viele andere macos-Dienste auch zu.

Soviel zur Theorie

Ich stimme zu, der Fisch und der Kopf usw. Das sind schon alles Faktoren die einmal hinterfragt werden sollten. Dennoch, im Augenblick stimmen die Zahlen (und das ist ziemlich verniedlicht, tatsächlich sind die Zahlen einfach bombastisch plus weitere Superlative in nahezu sämtlichen Bereichen) und ausschliesslich das zählt fürs Management und hier wiederum für die Anteilseigner. Damit ist also auf absehbare Zeit keine Änderung in Sicht. Ausser natürlich, die Menschen im Management haben irgendwann einmal genug.

Ich möchte die iCloud nicht hergeben, selbst für ein absolut fehlerfreies System nicht! Es ist für mich wie mit dem Internet: Es gibt so viel Bugs, Fehler, Mängel, Störungen und Gefahren, die durch das Internet verursacht oder verstärkt werden, dennoch kann kaum jemand noch ernsthaft einen Computer ohne Internet verwenden.

Nein, das ist überhaupt gar nicht das Problem.

Konzeptionell ist die Software von Apple hervorragend aufgebaut, zumindest der von NeXT geerbte Kern. Neue Konzepte implementieren macht ja auch Spaß und ist eine erfüllende Aufgabe.

In einem komplexen System unvermeidbare Flüchtigkeitsfehler beseitigen und wenig originelle (aber halt für den Nutzer hilfreiche) Standardfunktionen hinzufügen, um das tolle Konzept abzurunden – all das macht weit weniger Spaß und bleibt bei Apple viel zu oft liegen.

Ich kannte vor langer Zeit einen genialischen Hobbyprogrammierer, der in kürzester Zeit diverse fantastische NEXTSTEP-Applikationen aus dem Boden gestampft hat. Aber immer, wenn die so zu ca. 80% – 90% fertig waren und nur noch Feinschliff gebraucht hätten, verlor er Interesse und Lust daran und stürzte sich aufs nächste tolle Programm. Und so kam es, dass keines seiner tollen Programme jemals veröffentlicht wurde.

So ähnlich ist das bei Apple auch – nur dass sie die Programme leider trotzdem veröffentlichen.

Ich habe von 2004 bis 2011 als Betatester für Apple gearbeitet (nicht die heutigen öffentlichen Tests, sondern interne). Es gibt Fehler, die ich 2004 gemeldet habe, die auch als solche bei Apple reproduziert und registriert wurden, die in einer Stunde zu beheben wären, und die heute, 2017, immer noch da sind. Es macht einfach keiner.

Es ist schwer, den Finger darauf zu legen, wo die strukturelle Ursache zu suchen ist (es ist ein Management-Problem, das ist klar – die einzelnen Entwickler finden nicht die Rahmenbedingungen vor, die sie für konsistentes Arbeiten bräuchten –, und es wurde deutlich schlimmer, als die iOS-Implementierung losging und der Kompatibilität halber etliche wunderbar funktionierende Mac-OS-X-Innereien neu geschrieben werden mussten und dann nie wieder so stabil waren wie vorher).

Leider „verrottet“ Cocoa, Apples Kronjuwel, so innerlich mehr und mehr, und wenn das Management hier nicht das Ruder herumreißt, wird der Punkt kommen, wo sich das bitter rächt.

Die Ursache dafür ist relativ einfach zu benennen. Apple hat eine Marktnische in der die Softwarewartung kein Verkaufsargument ist. D.h. nur über neue Features verkaufen sich Apples Produkte. Leider ist es nun einmal so, dass eine Änderung von Kernkomponenten eine längere Phase der Fehlerbehebung nach sich zieht, da man bei "normaler" Software auf die Korrektheitsprüfung wegen der enorm hohen Kosten verzichtet. So verfährt man nur bei Software für Luft- und Raumfahrt und noch einigen wenigen Bereichen. Es gibt da viel Literatur dazu, und in der Phase der Entwicklung von Ada wurde vom US DoD enorm viel zu Softwareanalysen publiziert. Aktuell gibt es extra einen Subset von Ada, um die formale Prüfung zu simplizifieren SPARK.

Da nun leider weder Objective-C, C noch C++ für eine solche formale Prüfung besonders geeignet sind, und dies viel zu teuer wäre, verfährt man nach dem guten alten Trial&Error Verfahren. Da Apple leider in der neueren Vergangenheit die Kernkomponenten verändert hat, hat man auch die Stabilität der Vergangenheit eliminiert. Man müsste nun viel Geld in das Debuggen der Komponenten stecken und da scheint das Managment bei Apple keine große Lust darauf zu haben, weil man eben damit nicht werben kann. Es ist eben kein BlingBling.

Dazu kommt die Tatsache, dass Objective-C leider durch die in vielen Fällen überflüssige schwache Typisierung solche Logikfehler nicht während der Übersetzung abfangen kann. Der übliche Weg ist es nun Unittests zu schreiben und so über Testprogramme diese Logikfehler abzufangen. Man kann dies gut am Beispiel das Monats 13 erklären. Zwar erkennt die Plausibilitätsprüfung im Programm, dass es keinen 13. Monat geben kann, aber das Programm ließ sich übersetzen. Mit Ada wäre das nicht so einfach gewesen, und im Extremfall bei einer erzwungenen Konversion während der Laufzeit wäre das Programm an der konkreten Fehlerstelle ausgestiegen.
Generell verrottet das Betriebssystem, weil Apple nicht in wichtige Dinge investiert die man nicht sieht. Der wichtigste Schritt wäre es meines Erachtens, die Releasezyklen von macOS auf mindestens fünf Jahre zu verlängern und statt dessen mehr Wert auf Wartung zu legen und neue Features nur noch als eigenständige Applikationen zu bringen und nicht ständig am Kern des OS herumzupfuschen. RHEL bringt ungefähr alle vier Jahre ein neues OS und hat mit dem extended Support eine Lebensdauer eines OS von ca. 14 Jahren.

Wenn Apples sich nicht anstrengt wird RHEL o.ä. Apple bei den Kreativen als OS der Wahl ablösen. Der Trend geht ja schon dahin.

Das ist sicher ein wichtiger Aspekt, aber ich zweifle doch, dass es der einzige ist.

Eine „Nische in Apples Marktnische“ sind ja sehr wohl die ernsthaften/intensiven/professionellen Nutzer, für die It just works ein entscheidendes Kaufargument war/ist und die Apple damit mittelfristig vergrault.

Und in vielen Fällen ist das Problem eben nicht, Fehler mithilfe aufwändigster Prüfverfahren erst zu finden. Die Fehler sind bekannt, sie sind in Apples Datenbank dokumentiert, und sie wären teils mit minimalem Aufwand zu beheben.

Da muss also noch was anderes dahinterstecken.

Ein Aspekt ist Apple ausgesprochener Geiz mit Manpower. Ich weiß aus persönlichen Gesprächen mit etlichen Entwicklern, dass sie sich überlastet fühlten. Dazu kommt dann noch, dass sie sich nicht kontinuierlich mit einem Bereich beschäftigen können, sondern immer wieder von einem Projekt zum anderen gescheucht werden, was Apple aufgrund der „Vermischung“ ja für eine großartige Idee hält.

Natürlich kenne ich die Probleme mit dem mythical man month, aber Apple ist meinem Eindruck nach weit von der Stelle entfernt, wo zusätzliches Personal die Produktivität nicht mehr erhöhen oder gar senken würde. Teilweise treten die Probleme ja in einem wohldefinierten, eng umgrenzten Kontext auf und ließen sich sehr gut von separaten Teams bearbeiten.

Dass Apple Anfang der 2000er auf seine Finanzen achten musste, glaube ich gerne, aber das ist ja nun weiß Steve nicht mehr der Fall. Hinter diesen zu kleinen Teams steckt was anderes, ich verstehe nur leider nicht wirklich, was.

Die letzten Jahre waren doch ohnehin für den "professionellen" Anwender die Hölle. Apple kommuniziert via der Produktpalette sehr deutlich, dass die ehemalige Kernkäuferschaft nur noch als Marketingresonator gern gesehen ist, um mit dem Nimbus des "professionellen" OS mehr unbedarfte Käufer für die Consumerprodukte zu akkumulieren.
Die Kunden kaufen die Produkte doch trotzdem, weshalb sollte Apple etwas an der Politik für die Wartung des OS ändern? Die Programmierer werden für die neuen Features benötigt, und können so eben nicht Softwarewartung machen. Die Börse wird es freuen, dass Apple eben nicht mehr Softwareentwickler beschäftigt. Aus Sicht der Buchhaltung ist der Weg der richtige.

Das ist eine "alte Tradition" von Apple. Da ich selbst einmal für dieses Unternehmen arbeiten durfte, kann ich aus meiner Erfahrung heraus sagen, dass dieser Ansatz einen sehr wichtigen Hintergrund hat (hatte).

Tradition:
Es ging darum, dass man generell in verschiedenen Bereichen quasi Einzelkämpfer etwas machen liess, was im Endeffekt einige phantastische Produkte erzeugte. Einzelkämpfer können (ohne Beeinflussung von Aussen, also Management, Teamleitungen, anderen Kollegen usw) unglaublich kreative Lösungen und komplexe Produkte in kurzer Zeit erschaffen. SJ selbst hat meist einzelne Mitarbeiter einzelne kreative Lösungen für Problemstellungen ausarbeiten lassen und eben die kreativste Lösung letztlich von einem Team unter der Anleitung des jeweiligen "kreativen Gewinners" produziert.
Dieser Ansatz hat einzelne Mitarbeiter zu unglaublichen Leistungen befähigt und dem Team drumherum gezeigt, dass es "das über sich hinauswachsen" tatsächlich gibt. Oftmals wurde das auch scherzhaft im Team als Steves "Reality Distortion Field" bezeichnet. Er forderte einfach unglaubliche, noch nie dagewesene Lösungen und Ansätze und es war komplett egal wie diese erreicht und realisiert wurden. Im Endeffekt wurden diese aber tatsächlich auf "wundersame" Weise von einzelnen Mitarbeitern kreiert.

Kleine Teams:
Bis heute sind daher die Teams bei Apple in kreativen Entwicklungsbereichen immer recht klein gehalten. Das hat für das Unternehmen den Vorteil der (quasi) "automatischen" Geheimhaltung, denn je kleiner das Team desto unwahrscheinlicher sind "Informations-Lecks" und vor allem, es bleibt der Geist und die Tradition der "möglichen" ungebremstem Kreativität erhalten.

Wechsel und Mischung:
Um eingetrampelte Pfade im Geist, Kontinuität, Eingewöhnung und z.B. "das habe ich so gelernt" oder "das habe ich schon immer so gemacht" Gedanken zu vermeiden (SJ hielt dies für die grössten Feinde der Kreativität) werden die kleinen Teams meist stark und häufig durchmischt. Das klingt im ersten Augenblick paradox. Der Hintergrund ist aber, dass jeder einzelne Mitarbeiter sich schnell auf neue Situationen, neue Probleme und andere Arbeits- und Herangehensweisen einstellen muss. Sein kreatives Potential damit also immer auf höchstem Niveau arbeiten muss und er sich ständig neue Varianten und Lösungen zu Problemen unterschiedlichster Form ausdenken muss. Und (für SJ war das am wichtigsten) die wenigen Beteiligten müssen sich schnell, effektiv und vor allem kreativ austauschen ohne Eingewöhnung oder Absprachen. Dieses System funktioniert sehr gut, so paradox das für Aussenstehende wirken mag. Es ist sogar integraler Bestandteil aller kreativen Entwicklungsbereiche bei Apple.
Ausserdem entwickeln parallel immer mehrere kleine Teams an Lösungen für die gleichen Aufgabenstellungen. Somit werden immer die bestmöglichen Lösungen recht schnell gefunden und die anderen einfach verworfen. Das trennt in der gesamten Mannschaft schnell die "Macher" von den "Mitarbeitern" und SJ legte grossen Wert darauf in den Entwicklungsbereichen keine Mitarbeiter sondern ausschliesslich "Macher" zu haben.

Wie es aktuell bei Apple aussieht kann ich allerdings nicht exakt sagen. Und ob meine Darstellung so noch aktuell ist, kann ich damit nicht garantieren. Es würde mich aber wundern, wenn bei Apple im Kreativbereich massive Änderungen eingetreten wären. Denn diese sind in der Masse, direkt auf die Inspiration von SJ (schon aus den 70er Jahren) zurückzuführen und "normalerweise" sind die Prinzipien von SJ im Kreativbereich von "heilig" bis "sagrosankt" angesiedelt und damit also eher vollkommen unantastbar

Da vermutlich niemand von uns Einblick in die internen Strukturen und Abläufe bei Apple hat, bleibt nur wildes Spekulieren - Meinungen, die nicht verifiziert werden können.

Ich glaube inzwischen, dass es im Bereich der Softwareentwicklung und Qualitätssicherung keine oder nur sehr schlechte Strukturen bei Apple gibt. Mein Verdacht: Früher trat das seltener nach Außen, weil ein Steve Jobs die Produkte wirklich selbst genutzt und ausprobiert hat und bei jedem falschen - oder hässlichen - Pixel wutschnaubend durch die Abteilung gebürstet ist. (so wurde ja immer mal wieder berichtet). Jeder Entwickler musste also in letzter Konsequenz um seinen Job bangen, wenn er es verbockt hatte.

Das mag ein beschissenes Arbeitsklima sein, hat die Leute aber offensichtlich zu hohen Leistungen angespornt. Ich kann nur vermuten, dass die Entwickler selbst(!) sehr intensiv getestet haben, bevor das ganze in die Qualitäts-Abteilung und zu Steve ging... Das alte Prinzip: "Nach bestem Wissen und Gewissen" - Vorher wurde nicht abgegeben und wenn der Termin MORGEN war, dann wurde halt die Nacht durchgearbeitet und alles dicht gemacht.

Das scheint mir nicht mehr so zu laufen. Ich höre und lese nichts von einem cholerischen Tim Cook sondern eher von einem sehr ruhigen Tim. Das Klima mag angenehmer und entspannter geworden sein - vermute ich, da man wenig anderes liest, jedenfalls nicht auf der Stufe wie es unter Steve war.

Ich kann nur vermuten, dass wir jetzt nach und nach sehen, wie es bei Apple wirklich läuft - und das sieht weit weniger strukturiert aus als man es glauben sollte.

Ich vermute mal:
- Für ein Kernthema gibt es ein Team, was wirklich mit Hochdruck an einer Sache arbeitet. Nehmen wir mal Face-ID
- Alle anderen Programmteile werden von anderen, kleinen Teams oder Ein-Mann-Büros abgearbeitet
- Kommunikation zwischen den Teams: Nahe Null. Unstimmigkeiten tauchen evtl. einmal in der Woche / im Monat bei einer Person auf und dann wird ggf. noch mal "gebastelt"
- Niemand hat den Gesamtüberblick.

Dass kein Entwickler ein festes Projekt/Thema hat, war schon oft zu lesen. Entwickler werden als Ressourcen bewertet und nach Bedarf an diverse Projekte gesetzt, wo halt Arbeitskraft benötigt wird. Das ist suboptimal, weil Entwickler dann nur selten "Herzblut" und Emotion für die Tätigkeit aufbringen werden - "Ist ja nicht mein Code ... mein Fix muss dann auch nicht eleganter als der Rest sein" oder "kümmert sich eh nächste Woche der nächste drum"

QM scheint es auch kaum zu geben... Warum meckert ein iOS 11.2 plötzlich 3rd-Party-Kabel an, die seit zig Versionen und Updates funktionierten? Da werden Lenkrad-Steuerungen in Kfz lahm gelegt und niemand merkt das bei Apple? Schlussfolgerung:
a) So etwas wird nicht getestet
b) niemand benutzt die Produkte selbst in solchem Umfeld
c) wenn ein Mitarbeiter so etwas bemerkt, hat er genauso wenig Einfluss darauf wie wir als Kunden

Das wird in den nächsten Monaten so weiter gehen - denn so etwas ändert man nicht über Nacht!

Ich habe Firmen erlebt, die es geändert haben (in einer arbeite ich selbst) und es bringt RICHTIG was! Strukturen aufbauen und halten, Entwickler an festen Projekten ("das ist mein Baby") - ja, immer mehr als einer - und ein stringentes QM und Testabteilung mit automatisierten und manuellen Tests und einem strukturiertem Abarbeiten der Fehlermeldungen der Kunden.

Wenn Apple da nichts ändert, ich weiß nicht, wo die in 2 Jahren stehen werden.

Für neue und innovative Entwicklungen ist das bestimmt ein guter Ansatz.
Aber jede Maschine braucht auch ihre Wartungstechniker. Und die profitieren von Erfahrung und Kontinuit.
Wie (fast) immer wäre wohl ein Mittelweg der Traum .

Weiß zufällig jemand, wie das bei NeXT organisiert war? Die haben ja Innovation und Qualität hinbekommen.

Sonst bin ich auch der Meinung, die oben schon geäußert wurde: Niemand zwingt Apple, für macOS jährlich ein großes, kostenloses Update rauszubringen, so daß nur Zeit für ein paar sichtbare Neuerungen, aber nicht mehr für interne Arbeit ist. Es war Apples Entscheidung,
a) macOS nach den Gesetzmäßigkeiten des iPhone-Marktes zu behandeln (für mich der Kern der Mac-Übel)
b) den Mac allgemein in der Priorität ganz nach hinten zu stellen
c) nicht in Wartung und Pflege zu investieren
(was man aus finanziellen Gründen nicht versteht: die Gehälter der paar dafür notwendigen Leute würden ja als Rundungsdifferenz in Apples Gewinnen verdampfen)

Ja erzähl mir mehr. Ich sehe auch ärgerlicher Fehler ... aber Epic Fail? Wirklich?

Wie ich im Thread zu Jony Ives Comeback schrieb bzw. wie dem verlinkten Artikel zu entnehmen ist, hat Jony wohl viel eher als Tim die Chuzpe, Leute nach Steves Muster anzutreiben.

Zum Thema Qualitätssicherung:
Man darf nicht ausser Acht lassen, dass Apple heute ein monstergrosser-Konzern ist, der weit über 110Tsd. Mitarbeiter weltweit hat. Vor 20 Jahren konnte SJ seine paar Tausend Mitarbeiter noch in der Eingangshalle in Cupertino zusammentrommeln und auch "zusammenstauchen".

Heute geht sowas natürlich nicht mehr. Die internen Mühlen (die SJ schon immer zutiefst verachtete) von Apple mahlen schon, aber wie von Mühlen eben gewohnt, sehr langsam. Bis interne Proceduren erarbeitet, geprüft und eingesetzt werden, die auch wirklich konzernweit (sprachunabhängig, währungsunabhängig, zeitunabhängig und weltweit nutzbar) greifen, vergehen schnell einmal zwei oder drei Jahre.

Dass die Apple-Mühlen mahlen, dass intern Fehlentwicklungen, Lücken oder Bedürfnisse der Kunden bemerkt werden und auch die Korrektur dazu anläuft, das beweist z.B. das (öffentliche) Eingeständnis der Fehlentwicklung des nMPro und die Reaktion dazu, dass man ein neues modulares Gerät entwickelt und auch der iMacPro, der ab Morgen erhältlich sein wird.

Auch in der Software hat Apple deutlich die Geschwindigkeit reduziert. Von Sierra ging es zu HighSierra über, was nichts zufälliges ist, sondern ein klare Tendenz, hin zur Qualitätssteigerung erkennen lässt. Im Augenblick mag das jetzt lächerlich erscheinen, vor allem wegen der vielen "bugs" die in den letzten Monaten durch die Medien geisterten. Man kann aber davon ausgehen, dass die Programme und Programmbauteile von Apple immer besser werden und sicher auch noch der öffentliche Schwenk zu längeren Update-Zyklen erfolgen wird. Apple hat eine Fülle neuer Frameworks vorgestellt und auch SWIFT wird von Apple nicht zum Spass entwickelt.

Alles zusammen zeigt schon die langfristige Strategie von Apple, etwa komplexe Sicherheits-Risiken zukünftig mit eigenen Chips (T-xy) zu begegnen und auch die Qualität der Software durch eine breitere Entwickler-Basis, längere Produktzyklen, mehr Beta-Phasen usw. zu steigern.

Bei aller Kritik, bin ich sehr davon überzeugt, dass die strategische Richtung von TC schon in der Zukunft aufgeht, auch wenn uns das alles langwierig und träge erscheint. Wir dürfen auch nicht darüber hinwegsehen, dass TC Apple von einer eher "zentralistisch" getriebenen SJ Organisation (das ist nicht negativ gemeint) hin zu einer auswechselbaren und universellen Konzern Struktur weiterentwickelt hat. Abgesehen vom Produkt-Design, das immer noch extrem von JI geprägt ist, sind alle anderen Konzernbereiche nicht mehr direkt von einzelnen Persönlichkeiten abhängig und dennoch ist trotz aller Grösse die eigentliche Innovationskraft von Apple weiterhin präsent. Sicher nicht mehr so impulsiv wie in der Vergangenheit, aber dennoch für jeden sichtbar und vor allem kaufbar in Form von Produkten.

So nervig augenblicklich die bugs sind und so chaotisch auch die Qualität der Software im Moment anmutet, so wenig dürfen wir die greifenden Strukturen des Apple Konzerns im Hintergrund unterschätzen. Viele "Macher" dort wissen schon, was sie tun, auch wenn wir es gerade nicht sehen

Tja, die Frage ist: informations- oder wunschbasierte Aussage?

Erfahrungsbasiert. Mit 5% Wunschhintergedanken

Die einzelnen Programme hatten dort ganz klar verantwortliche Autoren/Autorenteams, die auch im Info-Panel angezeigt wurden und teils bekannte Persönlichkeiten in der „Szene“ waren, Künstlern nicht unähnlich:



Und jeder wusste, dass Avie Tevanian das Mastermind hinter dem Kernel war.

Meinem subjektiven Eindruck nach begannen die Softwareprobleme bei Apple mit dem Wechsel von Avie Tevanian zu Bertrand Serlet an der Software-Spitze. Das letzte von Tevanian verantwortete Mac-OS-X-Release war 10.4 Tiger, und das war rock solid. Mit 10.5 Leopard begannen die Probleme.

Das kann eine rein zeitliche Koinzidenz gewesen sein mit den in Leopard erfolgten erheblichen Umbauten (Einführung von Core Animation und damit Auslagerung wesentlicher Programmstränge auf Grafikkarten, damit verbundene Instabilität des Nadelöhrs Window Server, Umbauten im Kern zur Herstellung der Kompatibilität mit dem damals in Entwicklung befindlichen iOS), es kann aber auch sein, dass Tevanian mit dieser neuen Ausrichtung, dem fast kompletten Aufschnüren eines stabilen Systems, nicht einverstanden war und genau deshalb das Handtuch schmiss, oder Serlet erfüllte seine Aufgabe eben einfach schlechter als Tevanian.

Die Tatsache, dass hier Kommentatoren sich nachts um 1 Uhr bzw. nachts um halbzwei Gedanken über das Unternehmen Apple Gedanken machen, macht mich das gelinde gesagt bedenklich. Ich arbeite seit 31 Jahren als Grafik-Designer als Selbstständiger mit Macs. Das war garantiert nicht immer einfach. Aber eine bessere Technik habe ich in dieser Zeit nicht gefunden. Ich begreife nicht, warum Leute, für die die Apple-Technik nicht ausreichend ist, nicht längs mit einer für sie passenden Technik arbeiten. Es reicht nicht zu sagen, so kann ich nicht arbeiten. Wenn ich so nicht hätte arbeiten können, dann wäre ich schon längst umgestiegen.

Was hat denn nun die Uhrzeit der Beiträge damit zu tun?

Falls es Dich beruhigt: meine Kernarbeitszeit ist zwischen 22:00 Uhr und 6:00 Uhr MEZ.
Du gibst Dir die Antwort auf Deine Frage doch selbst: weil es nichts Besseres gibt. Aber daraus folgt doch logisch nicht, dass das, was es gibt, hinreichend gut ist. Und insbesondere nicht, dass man nicht kritisieren darf oder einfach sich sorgen, wie es weitergeht, wenn man bestimmte Entwicklungen beobachtet.

Ja, der Bruch war ja von 10.4.3 auf 10.4.4 meine ich. Schon dieser Schritt klappte damals nicht gut, man ruderte noch wieder ein Stück zurück. Fragt mich nicht nach Details, die kriege ich nicht mehr zusammen. Im zweiten Anlauf gelang es dann.
Was ich generell als Gefahr sehe, ist, dass man zu schnell Sachen dazustrickt. Wenn man nicht die Balance einhält, immer die neuen Sachen mit dem Restsystem wieder in Einklang zu bringen, dann verliert man irgendwann das Wissen, wie es eigentlich laufen soll, so wie im System oder so wie in dem Rangestrickten. Die Zeit, die man für diese Kompatibilität investiert, ist gut angelegt. Sonst eiert man zwischen den beiden Welten unproduktiv und unbefriedigend hin und her. Ich kann nicht beurteilen, ob objektorientiertes Programmieren die Komplexität ausreichend in den Griff bekommt oder ob das auch nur einen Aufschub bringt. Ich meine, es gibt schon eine neue Herangehensweise, um noch besser mit komplexen Sachen klarzukommen. Leistet genau das SWIFT?

Die Design-Abkehr vom Skeuomorphismus ist so ein Punkt, wo Apple der Meinung war, dass man mit anderen neuen Designentwicklungen mithalten muss. Das macht es nicht einfacher, wenn alles, was schon funktionierte, noch mal wieder in optisch anders gemacht werden muss. Würde man mir mit sowas kommen, hätte ich dem einen Vogel gezeigt, denn ich hätte, bevor ich am Design den Syssiphus gebe, lieber an weiterer Funktionalität oder innerer Kompatibilität gearbeitet. Und erst, wenn man sonst nichts mehr zu machen hat, dann kann man noch mal übers Design nachdenken.

Apple = Computer + Software


Apple = Computer + Notebooks + Software


Apple = Computer + Notebooks + Smartphones + Software


Apple = Computer + Notebooks + Smartphones + Tablets + Software


Apple = Computer + Notebooks + Smartphones + Tablets + Watches + Software


Apple = Computer + Notebooks + Smartphones + Tablets + Watches + Musikstreaming + Software


Apple = Computer + Notebooks + Smartphones + Tablets + Watches + Musikstreaming + Bezahlsystem + Software


Apple = Computer + Notebooks + Smartphones + Tablets + Watches + Musikstreaming + Bezahlsystem + TV Produzent + Software

To be continued...

Wer in jedem Pott rumrührt muss sich meiner Meinung nicht wundern, das die Qualität langsam aber sicher auf der Strecke bleibt !🧐

Du hast die Ipods vergessen... Eine der wichtigsten Erungenschaften von Apple unter Steve Jobs

Da verwechselst Du was. Das war der Übergang PowerPC- auf Intel-Prozessoren, der für meine Begriffe recht gut verlief.

Die Probleme beim Übergang von 10.4 auf 10.5 waren völlig andere, wie oben beschrieben.
Das ist das Beste, was wir haben. Es ist nur nicht sehr performant, weswegen Apple zum Teil davon wieder abrückt, in Swift zum Beispiel.
Ganz im Gegenteil. Swift verwässert die Objektorientierung und stellt ansonsten auf ein paar im Moment gängige Moden um, insbesondere in der Syntax, so dass es Allerweltsprogrammierern nicht so seltsam vorkommt wie das streng objektorientierte Objective-C.

Die Energie, die Apple in Swift gesteckt hat, hätte es in Pflege, Reparatur und Ausbau von Cocoa (also der Bibliothek, die all die GUI- und Basisfunktionen für Mac-Programme zur Verfügung stellt) stecken sollen. Davon hätten alle etwas gehabt: die Programmierer (nichts erleichtert das Programmieren so sehr wie eine gute und mächtige Bibliothek), Apple (stabileres System) und Nutzer (Stabilität, Konsistenz aller Anwendungen von Apple und Drittanbietern). Swift statt besserem Cocoa war für meine Begriffe die Management-Fehlentscheidung des Jahrzehnts.

Ne, verwechsle ich nicht. Ich weiß nicht mehr genau, woran ich es so gut mitbekommen hatte, was zunächst nicht mehr richtig lief. Apple hatte damals auch eine Information herausgebracht wegen eben genau Einbeziehung des Grafikprozessors zum Berechnen (Rendern) von Texten. Wahrscheinlich war es etwas, das in Safari nicht lief. Ein Quartz-Objekt. Ja, das wars!

AppleUser2013

Yes.👍🤫

Sorry, tust Du doch.

Die Brüche, die ich aufgezählt haben, traten mit den massiven architektonischen Änderungen in 10.5 auf.

Das heißt ja nicht, dass es bei der Intel-Umstellung, auf die Du dich beziehst, keine Probleme gab. Es heißt nur, dass das nicht die Probleme waren, die ich meinte. (Und was ich meinte, weiß ich ja nun selbst am besten. )

Solch massive architektonische Änderungen wie die, die ich geschildert habe, nimmt man nicht in einem Minor Release vor, sondern nur in einem Major Release. Nicht zuletzt aufgrund des Umfangs dieser Änderungen verzögerte sich das Erscheinen von Mac OS X 10.5 Leopard damals deutlich.

War es nicht so, daß Apple seit 10.1 Puma schon auch immer eine Intel Version kompiliert hat...?

Die war von Anfang an da.

OPENSTEP lief ja auf Intel und war ohnehin darauf angelegt, auf mehreren Prozessorarchitekturen zu laufen (damals außer NeXTs eigenen, Motorola 68000 basierten Computern HP (PA-Risc) und Sun (SPARC)). Als OPENSTEP auf PowerPC portiert wurde, wurde Intel nie rausgeworfen, nur PA-Risc und SPARC.

Das war sehr seltsam damals, jeder, der die Innereien von OPENSTEP kannte, konnte mit einem Blick sehen, dass die Intel-Option noch vorhanden war, nur die „Fachwelt“ schwadronierte von wilden Gerüchten.

Na, ich weiß es so genau, weil ich eben davon betroffen war. Und ich war auch erstaunt, dass Apple diesen Schritt mit einem Minor Release machte. Einführung von Core Animation sagst Du hieß es? Dann ist das ja zu googlen, wann es passierte. Die Darstellung von Quartz-Animationen erhielt eine andere Grundlage. Das hatte zur Folge, dass nicht mehr überall, wo vorher noch Quartz lief, es weiterhin lief. Also Core Animation soll mit 10.5 eingeführt worden sein. Bleibt die Frage, was der gravierende Wechsel von 10.4.3 zu 10.4.4 war. Hatte mir extra beide OS-Versionen gesichert.

Mit 10.4.4 wurden erstmals Intel-Prozessoren unterstützt, auch da liegst Du richtig. Aber das ist eben noch nicht alles. Ich hatte zu der Zeit mein 17 Zoll Powerbook HiRes mit 1,67 GHz G4 und 1680x1050 Pixeln.

Ja, sag ich doch.
Ausschließlich die Umstellung auf „fette“ Binaries für PowerPC und Intel statt nur „schlanke“ Binaries für PowerPC. Aber dabei gab es halt halt ein paar unerwünschte Seiteneffekte …

Ich fand es klasse, dass Quartz-Animationen in Safari liefen. Die waren sehr schnell zu erstellen und eine Alternative zu Flash. Leider war das dann mit 10.4.4 auch schon wieder vorbei mit der Quartz-Unterstützung in Safari. Habs gerade nochmal mit Safari 11.1 probiert: geht immer noch nicht wieder. Auch ein Beispiel für in meinen Augen zu schnell zu Grabe getragene Technologien: Quartz-Unterstützung in Safari und Quartz-Composer überhaupt.

Das Quartz Composer.webplugin war nicht mehr in 10.4.4 und auch mit Rüberkopieren von 10.4.3 lief es nicht mehr. Alles auf G4, hatte mit der Umstellung auf Intel direkt nichts zu tun. Kollateralschaden.

Da Du nie Mac Nutzers warst, erschien Dir das so. Nein, es war ein Desaster, wenn man es mit dem Übergang von 68k auf PowerPC vergleicht. Bis auf wenige Applikationen, die spezielle Funktionen der Mac Toolbox nutzen, liefen Programme von System 1 auch noch in der BlueBox von MacOSX 10.4.x auf PowerPC. Es gab auf Macs nie eine größere Vernichtung von Applikationen als bei diesem Wechsel. Auch alte Programme sind wichtig, weil man nur so alte Datenformate konvertieren kann. Wer immer nur für den Augenblick lebt, dem ist das wohl egal. Ich wiederhole mich: Software für IBMs S/360 läuft auch heute noch auf einem modernen z/OS.
Das Problem an Objective-C ist nicht nur, dass das dynamische Dispatching extrem langsam ist, sondern das durch das Duck Typing wegen der schwächeren Typisierung massenweise Logikfehler verdeckt werden können. Diese Logikfehler muss man deshalb per Plausibilitätsprüfungen abgefangen. Dazu muss man Unittests nutzen, um den Code zu testen, um solche Logikfehler zu minimieren. Das ist vor allem ärgerlich, weil es in OO-Programmen fast nie die Notwendigkeit gibt Duck Typing zu nutzen. Das ist somit eine Quelle für Fehler, die man mit einer strengeren Typisierung schon beim Übersetzen abfangen kann. Wegen der Geschwindigkeit und der Vermeidung von Logikfehler ist eine Multiparadigmen OO-Sprache die sehr viel bessere Wahl. Ein so großes Projekt wie macOS lebt davon, dass man es möglichst leicht warten kann. Solche Fehlerpotentiale erzeugen einfach unnötigen Ärger.
Mitnichten, allerdings teile ich die Meinung, dass Swift hauptsächlich aus dem Zeitgeist heraus hervorgebracht wurde. Ein Objective-C 3.0 mit diversen Erweiterungen wäre sinnvoller gewesen, und hätte allen Beteiligten sehr viel Ärger mit der Softwarewartung erspart.

Das meinte ich jetzt aber nicht. Ich bezog mich auf Bugs bei der Umstellung, wir reden hier ja über abnehmende Stabilität des Systems. Du beklagst hingegen eine konzeptionelle Entscheidung von Apple, das Aufgeben der Blue Box. Dahinter steht letztlich doch schlicht, dass Mac OS X der Nachfolger von OPENSTEP war und eben nicht vom klassischen Mac OS; dessen Programme waren unportiert immer Fremdkörper auf Mac OS X, von denen doch von Anfang an klar war, dass sie nicht dauerhaft überleben würden, Intel hin oder her.
Ich glaube, wir sollten unsere Meinungsverschiedenheiten über die Details von Objective-C an dieser Stelle nicht erneut aufflammen lassen …
Na, das ist doch mal eine Zusammenfassung, auf die wir uns wunderbar einigen können! Und den bei diesem Vorgehen eingesparten Aufwand hätte Apple dann Cocoa zugute kommen lassen können.

Natürlich geht es um konzeptionelle Fehlentscheidungen von Apple, denn OPENSTEP for Mach lief doch bereits auf i486. Es waren also die konzeptionellen Änderungen die Ärger machten. Dazu halte ich es für fatal Software immer wieder mit Vorsatz kaputt zu machen, weil es Jobs toll fand. Man kann die Features einfrieren und die Software trotzdem noch weiter mit ausliefern. Außer Security Fixes gibt es dann keinerlei Arbeit mehr an der Software. Dafür ist es möglich auch noch alte Software auszuführen.

Desweiteren gab es keinerlei Portierungen von Carbon zu Cocoa, weil wirklich alles neu gemacht werden musste. Das komplette GUI, das Eventhandling, der komplette IO, … sind total unterschiedlich zwischen Mac Toolbox und Cocoa. D.h. wenn man früher eine 100% echte Mac Applikation hatte, war fast der komplette Code wertlos und musste durch neuen Code ersetzt werden.
Du hörst es nicht gerne, aber die schweren Designfehler von Objective-C haben ihre Auswirkungen auf die Softwarewartung und kosten richtig Geld.