Unser Team verf\u00fcgt \u00fcber neue iPhones. Unsere Nutzer hingegen nicht. Viele der Menschen, die an einem beliebigen Tag eine unserer Apps \u00f6ffnen, nutzen ein Ger\u00e4t, das drei, vier oder manchmal sogar f\u00fcnf Jahre alt ist. W\u00fcrden wir nur mit den Ger\u00e4ten testen, die wir selbst in der Tasche haben, w\u00fcrden wir unsere Produkte f\u00fcr die falsche Zielgruppe ver\u00f6ffentlichen.<\/p>\n
In einem kleinen Studio vergisst man das leicht. Wenn man den ganzen Tag auf schneller Hardware entwickelt, wird \u201eschnell\u201c zur Normalit\u00e4t, und alles, was auf einem \u00e4lteren Smartphone gerade noch in Ordnung ist, wird gar nicht mehr als Problem wahrgenommen. Die einzige zuverl\u00e4ssige L\u00f6sung, die wir gefunden haben, besteht darin, das \u00e4ltere Smartphone jedes Mal physisch vor uns zu legen.<\/p>\n
Wir unterhalten einen kleinen Bestand an physischen Ger\u00e4ten \u2013 jeweils ein iPhone aus jedem der letzten f\u00fcnf Jahre sowie das derzeit g\u00fcnstigste iPad-Modell. Jede Version durchl\u00e4uft diesen Ger\u00e4tebestand, bevor sie die Qualit\u00e4tssicherung verl\u00e4sst, und nicht nur die neueste Hardware, die auf den Schreibtischen der Entwickler steht. Das f\u00fcnf Jahre alte Smartphone deckt Probleme auf, die kein Simulator erkennen kann.<\/p>\n
Die Prozedur ist alles andere als glamour\u00f6s. Den Build installieren, einen Kaltstart durchf\u00fchren, durch die l\u00e4ngste Liste in der App scrollen, den ressourcenintensivsten Bildschirm \u00f6ffnen, das Ger\u00e4t drehen, die App in den Hintergrund verschieben und wieder zur\u00fcckkehren. Auf dem iPad testen wir au\u00dferdem den Split-View-Modus, denn ein billiges iPad, auf dem zwei Apps nebeneinander laufen, ist ein ganz anderes Ger\u00e4t als ein neues, auf dem nur eine App l\u00e4uft. Das alles dauert nicht lange, und es ist der Teil der Release-Woche, den wir am wenigsten auslassen m\u00f6chten.<\/p>\n
Dieser Ansatz gilt auch \u00fcber das iPhone hinaus. Unsere Android-Apps werden auf bescheidener Hardware getestet, nicht nur auf Flaggschiff-Smartphones, und unsere iPhone- und iPad-Apps laufen auch auf Mac-Ger\u00e4ten mit Apple-Silicon, wo ein Layout, das auf einem Smartphone gut aussah, pl\u00f6tzlich in einem in der Gr\u00f6\u00dfe anpassbaren Fenster angezeigt werden kann.<\/p>\n
Animationen, die auf dem neuesten Chip fl\u00fcssig wirken, erscheinen zwei Generationen sp\u00e4ter ruckelig. Einstellungen zur Bilddekodierung, die auf einem Pro Max nicht wahrnehmbar sind, k\u00f6nnen den Hauptthread auf einem Basis-SE zum Stillstand bringen. Speicherressourcen, die auf Ger\u00e4ten mit 8 GB gro\u00dfz\u00fcgig bemessen sind, sind auf Ger\u00e4ten mit 4 GB knapp bemessen. Nichts davon tritt als Fehler zutage \u2013 es zeigt sich vielmehr in einem subtilen Eindruck, dass sich die App auf g\u00fcnstigeren Smartphones schlechter anf\u00fchlt, und genau diesen Eindruck wollen wir nicht hinterlassen.<\/p>\n
Was wir anfangs falsch gemacht haben, war, das alte Smartphone als abschlie\u00dfende \u00dcberpr\u00fcfung zu betrachten, anstatt es als Input f\u00fcr das Design zu nutzen. Wir haben einen Bildschirm entwickelt, ihn auf neuer Hardware optimiert und erst dann festgestellt, dass er auf dem \u00e4lteren Ger\u00e4t ruckelte \u2013 woraufhin die Korrektur bedeutete, dass wir etwas \u00fcberarbeiten mussten, das wir bereits als fertiggestellt betrachtet hatten. Jetzt wird das \u00e4ltere Smartphone bereits ab dem ersten Prototyp mit einbezogen. Wenn eine Animation oder eine Liste dort nicht einwandfrei l\u00e4uft, \u00e4ndern wir das Design und nicht nur den Code.<\/p>\n
Es gibt Kompromisse. Manche Effekte lohnen sich einfach nicht, wenn sie nur auf der neuesten Hardware gut aussehen, daher verzichten wir darauf. Das f\u00fchrt gelegentlich dazu, dass eine App auf einem Screenshot etwas schlichter wirkt als die eines Mitbewerbers. Damit k\u00f6nnen wir gut leben.<\/p>\n
Zwei Hauptversionen iOS zur\u00fcck \u2013 und zwar f\u00fcr jede Zydeno-App. Apples Tempo bei der Ausmusterung von Funktionen ist so hoch, dass eine noch gr\u00f6\u00dfere R\u00fcckw\u00e4rtskompatibilit\u00e4t die Pflege des Codes erschweren w\u00fcrde; zwei Versionen zur\u00fcck zu gehen bedeutet jedoch den Unterschied zwischen einer guten Versorgung der meisten unserer Nutzer und einer Versorgung, die sich nur auf diejenigen beschr\u00e4nkt, die die neueste Software nutzen.<\/p>\n
An dieser Linie festzuhalten bedeutet, dass wir gelegentlich warten m\u00fcssen, bevor wir eine neue Systemfunktion \u00fcbernehmen, oder dass wir sie so entwickeln, dass die App auch ohne sie weiterhin funktioniert. Das ist ein echter Aufwand an Entwicklungszeit. Wir nehmen diesen Aufwand lieber in Kauf, als jemandem zu sagen, dass sein Smartphone, das einwandfrei funktioniert, f\u00fcr uns nicht mehr gut genug ist.<\/p>\n
Das billige Handy ist der ehrliche Kritiker. Wir haben es nicht ohne Grund auf dem Schreibtisch stehen.<\/p>","protected":false},"excerpt":{"rendered":"
Wie wir auf Ger\u00e4ten testen, die wir pers\u00f6nlich niemals kaufen w\u00fcrden \u2013 und warum jede App, die wir ver\u00f6ffentlichen, dennoch auf diesen Ger\u00e4ten einwandfrei laufen muss.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-575","post","type-post","status-publish","format-standard","hentry","category-journal"],"yoast_head":"\n