Cross-Plattform-Apps sind für die Anbieter natürlich ein Gewinn, für die Nutzer fast immer ein Nachteil.
Seit dem Erfolgszug von Android, sind immer mehr iOS-Apps nur noch schlecht auf das UI von iOS angepasst. Überfall findet man den schrecklichen Hamburger-Button .
In der Tagesschau-App, um nur ein Beispiel zu nennen, funktioniert das Scrollen nicht, je nachdem wo man anfässt, und ruckelt auch meist, auch das eine Konsequenz von Cross-Plattform oder WebView-Verwendung.
Und dabei hat sich Apple doch damals wirklich alle Mühe gemacht, das sauber hinzubekommen und die Unterscheidung von Tap- und Wisch-Gesten und den Übergang dazwischen sicher zu erkennen. Aber kaputt bekommt man alles, wenn man es selber nochmal implementiert...

Ja, diese Grossplattform-Seuche verbreitet sich immer mehr. Youtube ist eines der grauseligsten Beispiele. Wie schaut das eigentlich mit der Bedienungshilfen-Unterstützung bei so Dingern aus?

Apple wirbt ja immer damit, dass Swift eine hochoptimierte, schnelle Programmiersprache ist.
Werden dann auch alle Android Geräte wesentlich schneller?
Ist das nicht schlecht für Apple?

Das wäre in jedem Falle super für Apple!

1. Google würde vorhandene Android Entwickler total vor den Kopf stoßen
2. Apple könnte die Verbreitung von SWIFT erheblich beschleunigen
3. Android Entwickler könnten schnell iOS Apps anbieten

GROßER NACHTEIL:

iOS Entwickler könnten schnell auch Android Apps anbieten

Warum vor den Kopf stoßen? Java muss ja nicht verschwinden.

Cool, Java ist eine ziemlich fehlgeleitete Sprache. Das größte Problem ist dass Java den Programmierer zwingt objektorientiert zu programmieren. Damals wurde Objektorientierung als die große Offenbarung angesehen die die Zukunft sein sollte. Aber teilweise schafft dieses Paradigma mehr Probleme als es löst, und das ist zum Großteil weil Objektorientierung falsch gelehrt wird. Dieses Video erklärt sehr gut worum es wirklich geht (ab der 29. Minute wer nicht Zeit für das ganze Video hat):
https://www.youtube.com/watch?v=QHnLmvDxGTY

Und dieses Video erklärt warum reines OOP schlecht ist:
https://www.youtube.com/watch?v=QM1iUe6IofM

OOP ist aber kein schlechtes Paradigma, das Problem ist wenn man gezwungen ist es zu verwenden. C++ zum Beispiel bietet OOP an, aber man muss es nicht verwenden wenn es nicht angebracht ist. Und Swift ist auch so eine Sprache.

…wenn das so läuft wie bei WebKit, dann kann eher Apple davon profitieren, dass Google das mal so _richtig_ vorantreibt…

Meiner Erinnerung nach kommt das Hamburger-Menü (ich persönlich mag es ja sehr gern) aber gar nicht von Android? Wir haben doch die drei senkrechten Punkte.

Den verlinkten Artikel über das Hamburger-Menü finde ich richtig schlecht. „Less discoverable“ ist ja wohl kaum ein Bedienelement, welches in jeder App verwendet ist. Selbst die Menü-Reinwischgeste, die ohne sichtbares Element auskommt, ist doch längst in Fleisch und Blut übergegangen.

Was ist deiner Meinung nach falsch daran?

Ich bin kein Java-Entwickler, ich entwickle auch keine Gerätetreiber o.ä., aber gibt es noch irgendeine gängige Software, die nicht OO entwickelt wird? Ernsthaftes Interesse. Bin PHP Entwickler.

In dem Artikel steht doch überhaupt nichts davon Java zu ersetzen, maximal könnte man rauslesen, dass ganz vielleicht irgendwann Swift als zusätzliche Sprache unterstützt werden könnte.

Das von Apple empfohle GUI-Element für die wichtigsten Funktion einer App ist der TabBar und den ziehe ich jedem Hamburger-Menü vor.

Es gibt auch gute Hamburgermenüs, muss nicht alles per se schlecht sein, aber natürlich, UITabBarController ist das Mittel der Wahl.

Viele Entwickler "ärgern" sich das auf dem iPhone 4s dann wenig Platz ist.

Was haben Hamburgermenüs oder UITabBarController mit Swift für Android zu tun? Es geht doch um das Verwenden der gleichen Sprache, nicht der gleichen APIs.

