Manchmal ist es nicht ganz einfach mit Apples Entscheidungen glücklich und zufrieden zu sein. Als Mac-Nutzer sehen wir ja oft nur die „Kundenseite“, aber heute möchte ich einmal die Entwicklerseite beleuchten.
Ich selbst bin Product Manager für eine Firma in den Niederlanden, unser Produkt ist eine Browser-Erweiterung (Add-On / Extension) für Google Chrome, Firefox, Opera, Edge und auch Safari. Selbst für Internet Explorer haben wir was, nur darauf ist keiner so recht stolze ;)
Da ich mit meinen Vorgesetzten nicht über diesen Blogpost gesprochen habe, möchte ich gleich klarstellen: dies ist meine rein private Meinung und ich halte mich entsprechend mit Details zurück.
Bis zum Anfang des Jahres konnte man Safari Extensions über einen Framework erstellen, der dem Framework for Chrome & Firefox sehr ähnelte. Für uns war die Entwicklungsarbeit also entsprechend einfach, klar es gab Safari-spezifische Funktionen, aber grundsätzlich klappte alles gut.
Ein nicht mehr unterstützter Framework
Als ich im Herbst letzten Jahres mit der Arbeit anfing, musste ich meinem Vorgesetzten recht schnell informieren, dass der aktuelle Framework von Apple nicht mehr unterstützt wird und spätestens mit Safari 13 und macOS 10.15 nicht mehr zur Verfügung steht.
Wir machten uns also auf die Suche nach einer Firma, die die nötige Erfahrung für die Entwicklung mitbrachte. Diese Suche war weder leicht, noch gänzlich erfolgreich, denn niemand wollte sich so recht an unser Projekt wagen.
Im Ende haben wir uns für eine Firma in den Niederlanden entschlossen, weil einer der Geschäftsführer ein persönliches Interesse zeigte, die Firma in der gleichen Stadt ansässig ist und die Kommunikation mit unseren Entwicklern, die übrigens alle ausgezeichnet Englisch sprechen, noch ein kleines bisschen einfacher wurde.
Diese Suche brauchte einige Zeit und da die Entwickler mit dem Framework nicht so recht vertraut waren und wir auch eine besondere Lösung suchten, dauerte es einige Zeit, bis wir loslegen konnten. Natürlich musste wir auch erst einmal das nötige Budget finden.
„Neue“ Extensions werden nicht mehr angenommen
In der ursprünglichen Information zu dem nicht mehr unterstützten Framework und der dazugehörigen Safari Extension Gallery hieß es, dass „neue“ Extensions ab Januar nicht mehr angenommen würden.
Unsere Erfahrung war jedoch deutlich schlechter, das Update im November und Dezember wurden bereits nicht mehr übernommen und wir konnten so wichtige Produktverbesserungen für Mac-Nutzer nicht ausliefern.
Im Januar entschloss ich mich unseren Fall mit Apple aufzunehmen und bekam dann eine verfeinerte Antwort „Neue Extensions und Updates existierender Extensions“ werden nicht mehr bearbeitet.
Aus meiner Sicht ganz klar, das hätte Apple deutlicher kommunizieren sollen. So wurde unser Zeitrahmen künstlich kürzer, und nur, weil die Informationen für Entwickler mehrdeutig waren. Sicherlich war das für Apple alles eindeutig, nur unsere Fehlinterpretation zeigt, dass es das dann halt doch nicht war.
So fühlte ich mich gezwungen bei Apple Einspruch einzulegen, meine Argumentation war einfach. „OK, die Deadline war Januar, warum ist weder November noch Dezember bearbeitet worden, bitte erneut prüfen und zu mindestens Dezember freigeben“. Nach Apple-Art kam irgendwann eine Meldung, dass unser Dezember Update jetzt in der Extension Gallery verfügbar sei. Leider gab es keine weitere Kommunikation, keine Erklärung, keine Hinweise, Funkstille à la Cupertino.
Wenn der neue Framework nicht kann, was der alte konnte…
Unser Entwickler legte sich ins Zeug, wir stellten unseren Software Architect für Konsultationen ab und zusammen entwickelten die Beiden einen Proof of Concept, der suggerierte, dass wir erfolgreich wären. Nach viel zu langer Zeit, kam dann endlich das erste Alpha.
Diese Alpha-Version unterzog ich unserem erprobten Business Acceptance Testing und sie rasselte komplett durch. Nichts klappte wirklich so, wie es sollte. Aber der Code im Hintergrund lief korrekt, nur unser Entwickler machte Sommerurlaub.
Nach vielen weiteren Stunden der Entwicklung stellten wir dann fest, dass der aktuelle Framework einfach nicht alles unterstützt, was der alte Framework unterstützte. Ein katastrophale Situation, schließlich hatte ich zu diesem Zeitpunkt schon viel zu viel meines Budgets ausgegeben. Entwickler lassen sich bei solchen Projekten nach Stunden bezahlen, das Risiko liegt also beim Auftraggeber.
Als die ersten Betaversionen von macOS 10.15 rauskamen, lief plötzlich das, was vorher nicht lief und wir sahen das ersehnte Licht am Ende des Tunnels.
Im Moment haben wir eine Beta-Version, die auf macOS 10.15 gut, auf macOS 10.14 mäßig läuft. Unser Leben ist ein wenig komplizierter, da wir einen Weg wählten, der eben nicht rein nativ ist, sondern an unsere restliche Entwicklung andockt. Jetzt haben wir noch einen Show-Stopper-Bug und das Team arbeitet gerade daran. Das schöne, dieser Bug wird von unserem Core-Entwickler-Team bearbeitet, und damit beweisen wir schon jetzt, dass der gewählte Weg, der richtige ist.
Wenn Apple einem das Bein stellt
Die alten Safari Extensions werden ab Safari 13 und macOS 10.15 nicht mehr unterstützt, aber am 03. September geschah etwas, was mir die Sprache verschlug. Apple deaktivierte die Safari Extension Gallery, die einzige Möglichkeit solche Extension überhaupt zu installieren.
Man wird auf eine Seite mit Extension im App Store verwiesen, die aber auch nicht vollständig ist. Uns traf das ganze unvorbereitet, weil uns keine der Nachrichten von Apple erreichte. Durch einen befreundeten Entwickler lernte ich dann, dass es eine kurze eMail gab, genau eine Woche zuvor. Viel Zeit war das nicht.
Man fragt sich auch warum jetzt? macOS 10.15 kommt erst irgendwann im Oktober. Der Framework in macOS 10.14 / Safari 12 kann einfach nicht, was wir brauchen. Wir stecken fest und sind in der schlechtesten Situation, in der man sein kann.
Muss ich das verstehen?
Aus Apple Sicht scheint der Fall ganz einfach. Warum etwas anbieten, was es eh bald nicht mehr gibt. Aus Entwickler-Sicht frag ich mich, warum Apple so kurzsichtig agiert, besonders wenn der „neue“ Framework erst mit der nächsten macOS Version richtig gut läuft. Das schlimme, im Ende leiden unsere Nutzer und das tut mir jeden Tag aufs neue weh.
Die Lektion?
Wer für Apple entwickelt, lebt mit vielen Unsicherheiten.
Apple ist so groß, dass die Bedürfnisse von kleinen Entwicklern, einfach nicht ins Gewicht fallen. Ein Anwendungsfall der für Apple nicht wichtig ist, führt dazu, dass ein Framework durch einen anderen ersetzt wird, aber nicht alle Funktionen erfüllt, die der alte Framework bot (und andere vergleichbare Frameworks anbieten).
Browser Extensions sind eine wundervolle Art die Arbeit im Browser zu erweitern und zu verbessern. Dinge, die nur eine relativ kleine Nutzergruppe brauchen, können hinzugefügt werden, ohne, dass die Mehrzahl der Nutzer damit „belastet“ werden müssen. Apple schützt dabei die Privatsphäre der Nutzer in vorbildlicher weise, leider werden den Nutzern dabei auch nützliche Funktionen vorenthalten.
Ein Gedankenspiel – Wie wäre es mit einer rein nativen Lösung gelaufen?
Die Frage aus der Überschrift für diesen Abschnitt werden wir nie beantworten können, jede Spekulation ist daher müßig. Natürlich hätten wir eine rein native Lösung suchen können, aber das hätte für uns das Problem erzeugt, dass wir stets eine macOS Entwickler für jedes Feature-Update bräuchten. Für unsere Kostenstruktur katastrophal, der von uns gewählte Ansatz löst dieses Problem hoffentlich sehr elegant.
Ich selbst entwickle private Open Access Helper für iOS und macOS und die Entwicklung in meiner Freizeit macht Spaß und läuft in nativen Swift Code, für die eigentliche Extension kommt noch ein wenig JavaScript zum Einsatz. Mein Anwendungsfall ist bei weitem nicht so komplex, wie der Anwendungsfall auf der Arbeit.
Aber auch hier, erlebe ich immer wieder interessante Situationen in denen eine Version abgelehnt wird. Das Problem ist eigentlich nicht das der Grund nicht nachvollziehbar ist, sondern, dass es sehr darauf ankommt, wie der Prüfer gerade drauf ist.
Vor kurzem wurde die iOS Version abgelehnt, weil wissenschaftliche Artikel auch mal wenig schöne Bilder enthalten. Die bemängelte Funktion existiert seit er ersten Veröffentlichung. Hier ist also nichts neu, und trotzdem kam die Ablehnung erst nach 8 oder 9 Versionen. Hier möchte ich dem Prüfer jedoch große Klasse attestieren, denn in seiner Ablehnung ging er auf den besonderen Fall ein, erklärte den korrekten Lösungsansatz und die Version wurde nach Korrektur schnell in den Store aufgenommen. Trotzdem, wenn die Prüfung der Apps so subjektiv ist, bedeutet dies auch, dass man mit jedem neuen Update einen neuen Grund für eine Ablehnung befürchtet.
Bei einem Update der macOS Version wurde ich für eine Beschreibung abgelehnt, die so seit der allerersten Version vorhanden war. Auch hier gab es mindestens 8 Versionen, die nicht beanstandet worden waren. Eine empfohlene Länge gibt es für diesen String – meines Wissens nach – auch nicht, ich kürzte also nach „Gutdünken“ und versuchte mein Glück erneut.
Die eigentliche Frage: Sollte der AppStore Prozess etwas mit „Glück“ zu tun haben?
Die allermeisten Entwickler wollen gar nicht die Regeln bis an die Grenzen ausreizen, sondern leben einfach mit der Tatsache, dass die Regeln nicht ausreichend klar sind oder die Regeln nicht einfach genug zu finden sind.
Bei der Softwareentwicklung gibt es auch nicht den richtigen Ansatz, sondern meist eine ganze Reihe möglicher Lösungen, alle mit einer eigenen Liste von Vor- und Nachteilen, die es dann abzuwägen gilt, nur klare Regeln können einen Ansatz ausschliessen.
Man muss aber auch Apple zugestehen, dass man bei einigen Regeln erst entscheiden kann, ob eine App diese erfüllt (oder eben nicht), wenn man die App sieht. Das liegt in der Natur der Softwareentwicklung, nur braucht man dann als Entwickler auch eine Möglichkeit einen Ansatz vorher prüfen zu lassen.
Muss man wirklich erst viele Monate Entwicklungsarbeit leisten, um festzustellen, ob die eigene Auslegung einer Regel, der von Apple entspricht?
Für Neugierige – Wie geht es auf der Arbeit weiter?
Sobald der bekannte Bug – leider ein Showstopper – behoben ist, werden wir die App erneut testen und dann an Apple zur Prüfung übermitteln. Aber erst dann wird sich zeigen, ob unsere Investition von Erfolg gekrönt ist. Das Geld ist ausgegeben, aber ob wir letztendlich ein Produkt haben, liegt dann ganz in den Händen von Apple.
Mit unseren macOS Entwickler habe ich über das Problem gesprochen und von Anfang an war er recht deutlich, wir halten uns an alle bekannten Vorgaben, aber was Apple dann daraus macht, kann er nicht vorhersagen.
0 Kommentare