iOS 14: Entwickler nicht begeistert vom raschen Marktstart

Im Sommer zeigte Apple iOS 14, iPadOS 14 und watchOS 7 erstmals der Öffentlichkeit und wenige Stunde nach Ende der Präsentation standen bereits Vorabversionen für Entwickler zum Download bereit. Viele Entwickler nutzten die vergangenen Wochen und Monate, um Apps an die kommenden Betriebssystemgenerationen anzupassen. In vielen Fällen ist dies auch genug Zeit, um beispielsweise neue Features hinzuzufügen, welche die neue Betriebssystemgeneration ermöglicht oder Fehlerbehebungen durchzuführen. Doch auf dem "Time Flies"-Event am Dienstag verärgerte Apple die Entwicklergemeinde


Zwar hatten App-Entwickler über die letzten Monate genug Zeit für Anpassungen und Fehlerbehebungen – doch Apple gab Entwicklern diesmal nur ein Zeitfenster von 24 Stunden, finale Tests mit den Golden-Master-Versionen durchzuführen, die App einzureichen und auf die Freigabe von Apple zu warten.

Normal: Über eine Woche
Normalerweise gewährt Apple Entwicklern hier deutlich mehr Zeit. Bei den vergangenen, größeren iOS-Versionen hatten Programmierer stets eine Woche oder mehr Zeit, ihre Apps im App Store zur Begutachtung einzureichen. Normalerweise ist dies genug Zeit, noch einen letzten Test durchzuführen und mittels Xcode eine Version zum App Store zwecks Begutachtung zu übermitteln.

Vorher übermitteln: Geht nicht
Hätte man als Entwickler nicht einfach schon vor einer Woche eine Version mit Anpassungen für die kommende Betriebssystem-Version hochladen können? Die klare Antwort: Nein. Bis zum Erscheinen der Golden-Master-Version von Xcode 12 am Dienstag akzeptierte Apple keine Apps, welche mit der neuen Xcode-Version erstellt sind. Diese ist erforderlich, um Funktionen und Features von iOS 14 zu nutzen.

Begutachtung: Glücksspiel
In den vergangenen Jahren hat Apple glücklicherweise die Geschwindigkeit der Begutachtung von Apps deutlich erhöht: Wartete man vor 5 bis 10 Jahren manchmal 10 Tage oder mehr auf die Freigabe einer App, wird heute die Begutachtung meist innerhalb von 6 bis 24 Stunden durchgeführt. Seit dem Erscheinen der Golden Master von Xcode 12 dürfte das App-Store-Review-Team aber deutlich überlastet sein: Ob und welche App wann freigegeben wird, ist für Entwickler jetzt pures Glücksspiel. In der Vergangenheit reichte die Zeit meist aus, um fast alle Apps innerhalb einer Woche zu begutachten – doch 24 Stunden können hier unmöglich ausreichen.

Kommentare

ricoh17.09.20 08:35
Also die Apps, die immer regelmäßig entwickelt werden, sind jetzt schon aktualisiert. Die, wo man immer auf Updates wartet, brauchen auch diese mal länger. Das hat mit Apple wenig zu tun.
+12
Raziel117.09.20 08:36
Zeit zum Anfassen etc gab es kaum, wenn man bedenkt das die Betas oft noch voller Bis und spezifischem Verhalten sind, welche (hoffentlich) in der Releaseversion behoben sind. Leider kommt hier noch dazu das es grobe Bugs gibt die sich jetzt schon durch die Betas ziehen und auch in der unerwartet spontan veröffentlichten Release Version nicht behoben wurden.

Als Entwickler müssen wir also jetzt versuchen verrückte Workarounds für Grundfunktionen zu finden, die nicht richtig gehen, falls Überhaupt möglich.

Ich finde sie hätten hier die groben Sachen beheben sollen denn wenn schon Grundfunktionen nicht mehr richtig gehen dann kann man das bei Apple ja nicht einfach übersehen haben.
+3
Gammarus_Pulex
Gammarus_Pulex17.09.20 08:53
Also läuft 14 jetzt stabil?