Garnix, aber Diskussionen schweifen gelegentlich aus.

Der MTN-Artikel spricht von den Vorzügen der Cross-Platform-Entwicklung für Entwickler, also ist es sehr wohl "on topic", die Nachteile für User zu diskutieren!

Kann sein, ich meinte ja auch nur, dass der „Hamburger“ nicht von Android käme. Ich habe grad noch mal nach alten Android-Screenshots gegoogelt, da sind überall die Drei-Punkte-Buttons drauf.

Mir ist nur wichtig, dass Bedienelemente normalerweise gar nicht sichtbar sind. Das nimmt nur Platz weg. Material Design verwendet meist gar keine sichtbaren Elemente mehr, die Menüs erreicht man durch reinwischen von links — vorher ist alles unsichtbar.

Ist grundsätzlich zu begrüßen. Cross Plattform noch einfacher und zudem käme das bestimmt auch der Performance auf Android zu Gute. Apple bekäme eine gewisse yleistungskonkurrenz und wäre zu mehr Innovationstätigkeit genötigt um seine hohen Preise weiterhin zu rechtfertigen. Tolle Sache, glaube selbst aber nicht das Swift es schaffen wird auf Android.

+1

So ist es.

Zumal Google sich bereits entschieden hat und schon kräftig umgestellt hat und noch weiter umstellt auf OpenJDK /, der freien Community-Version von Java, welche Grundlage und von Oracle anerkannte Referenzimplementierung des von Oracle herausgegebenen Java ist (Oracle ist leitendes OpenJDK Community-Mitglied, ebenso sind dort an OpenJDK Mitarbeitende Mitglieder, so z.B. auch IBM, SAP, Apple? und auch Google):

Golem (30.12.2015): OpenJDK: Nächste Android-Version soll mit Open-Source-Java kommen
Google wechselt von Oracles proprietärem Java Development Kit (JDK) zur Open-Source-Variante OpenJDK. Hintergrund dürfte auch ein jahrelanger Rechtsstreit um die Nutzungsrechte der Java-APIs sein, der noch nicht beendet ist.


heise (04.01.2016): Android N: Googles Mobilsystem wird auf Open-Source-Java OpenJDK aufsetzen
Technische, aber auch rechtliche Gründe dürften dafür sprechen, dass die nächste Version von Googles mobilem Betriebssystem auf der Open-Source-Implementierung von Java aufbauen wird.
Quelle: Wikipedia (de), OpenJDK

Googles bisherige Java-APIs und Java-Klassen sind ursprünglich entnommen dem inzwischen eingestellten Apache Harmony-Projekt , einer freien Community-gemanagten Clean-Room-Implementierung von Sun/Oracles Java, jahrelang ganz wesentlich von IBM vorangetrieben. Googles Dalvik VM ist eine völlig neu entwickelte VM, in welcher diese von Harmony übernommenen Java-Klassen und -APIs nutzt bzw bereitstellt, welche inzwischen von Google auf die Klassen und APIs von OpenJDK umgestellt werden bzw. sind.

Als IBM aufgrund Bittens und Druck von Oracle aus dem Apache Harmony-Projekt ausstieg und stattdessen in das von Oracle geführte Konkurrenz-Projekt OpenJDK einstieg, hat das Harmony-Projekt seinen größten Zuträger und Motor verloren, kurze Zeit später wurde Harmony offiziell eingestellt, das Projekt ist inzwischen offiziell tot.

Golem (05.05.2011): Android-Streit: Oracle lässt Apache vorladen
Im Streit mit Google um Urheberrechtspatentverletzungen durch Android hat Oracle der Apache Software Foundation (ASF) eine Vorladung geschickt. ASF soll zur Verwendung des Codes seiner Java-Implementierung Projekt Harmony in Android aussagen.

Golem (18.03.2011): Java: Harmony-Projektleiter Tim Ellison tritt zurück
Das Projekt Apache Harmony verliert seinen Project Management Chair Tim Ellison: Er hat seinen Rücktritt erklärt. Zuvor hatte schon Ellisons Arbeitgeber IBM die Unterstützung des Harmony-Projekts eingestellt und sich an Oracles Projekt OpenJDK beteiligt.

Golem (10.12.2010): Java: Apache verlässt den Java Community Process
Die Apache Software Foundation (ASF) macht ihre Drohung wahr und verlässt mit sofortiger Wirkung das Exekutivkomitee des Java Community Process (JCP). Sie kündigt zugleich an, sich komplett aus dem JCP zurückzuziehen.

