Vermeide 3rd-Party Frameworks

Um sich vermeintlich die Arbeit zu erleichtern und nichts von dem verstehen zu müssen, was sie da tun, neigen viele Entwickler dazu, ihre Apps mit 3rd-Party-Frameworks vollzustopfen. Meist finden sie das auch noch cool, weil sie glauben, je mehr Hipster-Frameworks sie benutzen, umso schärfer wäre ihre App. Außerdem haben sie damit noch ein paar extra Buzzwords zur Verfügung, um ihre Inkompetenz zu kaschieren.

Der richtige Weg, um dauerhaft schnell zu entwickeln und dabei technisch hochwertige Apps zu erstellen, sieht für mich so aus:

Guter Standard

Auf anderen Plattformen muß man für viele Dinge kreative Wege gehen, um eine Lösung zu finden. Apple stellt hingegen für praktisch alle Anwendungsfälle nützliche Frameworks zur Verfügung und beschreibt in der Entwickler-Dokumentation und den WWDC-Videos, wie man gängige Aufgaben idealerweise löst. Es gibt für jeden Fall offizielle Best Practices von Apple. Diese zu lernen und anzuwenden sehe ich als Pflicht-Aufgabe. Wenn Du für Apples Systeme entwickeln willst, dann komm mit Apples Tools und Frameworks klar. Ansonsten bist Du alles andere, aber kein Apple Entwickler.

Verwende die Tools und Frameworks, die von Apple kommen, denn diese sind Standard und allen Entwicklern bekannt. Sie sind gut dokumentiert. Neue Entwickler im Team kommen mit so einer Code-Basis schnell zurecht. Vermeide 3rd-Party Frameworks. Die kennt nur ein Bruchteil der Entwickler, was unnötige Einarbeitungszeit bedeutet, und sie sind meist auch noch schlecht dokumentiert, was diese Einarbeitung obendrein noch schwierig macht.

Apples Frameworks werden von mehr Entwicklern inklusive von Apple selbst in Betriebssystemen und Apps eingesetzt. Sie sind daher wesentlich besser in der Praxis erprobt und gereift, dokumentiert und getestet.

Extra Bugs

3rd Party Frameworks bringen zusätzliche eigene Bugs und Entwicklungsprobleme mit sich. Google hat sich zum Beispiel erst nach 1,5 Jahren dazu durchgerungen, eine heftigen Crash in einem seiner iOS-Frameworks zu fixen. Heftig bedeutet, daß dieser eine Bug die bei weitem häufigste Ursache für Abstürze in vielen Apps war. Man hat schon genug mit den eigenen und mit unvermeidlichen Bugs zu tun.

Extra verwundbar

Jede Zeile Code in der App, die durch direkte oder indirekte Inputs irgendwie erreicht werden kann, erhöht die Angriffsoberfläche. Eine zusätzliche Netzwerk-Library mit tausenden Code-Zeilen macht die App erst recht verwundbar. Das Buch "iOS Application Security" hat einen eigenen Abschnitt, der sich den Sicherheitsrisiken von 3rd Party Networking Libraries widmet.

Von außen angreifbar sind nicht nur Netzwerk-Libs, sondern auch solche zu Bildverarbeitung, Textmanipulation und einfach alles, was mit Daten von außen in Berührung kommt bzw. diese weiterverarbeitet. Das Risiko ist durch die eh schon benutzten System-Frameworks hoch genug, man muß nicht noch was oben draufpacken.

Der Busfaktor

Grundsätzlich ist der Busfaktor bei Fremd-Lib deutlich geringer als bei Apple: Die Anzahl der Entwickler, die überfahren werden müssen (oder aus anderen Gründen die Arbeit einstellen am Projekt), damit das Projekt nicht mehr weiterlebt, ist in der Regel sehr gering. Meist sind es nur 1-3 Hauptentwickler, die das Projekt als privates Hobby betreiben. Apples Frameworks werden weiter gepflegt werden selbst wenn ein ganzes Team durch ein Erdbeben in Cupertino verloren würde. Im Gegensatz zu 3rd Party haben Apples Frameworks eine Zukunft und werden über viele Jahre gepflegt.

Außer Atem

Für gewöhnlich können Dritt-Frameworks nicht mit Apples schnellem technischem Fortschritt mithalten und geraten recht schnell ins Hintertreffen. So wurden beispielsweise externe JSON-Frameworks von Apples eigener Standard-Lösung in der Performance überholt. Bei den Netzwerk-Frameworks hatte zum Beispiel ASIHTTPRequest schon 2011 selbst eingesehen, daß es unpflegbar und von schlechter Architektur war.

Setzt man auf Apples Standard-Frameworks, dann bekommt man mit jedem System-Update Performance-Gewinne und Bugfixes geschenkt, ohne eine einzige Zeile im Projekt-Code ändern zu müssen.

Alternative Entwicklungs-Umgebungen wie AppCode sind zur Unzulänglichkeit verdammt. Mit jeder technischen Entwicklung, die von Apple kommt, kommen diese Tools nicht klar. Sie können die Neuerungen ja nicht vorausahnen, sondern müssen sie mühsam mit Verspätung nachrüsten. Von Storyboards über Size Classes bis hin zu Swift oder der Apple Watch steht man jedes Mal für sehr lange Zeit ohne oder mit schlechter Unterstützung da.

Diametral

Diverse Dritt-Lösungen sind einfach eingebrödlerischer Mist, der überhaupt nicht zu Apples Architektur paßt, so wie eckige Reifen nicht mit einen Rennwagen harmonieren. Zum Beispiel die Abseitsfalle ReactiveCocoa.

Verantwortung

Wer allein an seinem privaten Projekt herumschraubt, der kann meinetwegen einsetzen, was auch immer ihn an 3rd-Party-Frameworks anmacht. Aber im Team oder als Auftragsarbeit ist es einfach unverantwortlich, ein Projekt mit unnötigen Dritt-Libs durch die oben genannten Punkten zu gefährden.

---