Klingt ein wenig, dass die Bugs dort sind, wo die Entwickler noch nicht hinterherkamen, aber das eigentliche System gut läuft.
0
pünktchen
pünktchen17.09.20 08:56
ricoh
Also die Apps, die immer regelmäßig entwickelt werden, sind jetzt schon aktualisiert.

RTFA:
Vorher übermitteln: Geht nicht
+3
Solaris
Solaris17.09.20 09:17
Ich verstehe natürlich, dass die gegebenen Fristen dieses Mal reichlich knapp waren. Ich denke diese könnten auch aus den Statistiken, die Apple von bisherigen Upgrades hatte, resultieren.

Aber:

Wenn du dich als Entwickler an die Guidelines gehalten hast, läuft deine App ohne Probleme auch unter iOS 14. Das wäre m.E. mal das Wichtigste. Wenn du jetzt neue Features und Funktionen, die iOS 14 bietet, in der App verwenden willst, kannst du dies als Entwickler ab jetzt ja tun.

Ich finds nur ärgerlich, wenn nach einem iOS Update bestimmte Apps nicht mehr laufen, wobei dann gleich alle wissen dass du dich irgendwo nicht an die Vorgaben gehalten hast. Wenige Ausnahmen jetzt mal ausgenommen.
+5
Raziel117.09.20 09:23
Solaris
Ich verstehe natürlich, dass die gegebenen Fristen dieses Mal reichlich knapp waren. Ich denke diese könnten auch aus den Statistiken, die Apple von bisherigen Upgrades hatte, resultieren.

Aber:

Wenn du dich als Entwickler an die Guidelines gehalten hast, läuft deine App ohne Probleme auch unter iOS 14. Das wäre m.E. mal das Wichtigste. Wenn du jetzt neue Features und Funktionen, die iOS 14 bietet, in der App verwenden willst, kannst du dies als Entwickler ab jetzt ja tun.

Ich finds nur ärgerlich, wenn nach einem iOS Update bestimmte Apps nicht mehr laufen, wobei dann gleich alle wissen dass du dich irgendwo nicht an die Vorgaben gehalten hast. Wenige Ausnahmen jetzt mal ausgenommen.


Leider ist das nicht so einfach. Es gehen zb Elemente, und Funktionen aus SwiftUI von iOS13 in iOS14 nicht mehr richtig. Modals werden nicht mehr angezeigt, Inputfelder lassen die CPU auf 100% fahren, simple Events gehen nicht mehr oder feuern zum falschen Zeitpunkt und so weiter. Da hilft dir auch die beste Guideline nichts, wenn sich das alles fehlerhaft verhält

Die Liste an Bugs und Fehlverhalten die im Entwicklerforum gepostet werden ist ja nicht umsonst so lang. Wenn man Pech hat, dann geht in der App halt nichts mehr und man kann nur warten bis eine 14.1 erscheint die das behebt.

Fehler können sich immer einschleichen. Aber wenn plötzlich Grundfunktionen so verbuggt sind und dies schon seit 3 oder mehr Betas reported wird aber dann trotzdem nicht behoben werden, finde ich das schon merkwürdig.
+9
DTP
DTP17.09.20 09:30
Solaris
Wenn du dich als Entwickler an die Guidelines gehalten hast, läuft deine App ohne Probleme auch unter iOS 14. Das wäre m.E. mal das Wichtigste. Wenn du jetzt neue Features und Funktionen, die iOS 14 bietet, in der App verwenden willst, kannst du dies als Entwickler ab jetzt ja tun.