Golem (10.11.2010): Java: Apache Software Foundation droht Oracle
Die Apache Software Foundation (ASF) geht auf Konfrontationskurs zu Oracle und droht mit dem Ausstieg aus dem Java Community Process.

Golem (22.10.2010): Java: Apache Foundation hält an Harmony fest
Die Apache Software Foundation steht weiterhin zu ihrer freien Java-Implementierung Harmony, obwohl Oracle dem Projekt die notwendige Lizenz verwehrt und sich IBM als bisher größter Harmony-Unterstützer entschieden hat, künftig das Konkurrenzprojekt OpenJDK zu unterstützen.

Golem (12.10.2010): OpenJDK: Oracle und IBM arbeiten bei Java künftig zusammen
Gemeinsam wollen Oracle und IBM das Projekt OpenJDK zur führenden freien Open-Source-Implementierung machen und bei der Java-Entwicklung künftig eng zusammenarbeiten. Dem Apache Project Harmony kehrt IBM weitgehend den Rücken.

Da auch Google als OpenJDK-Mitglied ganz kräftig in OpenJDK investiert hat und immer noch investiert und dazu beiträgt, ist kaum anzunehmen, dass sie dieser Plattform und Sprache so schnell den Rücken kehren werden. Es würde vor dem ganzen Hintergrund sowohl wirtschaftlich als auch technisch kaum Sinn ergeben.

Und dennoch:

Golem (06.01.2016): OpenJDK: Oracle könnte GPL gegen Android-Hersteller einsetzen
Google nutzt künftig das GPL-lizenzierte OpenJDK in Android. Da Oracle jedoch das Urheberrecht an der Java-Implementierung hält, könnten auf die Gerätehersteller Klagen und hohe Lizenzkosten zukommen.

Igitt, noch mehr Java-Schrott.

PaulMuadDib:

Solltest Du da evtl. was durcheinanderbekommen haben und eigentlich das regelmäßig fehlerbehaftete clientseitige Browser-Plugin (welches eine JRE, eine Java Runtime Environment zur Verfügng stellt bzw. umhüllt) meinen, das aber mit der serverseitigen und allgemeinen Nutzung von Java nichts zu tun hat und auch Java als Programmiersprache im Allgemeinen damit nicht infrage gestellt ist? Dieses ins Gerede gekommene Java Browser-Plugin wird zudem von Oracle eh bald offiziell abgeschafft und eingemottet (u.a. weil langsam überflüssig und auch nicht mehr API-kompatibel mit modernen Browsern).

Java hat dank Android wieder einen enormen Popularitätsschub erfahren, und im Enterprise-Bereich (Banken-, Börsen- und Finanzsektor, Dienstleistungssektor im Allgemeinen) hat es seit Jahren ein festes Standbein bzgl. servergestützter Anwendungen. Auch Apples Online Store basierte jahrelang und bis vor noch nicht allzu langer Zeit auf Java (JSP, Java Server Pages).

Was denkst Du, wie egal mir das ist? Das einzige, was ich täglich davon mitbekommen, sind grauenhafte Inkompatibilitäten. Sowas wie Abwärtskompatibiltät scheint es nicht zu geben. Oder es gibt nur unfähige Programmierer. Es dauert immer Monate, herauszupuzzeln, welche Java-Version auf die nächste Musterplatte soll. Es ist eine Pest. Und es ist ein Sicherheitsloch. Für mich gehört dieser Müll entsorgt. Direkt nach Flash.

Du meinst wahrscheinlich WebObjects … das sind aber keine JSPs.
Es basiert seit 5.0 auf Java, vorher Objective-C.

OT: Ich sehe das eher mit Bauchweh als mit Freude …
allein der Gedanke an UI-Bibliotheken, die dann auf beiden Plattformen laufen, aber auf keiner an die Standards halten.

PaulMuadDib:

Egal ist 88.
Ich habe Dir eben klargemacht, dass das Java-Plugin, das Du meinst und nicht magst, ungleich Java ist. Es ist nicht gleichbedeutend mit Java. Es ist eine kleine Teilmenge davon, ein ganz winziger und inzwischen sehr verzichtbarer Teil der Implemenetierung von Java.

Eine Verallgemeinerung, wie Du sie hier tätigst, dieses Plugin als Synonym und Sündenbock herzunehmen für alles, was mit Java zu tun hat, ist hier einfach nicht angebracht und fehl am Platze.

Das wäre in etwa genauso, als wenn Du per Pauschalurteil das Auto als Fortbewegungsmittel per se verdammen würdest, nur weil VW oder einzelne Hersteller beim Abgastest betrogen und Scheiße gebaut haben.

