„Wir bauen eine App." Diesen Satz hört man heute überall. Auf Familienfeiern, in der Bäckerei, in jeder zweiten Zeitung. Apps klingen leicht. Man hat eine Idee, man tippt sie irgendwie ein, fertig liegt sie im App Store.
Das stimmt — aber erst auf dem allerletzten Meter. Dazwischen liegen Wochen Arbeit, die mit Programmieren überraschend wenig zu tun haben. Ich beschreibe das hier, weil ich gerade selbst mittendrin stecke — mit Bonblick. Und weil mir oft auffällt, wie sehr der Aufwand unterschätzt wird, sobald jemand sagt „ich brauche da nur eine App".
Wenn du als Bonblick-Tester gerade liest und dich fragst, warum manche Verbesserung Tage braucht statt Sekunden — hier ist die Antwort.
1. Der sichtbare Teil: das Programmieren
Programmieren ist tatsächlich der Teil, den man sich vorstellt: Code schreiben, Knöpfe gestalten, Bilder einbinden, Logik bauen. Das ist eine echte Arbeit, aber sie ist nur ein Stück vom Ganzen.
Bei Bonblick zum Beispiel war der „eigentliche App-Code" für die Hauptfunktion „Bon scannen, lesen, anzeigen" relativ schnell stehen. Damit beginnt der Rest.
2. Verschiedene Geräte
Ein iPhone ist nicht das iPhone. Es gibt iPhone 12, 13, 14, 15, 16 — alle in mehreren Größen. Jeder Bildschirm hat eine andere Auflösung, eine andere Form, manche haben oben einen schwarzen Balken, andere nicht. Wer eine App baut, muss prüfen, dass sie auf jedem dieser Geräte gut aussieht.
Bei Android wird es noch wilder. Samsung, Google Pixel, Xiaomi, Huawei, Oppo, Motorola — jeder Hersteller setzt das gleiche Android-System anders um. Knöpfe sitzen woanders, Schriften sind unterschiedlich, manche Geräte haben einen Stift, andere falten sich auf.
Eine Liste, die mir bei Bonblick im Kopf herumgeht:
| Sache | Wie viele Versionen es davon gibt |
|---|---|
| iPhone-Modelle in aktiver Nutzung | etwa zehn |
| iOS-Versionen, die Tester noch nutzen | drei bis vier |
| Android-Hersteller mit eigener Oberfläche | mindestens fünf große |
| Android-Versionen am Markt | sechs bis sieben |
| Bildschirm-Größen | zu viele zum zählen |
Wenn ich also „Bonblick" sage, meine ich nicht eine App. Ich meine eine App, die auf hundert verschiedenen Geräten gut funktionieren muss.
3. Wie aus Code eine echte App wird
Wenn der Code geschrieben ist, ist er noch keine App. Er muss zuerst in das Format gebracht werden, das iPhones und Android-Geräte verstehen können.
- Für iPhone: Apple verlangt einen Mac als Baurechner, ein digitales Zertifikat (man kann es sich wie einen Ausweis vorstellen, den nur Apple ausstellt), ein passendes Provisioning Profile (eine Genehmigung pro App), und mehrere automatische Schritte, die aus dem Code eine
.ipa-Datei machen — das ist sozusagen die fertige App-Verpackung. - Für Android: Google verlangt einen Schlüssel zum digitalen Unterschreiben (man darf den nie verlieren — sonst kann man die App nie mehr aktualisieren), und macht aus dem Code eine
.apk- oder.aab-Datei.
Diese Bau-Schritte heißen Build-Pipeline. Sie laufen automatisch, aber wenn etwas hakt — und das tut es oft — dann steht der Builder mehrere Stunden vor unverständlichen Fehlermeldungen.
4. Tester anwerben
Bevor eine App in den großen Store kommt, sollte man sie auf echten Geräten testen lassen. Nicht nur die eigenen — alleine sieht man die Hälfte der Probleme nicht. Man braucht andere Menschen mit anderen Geräten.
Tester zu finden ist überraschend schwer. Familie und Freunde helfen am Anfang, aber:
- Sie haben oft das gleiche iPhone-Modell wie man selbst.
- Sie testen einmal kurz, dann vergessen sie es.
- Sie wollen niemandem auf die Füße treten und melden Probleme nicht.
Echte Tester sind Menschen, die regelmäßig die App benutzen, die ehrlich Rückmeldung geben und die ihre Erfahrungen schriftlich oder per Sprachnachricht teilen können. Solche Menschen findet man nicht über Nacht.
Bei Bonblick versuchen wir, das mit TesterPayKit zu lösen — ein Werkzeug, das den Tester-Feedback-Kanal direkt in die App einbaut. Dazu gibt es einen eigenen Journal-Artikel.
5. Die verschiedenen Test-Stufen — ein Begriffs-Wirrwarr
Hier wird es richtig durcheinander. Es gibt nämlich viele verschiedene Wege, eine App zum Tester zu bringen, und sie heißen alle anders. Hier eine Übersetzung:
| Begriff | Was es bedeutet | Wer kontrolliert es |
|---|---|---|
| Alpha-Test | Sehr früh, oft nur das eigene Team und engste Freunde. Vieles ist noch kaputt. | Der Entwickler. |
| Beta-Test | App ist im Kern fertig, aber noch zu früh für die Öffentlichkeit. Externe Tester probieren sie aus. | Der Entwickler. |
| Internal Testing (Google Play / Apple) | Apple bzw. Google erlaubt einen kleinen Kreis Tester (bis 100), die sofort Updates bekommen — ohne Wartezeit. | Apple bzw. Google, aber schnell. |
| External Testing (Apple TestFlight) | Größere Tester-Gruppen, aber Apple prüft jede neue Version vorher. | Apple. Dauert 12–48 Stunden pro neue Version. |
| Closed Testing / Open Testing (Google Play) | Geschlossene oder offene Tester-Gruppen über Google Play. | Google. |
| Firebase App Distribution | Google-Dienst, der Apps an Tester verteilt — funktioniert für iPhone UND Android, ganz ohne Apple- oder Google-Prüfung. | Der Entwickler. Keine Wartezeit. |
| App Store / Play Store (Production) | Die App ist öffentlich. Jeder kann sie laden. | Apple bzw. Google. Prüfung dauert Tage. |
Das heißt: eine App ist nicht „beim Tester" oder „im Store". Sie kann gleichzeitig in mehreren Tester-Wegen sein und sich für jeden Tester anders anfühlen. Eine wahre Freude für den Entwickler, der überall den Überblick behalten muss.
6. Apples Prüfung — der Engpass
Apple lässt nichts in den App Store, ohne es vorher angeschaut zu haben. Das gilt auch für Beta-Versionen, wenn man sie an größere Tester-Gruppen verteilen will.
So eine Prüfung — Apple nennt sie Review — dauert heute typisch zwischen 12 und 48 Stunden. Manchmal schneller, manchmal langsamer. Wenn Apple etwas an der App nicht passt — zum Beispiel ein Schreibfehler in einer Beschreibung, eine fehlende Datenschutz-Angabe, ein Hinweis zur Verwendung deiner Kamera, der zu allgemein formuliert ist — wird die Version abgelehnt. Dann darf man nachbessern, neu hochladen und noch einmal warten.
Bei Google ist es schneller, aber auch dort gibt es Regeln. Verstöße können zur Sperrung der ganzen App führen.
7. Was außer dem Code noch da sein muss
Bevor eine App überhaupt eingereicht werden darf, braucht sie:
- eine Datenschutz-Erklärung im Internet (rechtlich Pflicht in Europa)
- ein Impressum (Pflicht in Deutschland)
- eine Beschreibung für den Store, in mehreren Sprachen
- Screenshots in den richtigen Auflösungen für jedes Gerät
- ein App-Icon in vielen Größen
- Schlagwörter und Kategorien
- eine Altersfreigabe-Erklärung (was zeigt die App, ist da Werbung drin, Glücksspiel, was auch immer)
- Datenfluss-Angaben: was sammelt die App, was wird wohin geschickt
- Support-Kontakt
Jeder dieser Punkte kann eine eigene Geschichte werden. Die Datenschutz-Erklärung allein kostete bei Bonblick einen Nachmittag — und wir sind eine vergleichsweise einfache App, weil wir nichts tracken.
8. Updates — der dauerhafte Teil
Wer denkt, mit der ersten Veröffentlichung sei die Arbeit getan, irrt sich. Eine App, die einmal im Store ist, will alle paar Wochen ein Update sehen — sonst riecht sie nach „verlassen". Tester finden weiterhin Probleme. Apple und Google ändern ihre Regeln. Neue Geräte erscheinen, die alte Geräte-Tests obsolet machen.
Bei Bonblick haben wir gerade die Vereinbarung, die Versionsnummer nur dann zu erhöhen, wenn wirklich eine größere Welle abgeschlossen ist — und sonst nur die kleine Build-Nummer hochzuziehen. Warum? Weil Apple bei jeder neuen großen Versionsnummer wieder eine Prüfung verlangt. Wer fünfmal pro Tag eine neue Version hochlädt, wartet fünfmal auf Apple. Wer fünfmal die Build-Nummer hochzieht, wartet nicht.
So eine Detailentscheidung wirkt klein. Sie macht aber bei einer App im Tester-Modus den Unterschied zwischen „eine Woche Updates aus dem Vormittag" und „eine Woche Updates pro Woche".
9. Wie sich das anfühlt
Ich nenne mal die Tage, die ich diese Woche bei Bonblick mit folgenden Dingen verbracht habe:
| Tätigkeit | Anteil |
|---|---|
| Programmieren | etwa 40 % |
| Prüfen, ob auf verschiedenen iPhones alles aussieht | 10 % |
| Tester-Feedback lesen, beantworten, einsortieren | 15 % |
| Build-Pipeline anpassen (Firebase, TestFlight, Play) | 10 % |
| Texte schreiben (Anleitungs-Seite, App-Beschreibung) | 10 % |
| Dokumentation und Architektur-Entscheidungen schreiben | 10 % |
| Werbung schauen, wie der Markt unterwegs ist | 5 % |
Nur 40 Prozent sind das, was sich Außenstehende unter „App bauen" vorstellen. Der Rest ist Drumherum — und der Rest ist genauso wichtig.
10. Warum das wichtig ist
Wenn du das nächste Mal hörst „wir haben eine App gebaut", weißt du: dahinter steckt eine ganze Menge mehr als ein Programmierer mit einem Laptop. Es steckt Tester-Arbeit dahinter, Geräte-Tests, Apple-Prüfungen, Google-Hürden, Datenschutz-Texte, Übersetzungen, Screenshots, Support, Updates.
Das ist nichts Geheimnisvolles. Aber es erklärt, warum echte Apps Zeit brauchen — auch wenn die Idee dahinter in zehn Minuten erzählt werden kann.
Für Bonblick bedeutet es: wenn du als Tester eine Verbesserung wünschst und sie nicht in der nächsten Stunde da ist, liegt das fast nie am Programmieren. Es liegt daran, dass die App durch alle diese Schichten muss, bevor sie wieder bei dir auf dem Handy landet.
Fazit
Eine App ist nicht der Code. Eine App ist der Code, plus jede Menge Drumherum — Tester, Geräte, Prüfungen, Texte, Updates. Wer „mal eben eine App macht", merkt das spätestens, wenn er das erste Mal vor der Apple-Review-Schlange wartet.
Und das alles ist nur der Pre-Release. Was passiert, wenn die App wirklich öffentlich ist und tausend Menschen sie täglich benutzen — das ist eine ganz eigene Geschichte. Eine, die wir bei Bonblick auch noch erleben werden. Mehr dazu, wenn es soweit ist.
Bis dahin: jeder Tester, der einen roten Käfer drückt und uns Feedback gibt, macht diesen Prozess kleiner. Danke dafür.