Ich finds nur ärgerlich, wenn nach einem iOS Update bestimmte Apps nicht mehr laufen, wobei dann gleich alle wissen dass du dich irgendwo nicht an die Vorgaben gehalten hast. Wenige Ausnahmen jetzt mal ausgenommen.
Das ist in der Regel nicht so.
  • Erstens, du musst ja als Entwickler die endgültige iOS Version testen. In allen Sprachen. Auf allen Geräten. Da kann einiges anders sein als noch in Betas. Wenn du was findest, sind 24h schon knapp um das zu beheben.
  • Zweitens hat Apple eine Historie, Sachen zu ändern ohne das du es vorher weißt.
  • Drittens sind die Entwickler bei Apple auch Menschen und machen Fehler. Da können also Bugs in der neuen iOS Version sein. Das findest du nur durch Testen.
  • Viertens kannst du Appversionen die iOS 14 voraussetzen, nicht einreichen, bevor iOS 14 nicht freigegeben ist. Da Apple so 1-3 Tage braucht um zu prüfen, sind 24h einfach zu kurz.
  • Und fünftens hat Apple das in der Vergangenheit immer anders gehandhabt. Auch wenn man daruas nicht schließen kann, dass das immer so sein wird, ging man als Entwickler schon davon aus, dass es diesmal auch wieder so eine Woche zum Testen und Einreichen geben würde.

Die Apps, die jetzt sofort und 100% problemlos funktionieren, haben vielleicht einfach nur Glück gehabt Oder du hast noch nicht alles ausprobiert?
+7
beanchen17.09.20 09:46
pünktchen
ricoh
Also die Apps, die immer regelmäßig entwickelt werden, sind jetzt schon aktualisiert.

RTFA:
Vorher übermitteln: Geht nicht
Sorry aber kannst du erst mal einen Kaffee trinken und dein Hirn aktivieren? Was hat das miteinander zu tun? Die Apps sind aktualisiert! Wenige Stunden nach erscheinen der GM mit Features von iOS 14. Wer behauptet bitte, dass die vorher übermittelt wurden? Sie lagen halt fertig in der Schublade, die Entwickler haben schnell reagiert und Apple schnell gearbeitet. Das ist eine Tatsache und keine Behauptung von ricoh.
-5
Retrax17.09.20 09:47
Es hiess doch letztes Jahr dass Apple den Qualitätsmanagementprozess für iOS 14 / Big Sur,... komplett überarbeitet und verbessert haben.

Und jetzt klingt die 14.0 nach der gleichen Baustelle wie iOS 13 letztes Jahr.

Spitzenleistung, Apple!
-4
pünktchen
pünktchen17.09.20 10:19
beanchen
Sorry aber kannst du erst mal einen Kaffee trinken und dein Hirn aktivieren?

Musst du eigentlich immer gleich pöbeln? Machst du das ausserhalb des Internets auch oder lädst du nur hier deinen Frust ab?
0
semmelroque
semmelroque17.09.20 10:19
Klingt für mich nach recht viel Murks. Ich bleib bis auf weiteres bei 13.6.1.
0
beanchen17.09.20 10:24
pünktchen
RTFA:
Vorher übermitteln: Geht nicht
... ist nicht pöbeln? Welcher Frust steckt da dahinter?
Ob im Internet oder im realen Leben, wer austeilt sollte auch einstecken können.
0
ApfelHandy4
ApfelHandy417.09.20 10:28
Retrax
Es hiess doch letztes Jahr dass Apple den Qualitätsmanagementprozess für iOS 14 / Big Sur,... komplett überarbeitet und verbessert haben.

Und jetzt klingt die 14.0 nach der gleichen Baustelle wie iOS 13 letztes Jahr.

Spitzenleistung, Apple!

Ich spreche hier jetzt mal aus der Perspektive eines Users (kein Entwickler), der iOS 14 seit der Public Beta 1 nutzt. Ich nutze ca. 100 Apps sehr regelmäßig und bis auf die Apps von Sky (Q und Ticket), die von vorne bis hinten absoluter Code-Müll sind, egal auf welcher Platform, haben alle Apps ohne Einschränkungen funktioniert und die Performance des Systems war von Beginn an sehr gut. Einige wenige Darstellungsfehler wurden behoben und das System fühlt sich (für mich) mit der finalen Version nun wirklich auch "fertig" an. Kein Vergleich zum iOS 13-Drama!