LoCal:

Ja, ich meine WebObjects. Wenn's keine JSPs waren, warum hat Apple dann Seiten mit .jsp-Endung gehabt und ausgeliefert (teilweise immer noch per Google zu finden)?

LoCal:

Apple Developer Library Documentation: WebObjects J2EE Programming Guide (Legacy) (PDF)

Abschnitt JavaServer Pages
Seite 20-38

LoCal:

Was genau siehst Du eher mit Bauchweh als mit Freude?


Zudem sehr interessant und aufschlussreich (inkl. Kommentaren):

Andreas Gal Blog (05.01.2016), Ex-CTO Mozilla: Oracle sinks its claws into Android

Schön wenn du damit zurechtkommst, viele Nutzer haben damit aber erhebliche Probleme. Solche UIs sind extrem schwierig zu erfassen, weil es eben unsichtbar und wenn man es erlernt hat kann man es schlecht merken, weil es eben nichts Sichtbares zum Einprägen gibt.
Hinzu kommt, dass das Hereinwischen von außen häufig mit anderen Aktionen kollidieren kann.

Mein Hauptgruselgrund haben ich oben ja schon beschrieben:
Es werden Crossplattform-UI-Frameworks en masse produziert und keine macht es auf einer Plattform richtig, sondern es gibt ein riesiges Mischmasch. Mit grauen denke ich an three20.

Ein weiterer Grund:
Ich will jetzt nicht über WebKit oder Blink werten, eher über die Vorgehensweise da.
Google war auf den WebKit-Zug aufgesprungen und hat den auch ganz schön vorangetrieben. Der fork zu Blink hat bei mir aber einen faden Beigeschmack hinterlassen … für mich sah das eher nach einer politischen als einer technischen Notwendigkeit aus.

Ja, aber wovon genau redest Du? Wobei werden oder würden "Crossplattform-UI-Frameworks en masse produziert und keine macht es auf einer Plattform richtig"? Worauf bezogen und bei welcher Wahl von wem auf was? Swift? Java? OpenJDK? Bahnhof? Kühlschrank?

Beides: politisch wie auch technisch. Frag' mal Opera (die diesen Schritt jahrelang herbeigesehnt haben und Google öffentlich geradezu danach gebeten haben, diesen Schritt zu tun:

Opera Blog (06.05.2010): Dear Google: Please fork WebKit

Opera u.a. wegen Apples Lahmarschigkeit beim Fixen von Bugs und auch beim zeitnahen Umsetzen von Webstandards. Da ist Opera nicht der Erste und nicht der Einzige, der sich darüber beschwert hat, die Liste derer, die mit Apple daäußerst unzufrieden sind, ist sehr lang, viele Webentwickler am Puls der Webentwicklung da draußen handeln den Safari und dessen Nicht-Können aktueller Webstandards und und Webtechnologien inzwischen als neuen Bremsklotz im Gewerbe, als neuen IE6, Apple erlaubt sich hier seit einiger Zeit weitehenden Stillstand im Gegensatz zu allenanderen Browser-Herstellern, und das bremst die Webentwicklung insgesamt total aus, weil's halt ein nicht unwichtiger Browser ist mit nicht unwichtiger Verbreitung, auf den somit notgedrungen Rücksicht genommen werden muss bisher, und die Stimmen mehren sich, diesen Browser bei der Rücksichtnahem so langsam links liegen zu lassen und ihn zu ignorieren, so ähnlich, wie man es dann endlich auch mal mit dem IE6 gemacht hatte.

Und auch Microsoft. Welche Blink und WebKit näher für sich selber begutachtet gehabt haben und dem von Google geführten Blink eine dauerhafte technische Überlegenheit und somit eine rosigere Zukunft gegenüber dem von Apple geführten WebKit attestiert haben, trotzdem haben sie sich am Ende für keinen der beiden entschieden, sondern für Edge ihr eigenes Ding gemacht - aus rein politischen Gründen, um weder von Googles noch von Apples Entscheidungen abhängig zu sein, wie sie offen zugegeben haben, obwohl sie von Blink extrem angetan und dessen technischer Überlegenheit gegenüber WebKit überzeugt waren:

derStandard.at (20.01.2015): Spartan: Warum Microsoft auf Webkit verzichtet hat
Hitzige interne Debatte über Browser-Engine

Paul Thurrott (19.01.2015): So Maybe Windows 10’s Spartan Isn’t Going to Suck