Und bevor jetzt einer kommt mit "Mimimimimi, die Betas sind für Entwickler, nicht für Nutzer, ...": ich habe schon immer die Public Betas (auf Zweitgeräten) benutzt und schon immer auch Fehler gemeldet.
+4
pünktchen
pünktchen17.09.20 10:28
Nein, RTFA ist nicht pöbeln sondern ein Hinweis auf den Text.
-2
fox_rc17.09.20 11:12
ApfelHandy4

Ja, Sky (Ticket) nervt wirklich. Habe die tvOS-Betas installiert. Schon unter OS13 sind die Sky-Apps auf der jeweiligen Plattform ein Graus und vom fehlerfreien Funktionieren weit entfernt. Videos/Filme funktionieren unter OS14 (tvOS) gar nicht. Das ist bei einem Inhalte-Anbieter vorsichtig ausgedrückt ein echtes Armutszeugnis
+1
Bananenbieger17.09.20 11:24
Solaris
Wenn du dich als Entwickler an die Guidelines gehalten hast, läuft deine App ohne Probleme auch unter iOS 14.
Nein. Das war bei Apple noch nie so. Weder bei iOS, noch bei macOS.

Ich mag ja Apple wirklich und das Entwicklen für iOS und Mac macht auch Spaß, aber Apple ist wirklich nicht gut in Sachen Abwärtskompatibilität.
Da werden ohne Vorwarnung APIs geändert oder plötzlich gibt es neue Bugs in eigentlich stabilen APIs.
Dazu kommt noch, dass Apple vieles grottenschlecht oder sogar gar nicht dokumentiert.

Mit Windows haben wir diese Probleme nicht. Da laufen unsere Applikationen problemlos seit Dekaden. Sogar Uraltversionen können noch unter Windows 10 betrieben werden.
+6
Retrax17.09.20 13:04
Bananenbieger
Mit Windows haben wir diese Probleme nicht. Da laufen unsere Applikationen problemlos seit Dekaden. Sogar Uraltversionen können noch unter Windows 10 betrieben werden.
Ja, weil MS sein Windows-OS halt seit Dekaden immer wieder "hinbiegt" so dass auch die krümmsten Bananen-Apps noch laufen - auf wessen Kosten das geht wissen wir ja:

Das MS-System ist seit Dekaden der selbe S....
Und aus Kompatibilitätsgründen, welche eingefordert werden, wird das auch nichts mehr.
-3
pünktchen
pünktchen17.09.20 13:30
Jaja wenn man nicht die Fähigkeit hat zu erahnen welche APIs Apple demnächst ändern wird dann muss man wohl ein unfähiger Programmierer sein. 🙄
0
Mecki
Mecki17.09.20 20:05
War denn irgend eine Änderung für das neue System zwingend erforderlich? Ansonsten, was ist denn so schlimm, wenn die Nutzer erst mal eine Zeit lang die bisherige Version einfach weiter nutzen? Dann bekommen sie halt ein neues Feature ein bisschen später, sehe da nicht das große Problem. Ich hab das Update gleich eingespielt (sonst warte ich eigentlich etwas damit) und alle meine Apps funktionieren ohne Probleme, ohne das davon eine extra für 14 ein Update erhalten hat (die werden mir jetzt schon teilweise angeboten, aber zwingend erforderlich war davon bisher keines).

Die meisten Apps brechen bei Upades, weil die Entwickler sich auf etwas verlassen, das nie garantiert wurde oder weil die Entwickler nicht lesen, was Apple in der Doku schreibt, wie man etwas tun soll (sie tun es anders, was bisher auch ging, dann aber bricht, während der Weg aus Doku weiter funktioniert).

Testfrage für Programmierer: Was liefert diese Funktion zurück?

/// @return A random value.
int getRndValue ( ) { 
    return 42;
}

Jeder der sagt "Na 42", ist genau in die Falle getappt. Die Funktion liefert eine zufällig Zahl zurück. Das impliziert ihr Name und das sagt die Dokumentation und nur darauf darf man sich verlassen. Wer sich darauf verlässt, dass sie 42 liefert, dessen Code wird brechen, wenn sie es nicht mehr tut.
-5
Raziel118.09.20 06:47
Mecki
War denn irgend eine Änderung für das neue System zwingend erforderlich? Ansonsten, was ist denn so schlimm, wenn die Nutzer erst mal eine Zeit lang die bisherige Version einfach weiter nutzen? Dann bekommen sie halt ein neues Feature ein bisschen später, sehe da nicht das große Problem. Ich hab das Update gleich eingespielt (sonst warte ich eigentlich etwas damit) und alle meine Apps funktionieren ohne Probleme, ohne das davon eine extra für 14 ein Update erhalten hat (die werden mir jetzt schon teilweise angeboten, aber zwingend erforderlich war davon bisher keines).

Die meisten Apps brechen bei Upades, weil die Entwickler sich auf etwas verlassen, das nie garantiert wurde oder weil die Entwickler nicht lesen, was Apple in der Doku schreibt, wie man etwas tun soll (sie tun es anders, was bisher auch ging, dann aber bricht, während der Weg aus Doku weiter funktioniert).

Testfrage für Programmierer: Was liefert diese Funktion zurück?

/// @return A random value.
int getRndValue ( ) { 
    return 42;
}

Jeder der sagt "Na 42", ist genau in die Falle getappt. Die Funktion liefert eine zufällig Zahl zurück. Das impliziert ihr Name und das sagt die Dokumentation und nur darauf darf man sich verlassen. Wer sich darauf verlässt, dass sie 42 liefert, dessen Code wird brechen, wenn sie es nicht mehr tut.


Da weiß man garnicht wo man anfangen soll Mecki

Nochmal Grundfunktionen, die unter iOS13 gehen, und so unverändert weiterhin gehen sollten, gehen nicht mehr, die neuen Funktionen habe ich, bis auf 1-2 neue Methoden, noch garnicht getestet´, weil ich seit 3 Tagen durchgehend nur versuche die Apps wieder zum laufen zu bringen mit jeder Menge Workarounds, die nicht notwendig sein sollten.

Beispiel SwiftUI Modifier tun nicht mehr das was dokumentiert ist, Popups/Moduls erscheinen nicht mehr obwohl sie es sollten, Text wird falsch gerendert und erscheint ohne Farbe bzw weiß auf weißen Hintergrund, native Textfelder können die CPU auf 100% treiben und das bleibt dann auch so. Event Handler werden zum falschen Zeitpunkt gefeuert und zum richtigen teilweise garnicht mehr. Eine der neuen iOS14 Methoden die ich gestern getestet habe hat gleich garnicht funktioniert und so weiter.

Das hat nichts mit neuen Funktionen zu tun. Es bedeutet das bereits einwandfrei funktionierende Apps einfach nicht mehr gehen und, wenn man Pech hat und kein Workaround für die Bugs findet, sie auch so lange nicht mehr unter iOS14 laufen, bis Apple ein iOS Update bringt welches den Soll-Zustand wiederherstellt.

Für dein schönes Beispiel oben Als Entwickler sieht man nur die Methode und die Doku was sie machen soll, nicht wie sie funktioniert. Nun stell dir vor beim nächsten Update liefert die getRndValue Methode plötzlich nur noch die selbe Zahl egal was man macht und trotz gegenteiliger Dokumentation. Dann ist deine App vermutlich hinüber.

Für Aussenstehende mag das dann so wirken, wie in deinem Text beschrieben, ist aber leider völlig realitätsfern. Und wir sprechen hier nicht von komplexen Funktionen und Abläufen, sondern einfach nur von grundlegenden Features.

Wenn z.B. ein onAppear-Modifier, den man in all seinen Views für bestimmte Aktionen beim erscheinen der Views verwendet, nach dem Update plötzlich nicht mehr beim Erscheinen, sondern beim "disappear" feuert (zusammen mit dem echten onDisappear) und dann beim richtigen Erscheinen garnicht mehr, fragt man sich als Entwickler, wie es sowas überhaupt in eine Release Version schaffen konnte.
+1
DTP
DTP18.09.20 09:00
Mecki
Die meisten Apps brechen bei [iOS] Upades, weil die Entwickler sich auf etwas verlassen, das nie garantiert wurde oder weil die Entwickler nicht lesen, was Apple in der Doku schreibt, wie man etwas tun soll (sie tun es anders, was bisher auch ging, dann aber bricht, während der Weg aus Doku weiter funktioniert).
Hast du irgendeinen Indiz für deine Behauptung? Oder ist das einfach eine Vermutung von dir?
+2
Mecki
Mecki18.09.20 11:00
Raziel1
Nochmal Grundfunktionen
Hier geht es schon los. Diesen Begriff gibt es gar nicht. Es gibt keine "Grundfunktionen", denn dieses Begriff legt nahe, dass eine Einteilung in Basisfunktionen und zusätzliche Funktionen existiert, was nicht der Fall ist. Daher ist dieser Begriff auch nicht definiert.

Beispiel SwiftUI
... das jeder vernünftige Entwickler aktuell als Betastadium betrachtet und niemals für wichtige, kommerzielle Entwicklungen nutzen würde ...
Modifier tun nicht mehr das was dokumentiert ist
was dann aber schlichtweg ein Bug und keine beabsichtigte Änderung ist. Und genau wegen solchen Kinderkrankheiten ist SwiftUI noch nicht ready for primetime.
Popups/Moduls erscheinen nicht mehr obwohl sie es sollten, Text wird falsch gerendert und erscheint ohne Farbe bzw weiß auf weißen Hintergrund,
Also Bugs. Wenn du um die jetzt herum arbeitest und Apple die dann aber behebt, dann brechen am Ende wieder deine Workarounds. Hier beschreibst du genau das Fehlverhalten, das Entwickler eben nicht an den Tag legen sollten und das für fast alle Probleme am Ende verantwortlich ist.
Nun stell dir vor beim nächsten Update liefert die getRndValue Methode plötzlich nur noch die selbe Zahl egal was man macht und trotz gegenteiliger Dokumentation.
Dann ist das korrekt, weil 42 ist so zufällig wie jede andere Zahl auch. Sofern da keine andere Doku ist als die von mir gezeigte, ist nicht dokumentiert, dass es unwahrscheinlich oder gesichert ist, dass mehrere Aufrufe der Funktion nicht immer die gleiche Zahl liefern werden. Dokumentiert ist nur, dass sie "irgend eine zufällig gewählte Zahl liefert" und das tut sie. 42 ist irgend eine zufällig gewählte Zahl. Das diese Zahl durch einen Zufallsgenerator erzeugt wird, das steht da nicht. Das interpretierst du da rein, keine Ahnung woher die Basis für diese Interpretation stammen soll. Wenn du gut verteilte Zufallswerte brauchst, dann solltest du diese Funktion nicht nutzen, sondern eine, für die dokumentiert ist, dass sie gut verteilte Zufallswerte liefert. Du zeigst hier überdeutlich das Problem, dass ich aufzeigen wollte, danke, besser hätte man das nicht belegen können.
-2
Mecki
Mecki18.09.20 11:05
DTP
Hast du irgendeinen Indiz für deine Behauptung?
Schau dir nur die Antwort von Raziel1 an. Auch er interpretiert eigenmächtig etwas in meine Beispielfunktion, das nirgendwo dokumentiert ist.

Bei kommerziellen Apps kann ich dir das nicht belegen, weil ich nicht an deren Code komme, allerdings wenn da eine nach einem Update an einer bestimmten Stelle bricht, dann kann ich dir sagen, warum das wahrscheinlich passiert ist (was der Entwickler da tut und was er eigentlich tun soll). Tatsächlich belegen kann ich dir das, wenn das eine OpenSource App ist, weil dann sieht man wie der Code aussieht und das er nicht so aussieht, wie er laut Doku hätte aussehen sollen: Dinge die man unbedingt tun soll werden nicht getan, Dinge die man nicht tun sollen werden getan und Empfehlungen, wie man es am besten tut wurden komplett ignoriert.
-1
DTP
DTP18.09.20 11:22
Mecki
DTP
Hast du irgendeinen Indiz für deine Behauptung?
Schau dir nur die Antwort von Raziel1 an. Auch er interpretiert eigenmächtig etwas in meine Beispielfunktion, das nirgendwo dokumentiert ist.
"auch er"? Du rechtfertigst also, eine Vermutung als Fakt zu präsentieren, weil andere angeblich das auch tun?
Mecki
Bei kommerziellen Apps kann ich dir das nicht belegen, weil ich nicht an deren Code komme, allerdings wenn da eine nach einem Update an einer bestimmten Stelle bricht, dann kann ich dir sagen, warum das wahrscheinlich passiert ist (was der Entwickler da tut und was er eigentlich tun soll).
"Ich kann es nicht belegen aber sagen warum etwas wahrscheinlich passiert…" ist eine subjektive Äußerung.
Oben schreibst du "Die meisten Apps brechen bei [iOS] Upades, weil die Entwickler sich auf etwas verlassen, das nie garantiert wurde oder weil die Entwickler nicht lesen…"

Siehst du den Unterschied? Du stellst erst etwas als Fakt hin und auf Nachfrage ist es eine nicht belegbare Vermutung oder eine Annahme eines deiner Meinung nach wahrscheinlichen Grundes.

Vermeide doch so etwas bitte; wir haben in der Welt (und hier im Forum) schon genug Menschen, die Behauptungen aufstellen, die ihrer Meinung nach natürlich wahr sind.

Meinungen sind super, wir haben alle Meinungen und Eindrücke, die aus unserer Erfahrung und Umwelt entstehen. Nicht-belegbare Eindrücke oder Vermutungen als "Wahrheit" darzustellen helfen nMn weder der Diskussion (und damit der Meinungsbildung) noch unserer Gesellschaft. Danke.
-1
pünktchen
pünktchen18.09.20 11:25
Mecki
Dann ist das korrekt, weil 42 ist so zufällig wie jede andere Zahl auch.

Öhm nö. 42 ≠ zufällige Zahl. 42 = 42.
0
Raziel118.09.20 11:26
Mecki
Raziel1
Nochmal Grundfunktionen
Hier geht es schon los. Diesen Begriff gibt es gar nicht. Es gibt keine "Grundfunktionen", denn dieses Begriff legt nahe, dass eine Einteilung in Basisfunktionen und zusätzliche Funktionen existiert, was nicht der Fall ist. Daher ist dieser Begriff auch nicht definiert.

Beispiel SwiftUI
... das jeder vernünftige Entwickler aktuell als Betastadium betrachtet und niemals für wichtige, kommerzielle Entwicklungen nutzen würde ...
Modifier tun nicht mehr das was dokumentiert ist
was dann aber schlichtweg ein Bug und keine beabsichtigte Änderung ist. Und genau wegen solchen Kinderkrankheiten ist SwiftUI noch nicht ready for primetime.
Popups/Moduls erscheinen nicht mehr obwohl sie es sollten, Text wird falsch gerendert und erscheint ohne Farbe bzw weiß auf weißen Hintergrund,
Also Bugs. Wenn du um die jetzt herum arbeitest und Apple die dann aber behebt, dann brechen am Ende wieder deine Workarounds. Hier beschreibst du genau das Fehlverhalten, das Entwickler eben nicht an den Tag legen sollten und das für fast alle Probleme am Ende verantwortlich ist.
Nun stell dir vor beim nächsten Update liefert die getRndValue Methode plötzlich nur noch die selbe Zahl egal was man macht und trotz gegenteiliger Dokumentation.
Dann ist das korrekt, weil 42 ist so zufällig wie jede andere Zahl auch. Sofern da keine andere Doku ist als die von mir gezeigte, ist nicht dokumentiert, dass es unwahrscheinlich oder gesichert ist, dass mehrere Aufrufe der Funktion nicht immer die gleiche Zahl liefern werden. Dokumentiert ist nur, dass sie "irgend eine zufällig gewählte Zahl liefert" und das tut sie. 42 ist irgend eine zufällig gewählte Zahl. Das diese Zahl durch einen Zufallsgenerator erzeugt wird, das steht da nicht. Das interpretierst du da rein, keine Ahnung woher die Basis für diese Interpretation stammen soll. Wenn du gut verteilte Zufallswerte brauchst, dann solltest du diese Funktion nicht nutzen, sondern eine, für die dokumentiert ist, dass sie gut verteilte Zufallswerte liefert. Du zeigst hier überdeutlich das Problem, dass ich aufzeigen wollte, danke, besser hätte man das nicht belegen können.


Autsch: Also ich weiß es ja nicht aber man müsste annehmen das du selber nicht entwickelst oder nicht in so einem Umfeld tätig bist andernfalls kann man sich deine Aussagen nicht erklären.

Du hast ein simples Beispiel gebracht und ich habe dir auf dessen Basis ein realitätsnahes Gegenbeispiel gebracht. Nun intepretierst du da 10 mal mehr rein als irgendwo irgendwo gesagt hat. Fakt ist: Es gibt Funktionen, es gibt genaue Dokumentationen. Wenn die Funktion nicht das tut was in der Doku steht ist das ein Bug (oder einen inkorrekte Doku). Fakt ist auch das Entwickler dafür zu sorgen haben das ihre Programme laufen, denn es gibt üblicherweise User die diese auch verwenden und Entwickler programmieren selten nur aus reiner Freude für sich alleine. Zumindest nicht beruflich. Wenn also ein neues iOS erscheint das nun alle oder ein Großteil der Kunden haben, dann können wir nicht warten bis Apple das vielleicht oder nie fixt (oft leider nie, es gibt Bugs die schon Jahre mitgezogen und nie behoben wurden).

"Also Bugs. Wenn du um die jetzt herum arbeitest und Apple die dann aber behebt, dann brechen am Ende wieder deine Workarounds. Hier beschreibst du genau das Fehlverhalten, das Entwickler eben nicht an den Tag legen sollten und das für fast alle Probleme am Ende verantwortlich ist."

Es ist schön das du mir erklärst das das Bugs sind. Das wissen wir als Entwickler auch alle. Nur einfach alles so lassen und die Apps laufen dann beim User nicht mehr ist leider keine bzw eine völlig realitätsfremde Lösung.

Wollen wir umständliche Workarounds einbauen, die irgendwann eventuell nicht mehr gehen? Natürlich nicht!

Am liebsten würden wir alles so lassen wir es in der Doku steht und darauf hoffen das das nächste Update alles wieder hinbiegt und es so geht wie es soll. Aber leider weist du als Entwickler weder wann so ein Update kommt, noch ob überhaupt. In der Realität ist es dann oft so das beim nächsten Update sogar noch ganz andere Dinge plötzlich bugs enthalten die vorher noch gelaufen sind und deine Probleme weiterhin nicht behoben sind.

Finde ich dann halt spannend das deiner Meinung nach die Entwickler schuld daran haben...

"das jeder vernünftige Entwickler aktuell als Betastadium betrachtet und niemals für wichtige, kommerzielle Entwicklungen nutzen würde"

Achso also da ist jetzt die Empfehlung Apples und die Dokumentation und auch die teilweise Notwendigkeit es zu verwenden alles nichts mehr wert weil "jeder vernünftige Entwickler" sagt es wäre ja noch Beta. Also jetzt doch gegen den Strom an Vorgabe, Doku und Apples Empfehlung? Mir kommt vor du kannst dich selber nicht entscheiden wie Entwickler nun vorgehen sollten.
+2

Kommentieren

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