Jetzt mal ehrlich. Ist deine App-Idee gut? Ja? Nein? Woher weißt du das? Oder wie findest du es raus?

Es gibt zwei Gründe eine App zu launchen. Zum Beispiel als Hobby. Dann ist es (sagen wir mal) egal, ob die Idee gut ist oder nicht. Es ist dein Hobby und du hast Spaß an der Sache mit der App. Fertig. Vorausgesetzt du kannst den Aufwand oder die Kosten vertreten deine Hobby App in’s Leben zu rufen.

Oder du betrachtest deine App als Business. Als Geschäft. In diesem Artikel werde ich davon ausgehen, dass du damit auch Geld verdienen willst und und wir das Hobby ausschließen können. In dem Fall sind es eigentlich drei Fragen, die hier entscheidend sind:

1. Ist die Idee als Geschäftsidee an sich gut? Trägt sich die Idee selber? Löst sie ein Problem? Macht sie das Leben bestimmter Leute besser, einfacher, effizienter, schmerzfreier oder einfach schöner?
2. Ist es eine gute Wahl deine Geschäftsidee als App zu realisieren, oder ist ein anderer Weg doch besser?
3. Wird die App so umgesetzt, dass am meisten Potenzial der Idee transportiert wird?

Wir reden jetzt über ein Geschäft. Das heißt es muss Geld rein kommen. Geld bekommt man von den Kunden. Kunden zahlen nur, wenn sie das Gefühl haben, dass ihnen das Geld Wert ist.

Ist die Geschäftsidee gut und ist eine App dafür sinnvoll?

Da sich dieser Blog primär um die Umsetzung dreht, gebe ich dir hier einfach nur Anhaltspunkte und Referenzen zu Ressourcen. Zum Thema Validierung von Geschäftsideen ist im Internet mehr als genug Information vorhanden.

• Fülle ein Business Model Canvas aus: https://www.startplatz.de/startup-wiki/business-model-canvas/
• Mache eine Konkurrenzanalyse. Wer löst denn sonst dieses Problem? Nicht unbedingt auf die gleiche Art wie du es lösen willst. Sondern wer ist generell an der Lösung von dem Problem beteiligt? Gibt es keine Konkurrenz: gibt es einen Grund dafür? Mangelnde Konkurrenz ist tendenziell ein schlechtes Zeichen!
• Mache Umfragen
• Gibt es alternative Wege um das Problem zu lösen ohne eine App zu haben? Vorteile? Nachteile?

Aufwand? Ja. Langweilig? Mag sein, wenn du es oberflächlich angehst. 😉

Hole das meiste Potenzial aus der Idee

Hast du die obigen Schritte gemacht und bist zum Entschluss gekommen, dass eine App wirklich für deine Rahmenbedingungen die beste Wahl ist? Gut. Jetzt wollen wir die bestmögliche Umsetzung erreichen. Nur wie?

Em Ende kommt es auf vier Faktoren an:

• Die App macht eine Sache und diese wirklich gut
• Die App macht diese Sache für deine spezifische Zielgruppe besonders gut
• Die App ist zuverlässig und hat keine Bugs
• Bonus: Details. Animationen, Mikrointeraktionen, Sounds

Auf die Zuverlässigkeit werde ich nicht eingehen. Eine App hat so zu funktionieren wie erwartet. Bugs sollten gefunden und behoben werden bevor die App an den Kunden geht oder zumindest so schnell wie möglich adressiert werden. Crashes sind ein komplettes no-go. Benutzer haben einen sehr kurzen Geduldsfaden mit Apps und auf die Gnade einer zweiten Chance solltest du dich nicht verlassen.

Mache eine Sache und diese richtig gut

Mehr ist nicht besser. Mehr ist einfach nur mehr. Du hast mehr Features in deiner App? Dann macht sie das nicht unbedingt besser, sondern erstmal voller, überladener und komplizierter zu bedienen. Potenziell mehr Funktionen in der App anzubieten heißt nicht, dass diese Features gut untergebracht sind und Benutzer sie verstehen. Oder vielleicht halten sie Benutzer sogar vom Kern der Sache ab.

Nehme doch mal dein Smartphone in die Hand und schaue die Apps an, die du selber öfter benutzt. Was machst du mit diesen Apps? Was ist das Grundprinzip und was ist letztendlich einfach nur „Zeug drum rum“? Wie schaffen diese Apps den Prozess klar zu halten und den Benutzer zu führen, ihnen zusätzliche Optionen zu geben, ohne vom Kern abzulenken?

Die Verlockung ist groß erstmal so viel wie möglich in die App reinzupacken, weil sich mehr nach besser anfühlt. Das kann aber auch sehr kontraproduktiv sein. Du steckst neue Features in die App bevor du überhaupt weißt wie deine Benutzer die App überhaupt benutzen. Ob sie mit dem Design so klar kommen oder nicht. Ob die Benutzer gut geführt werden, sodass immer klar ist was die nächste wichtige Sache ist. Gibt es mehr Funktionen, so gibt es mehr Ablenkungen auf diesem Weg. Sprich das Problem wird für die Benutzer potentiell schlechter gelöst.

Natürlich können all diese Sachen später noch eingebaut werden, aber viele Apps funktionieren nicht, weil sie den Fokus verloren haben, der nötig wäre um erstmal am Ball zu bleiben. Um die ersten Kunden so richtig zu überzeugen. Um Erfahrungswerte zu sammeln. Um zu sehen was die nächsten wirklich wichtigen Funktionen wären und wie diese wohl am Besten platziert werden.

Anstatt die App zu überladen könntest du zum Beispiel noch daran denken wie die App sich verhalten soll wenn was schief geht. Was passiert z.B., wenn zwischendrin die Internetverbindung abreißt? Es gibt nicht nur den sogenannten „happy path“, wo alles genau so funktioniert wie gedacht. Was kann sonst noch alles dazwischenkommen und wie kannst du dafür sorgen, dass auch in diesen Fällen der Benutzer ein rundes Erlebnis hat?

Mache eine Sache gut. So gut wie möglich. Dann gehe an den Markt. Und dann schaue, wie du mehr Funktion anbieten kannst, indem du Kunden beobachtest und mit ihnen redest.

Deine Zielgruppe und -situation

Das heißt auch, dass du deine Kunden kennen solltest. Also wer genau ist dein Kunde? In welchem Kontext wird denn deine App gebraucht? Daheim auf der Couch? In der Bahn beim Pendeln? Draußen, wenn man zu Fuß unterwegs ist? Auf dem Weg zur Arbeit? Bei der Arbeit? Ist das am Schreibtisch? Oder in einer Werkstatt? Oder sogar im OP-Saal vom Krankenhaus? Auf dem Weg zwischen Terminen? Oder wird die App auf dem Heimweg benutzt? Beim Joggen? In einem Laden? Im Wartezimmer beim Arzt?

Und ist die App wirklich so gebaut, dass sie den Benutzer in dem Kontext auch wirklich abholt und begleitet? Warum ist der Benutzer gerade in der Situation? Warum will er die Sache erledigen, die deine App kann? Wie kann deine App in dieser Situation am Besten helfen? Sind die z.B. Buttons groß genug um in dieser Situation gut getroffen werden zu können? Sind die „Arbeitsschritte“ in der App so wie der Benutzer es wirklich braucht?

Je besser du es verstehst umso besser kannst du auch die Details so zuschneiden, dass sich die Benutzer verstanden fühlen. Beziehungsweise weißt du dann auch wo du am Besten kleine Gimmicks einbauen kannst um den größten Wow-Effekt zu erzielen. Seien es Mikrointeraktionen, schöne Animationen oder Sounds, richtig eingesetzt sorgen sie dafür, dass sich deine Kunden verstanden fühlen.

Bonus. Ja, es ist ein Bonus, nicht essenziell

Also. Animationen sind cool. Schöne Übergänge zwischen den Ansichten sind cool. Mikrointeraktionen machen echt was her. Kleine Bestätigungssounds geben dem Benutzer Feedback und ein gutes Gefühl. Und du kannst in diese Sachen Geld versenken ohne Ende.

Es sind schwarze Löcher für Entwicklungsaufwand. Man kann immer noch was hübscher machen. Aber auch hier heißt hübscher nicht unbedingt besser. Es muss dir als auch den Benutzern klar sein, dass das ein Bonus ist. Erst wenn alles andere solide ist, dann lohnt es sich hier Aufwand reinzustecken. Vorher ist es nichts anderes als der Versuch die fehlende Basis zu kompensieren. Die Benutzer werden es merken und sich fragen warum du den Aufwand denn nicht lieber in die wichtigen Sachen steckst. Begeistern kannst du erst, wenn du nicht nur heiße Luft bietest.

Trotzdem solltest du Aufwand hier rein stecken. Deine App wird sich fluffiger anfühlen. Ich sage jetzt mal, dass die App dadurch lebendiger wird. Dein Job ist dafür zu sorgen, dass eine Balance da ist. Du solltest hier investieren und gleichzeitig die wirklich wichtigen Sachen im Auge behalten.

Zusammenfassung

Die Vorarbeit zu dieser Frage dreht sich also am meisten um generelle Business-Fragen: gibt es überhaupt einen Markt für deine Idee? Und macht es rein logisch überhaupt sinn eine App dafür zu machen, oder gibt es bessere Wege? Erst dann solltest du dir Gedanken machen wie du das dann am Besten als App umsetzt. Hier werden dir auch Entwickler und Designer mit ihren Erfahrungen helfen. Das wichtigste Asset für dich ist jedoch das Verständnis wie der Kunde tickt und wie du ihn glücklich machen kannst.

Höre den Artikel als Podcast-Folge

Diesen Artikel kannst du auch einfach hören als zu lesen. Hier im Web-Player oder auf allen Podcast-Plattformen:

Apple Podcasts: https://podcasts.apple.com/de/podcast/applify/id1489203144
Overcast: https://overcast.fm/itunes1489203144/applify-app-entwicklung-mit-jan-brinker
Spotify: https://open.spotify.com/show/6tVmQfMCZ7VgHU9iZD2VIU
Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xMDkwMTQ4Yy9wb2RjYXN0L3Jzcw%3D%3D

Im Artikel Was kostet eine App? bin ich bereits darauf eingegangen was denn die größten Kostenfaktoren in einem App-Projekt sind und warum die Frage was eine App generell kostet einfach nicht vorweg beantwortbar ist. Es gab einiges an Denkfutter für dich um überlegen zu können was du überhaupt wirklich brauchst. Somit hast du eine Baseline. An dieser Stelle steht fest was denn alles gebaut werden muss. Jetzt kannst du aber beeinflussen wie viel Aufwand verursacht wird um diese Funktionen zu bauen. Und Aufwände verursachen Kosten. In diesem Artikel gehe ich auf diesen variablen Anteil ein: Welchen Aufwand kannst du potentiell übernehmen um Kosten mit eigenem Einsatz zu sparen?

Die Herausforderung: nicht an der falschen Ecke sparen

Die offensichtliche Lösung wäre natürlich dafür zu sorgen, dass man sich einen günstigen Entwickler holt. Entsteht mehr Aufwand? Kein Problem, so teuer ist der Aufwand ja sowieso nicht.

Dieser Denkansatz hat allerdings mehrere Löcher und ich möchte zuerst darauf eingehen warum dieser Weg nur oberflächlich gut aussieht.

Ja, es gibt gute Entwickler, die auch günstig sind. Aber nicht viele. Ein guter Entwickler kennt in der Regel seinen Wert. Ja, das Kostet. Und gibt es aus gutem Grund das Sprichwort:

Wer denkt, dass es teuer ist mit einem Profi zu arbeiten, der hat noch nie mit einem Amateur gearbeitet.

In anderen Worten: kurzfristige Kosten können dir langfristige Kosten sparen. Kurzfristig gedachte Entscheidungen können dir bereits wenige Monate später Probleme bereiten, wenn Abkürzungen genommen wurden, die viele Folgen mit sich bringen. Ein Merkmal eines guten Entwicklers ist dich genau in solchen Fragen zu beraten und dich vor die Wahl mit den Vor- und Nachteilen zu stellen. Je besser der Entwickler umso besser kann er mit Weitsicht denken und flexible Lösungen bauen.

Steht ein IT-Projekt nicht auf solider technischen Basis, so wird jedes neue Feature schwieriger und schwieriger zum Einbauen. Ein neues Feature wird potentiell alte Features kaputt machen, diese müssen repariert werden und jeder Bugfix kann potentiell wieder neue Bugs erzeugen, vor allem bei schlecht entwickelter Software. (Ja, das ist wirklich so!) Ich selber durfte bereits in mehreren Projekten Feuerwehr spielen um diese zu retten. Ein Unterfangen, dass für die Kunden alles andere als günstig war!

Aber das ist auch nur der oberflächliche Grund. Viel schlimmer ist es was der Gedanke „extra Aufwand ist ja nicht teuer“ mit dir anstellt. Es fängt nämlich mit Kleinigkeiten an. Während der Entwicklung hast du eine Idee, dass man eine „Kleinigkeit“ doch noch anders und ganz viel besser machen kann. Dann änderst du den Plan was entwickelt werden soll. Es ist ja nur eine Kleinigkeit. Und der extra verursachte Aufwand eine bereits gebaute Sache umzubauen… ach. Du hast trotzdem ein gutes Gefühl. So viel teurer wurde es ja jetzt dadurch nicht. Und du hast ein Glücksgefühl, weil die neue coole Idee umgesetzt ist.

Feature creep

Also wirst du es wieder machen. Und wieder. Und jedes Mal werden deine Ideen ein klein wenig größer und oder spontaner. Diese „Kleinigkeiten“ werden sich langsam aufsummieren und plötzlich mehr Kosten verursachen als das gesamte Projekt ursprünglich gekostet hätte. Ja. Das passiert!

Oft!

Ich habe es bereits miterlebt. Das Phänomen tritt so häufig auf, dass es sogar einen Namen hat: feature creep oder scope creep. Also das Einschleichen von Features oder Funktionsumfang.

Abgesehen davon, dass an dieser Stelle regelmäßig Knatsch zwischen Entwickler und Kunde entsteht („Wird das jetzt überhaupt bezahlt?“, „Das ist aber teuer jetzt!“, „Das war ja nicht abgemacht, dass es so teuer wird!“, usw.), ist es ja auch nicht zielführend. Kleinigkeiten können viel ausmachen und Detailarbeit ist wichtig, ja. Aber ohne Priorisierung, ohne „was ist jetzt wirklich für den Endkunden am wichtigsten?“, läufst du in eine Sackgasse. Am Ende hast du eine Ansammlung an vielen Kleinigkeiten, die (vielleicht) super toll sind, aber der Anwendungsfall für den Kunden ist noch nicht fertig abgebildet. Wofür? Ist das sinnvoll? Hat jemand was davon?

Jetzt magst du meinen, dass du ja jetzt davon weißt und somit das einfach nicht machst. Wäre es so einfach das immer im Kopf zu behalten wären viele IT-Projekte nicht gescheitert. Wir sind alle Menschen und in der Situation fühlen sich neue kleine Ideen einfach viel zu verlockend an um sie hinten anzustellen. Es fällt uns Menschen einfach schwer.

Auch hier wieder: ein erfahrener Entwickler kann helfen dich zu bremsen. Er wird es zumindest probieren. Wir Entwickler sind nunmal ein Volk, das sich gerne an Pläne hält und haben uns alle schonmal an feature creep die Finger verbrannt und wollen das gerne für die Zukunft vermeiden.

Plane gut und bereite vor

Das Thema können wir jetzt noch weiterdenken. Wenn du regelmäßig neue Ideen für Details bekommst, dann ist das gut. Dann weißt du wie du in Zukunft die App ausbauen und verbessern kannst. Auch ist es gut, wenn dir neue große Features einfallen. Ein schlechtes Zeichen ist es allerdings, wenn dir immer wieder neue Arten und Weisen einfallen wie du das Kernproblem für deinen Endkunden lösen kannst und zwischen den Ansätzen hinterherjagst anstatt dich für eine Variante zu entscheiden.

Wenn du dich in so einer Situation wiederfindest, dann ist es ein Zeichen dafür, dass du schlecht geplant hast. Dann hast du dich schlecht vorbereitet. Du hast das Problem nicht gut genug verstanden, du hast deine Kunden nicht genug befragt und deine Lösungsansätze zu wenig analog auf Papier und „low tech“ ausprobiert. Du hast keine Prototypen gebaut und getestet.

Ich weiß, das hört sich nach langweiligem Standard-Ratschlag an. Und weil es langweilig ist und man es überall hört macht es kaum jemand richtig.

Also. Wie machst du es richtig? Du nimmst dir Zeit und redest mit deinen Kunden. Du holst sie an Bord. Du probierst deine Lösungsideen aus bevor du sie „in Technik gießt“. Probiere unterschiedliche Ansätze aus. Fixiere nicht auf deine Wunschidee, sondern schaue was am besten bei den Kunden ankommt. Hast du das ausführlich gemacht, dann verursachst du zumindest schonmal keine extra Kosten mehr.

Wie kannst du jetzt noch Kosten sparen? Du kannst dir überlegen und definieren was die genauen Hintergründe und Regeln sind anhand deren die Anwendungsfälle zu behandeln sind. Also z.B. kann es sein, dass es eine Leiste mit Buttons in deiner App gibt und bei jedem dieser Buttons soll eine Ansicht geöffnet werden, die exakt gleich aussieht und funktioniert, nur eben andere Inhalte anzeigt. Eine News-App ist ein gutes Beispiel hierfür. Egal ob man jetzt die Sektion Wirtschaft, Politik oder generell „das Neuste“ auswählt: die resultierende Ansicht ist immer gleich aufgebaut. Nur eben was genau angezeigt wird ist anders. Kannst du Orte in der App finden, die immer nach dem gleichen Schema funktionieren? Dann definiere es explizit. Und beschreibe wie dieses Schema genau funktioniert. Wenn es auch nur einen einzigen Ausnahmefall gibt, dann kannst du dir z.B. überlegen, ob du diesen Button doch lieber wo anders platzierst.

Der Grund? Naja, Programmieren ist das erstellen von Regeln. Also: Wenn x passiert, dann mache y. Und es ist eben einfacher und schneller zu programmieren, wenn man eine generelle Regel hat „wenn x passiert, dann mache y“ als „wenn x passiert und y zutrifft, dann mache z“. Natürlich kann man das bauen. Aber jede Regel, die einen Sonderfall enthält verursacht extra Aufwand und somit Kosten. Wenn es dir wichtig ist, dass diese Sonderregel genau an dieser Stelle so eingebaut ist: gut! Wenn nicht: wie kannst du es anders lösen? Definiere.

Zusätzlich: wenn du dem Entwickler direkt erklären kannst was die Hintergründe sind und wie die Prozesse funktionieren, dann kann der Entwickler direkt überlegen wie das umzusetzen ist. Du sparst den Aufwand der entsteht, wenn sich der Entwickler erstmal darum kümmern muss von dir aktiv zu erfragen wie denn die Prozesse funktionieren. Es geht nicht darum, dass du dem Entwickler sagen sollst was er technisch zu tun hat. Aber du bist der Experte in der Problemdomäne, also kennst du (und nicht der Entwickler) wie deine Kunden ticken, was sie wollen oder auch was die Kniffe oder sogar Legalitäten hinter deinem Geschäft sind. Das musst du dem Entwickler möglichst klar vermitteln, wenn du Aufwand sparen willst.

Ja, das erfordert Arbeit und ja das ist schwer. Dir muss nur klar sein, dass du den Aufwand sowieso haben wirst. Spätestens wenn der Entwickler eine Funktion umsetzen will. Die Frage ist, ob du den Entwickler vorweg mit Informationen versorgst oder nur auf Abruf Informationen lieferst und somit viel Wartezeit erzeugst. Beziehungsweise riskierst du auch, dass der Entwickler Teile deiner App ohne genug Weitsicht entwickelt. Das wiederum kann Kosten zu einem späteren Zeitpunkt erzeugen, wenn diese Teile umgebaut werden müssen.

Habe ich bereits in vorherigen Folgen gesagt, dass Kommunikation alles ist?

Nicht verkünsteln. Klein anfangen. In kleinen Schritten weiterdenken.

Eine Sache, die auch hilft die Kommunikation klar und fokussiert zu halten ist, wenn du dir mit deinem Entwickler klare Ziele steckst.

• Was soll bis wann fertig sein?
• Was ist erstmal wichtig für den Kunden?
• Was kann aufgeschoben werden?
• Was ist das kleinste sinnvolle Arbeitspaket?
• Wie kann man möglichst früh erste Testversionen haben?

Das Ziel hinter diesen Fragen ist letztendlich mit einem MVP zu starten. Mit der kleinsten sinnvoll nutzbaren App. Das fokussiert euch auf die wichtigen Themen. Alles andere kann später kommen. Aber dein Kunde hat dann was in der Hand. Bonus: du bekommst erstes Feedback von deinen Kunden und kannst früh nachsteuern, wenn die Kunden Änderungswünsche haben.

Zusätzlich, offensichtlich, hast du dann noch nicht so viel Aufwand erzeugt. Sondern nur so viel wie gerade nötig um eine erste Version zu haben. Stellst du hier fest, dass deine App-Idee einfach nicht zieht, dann kannst du froh sein, dass du nicht gleich viel zu weit gedacht hast. Dann hast du dir Aufwand und Kosten gespart.

Wenn dir das noch nicht genug ist, dann kannst du dir zusätzlich die Frage stellen:

Kannst du noch kleiner denken?

Zum Beispiel: ja, vielleicht willst du sowohl die App für Android und iOS haben, aber genügt für die erste Zeit auch erstmal nur eine Plattform? Ja, das sind Abstriche für die erste Zeit. Aber wenn du gewollt bist erst für eine Plattform zu entwickeln und danach für die andere, dann wirst du dir einigen Aufwand sparen können.

Egal wie sehr du dich vorbereitest, am Ende wird es einige Punkte geben, die während der Entwicklung auffallen und anders gemacht werden müssen. Das ist vollkommen normal. Baust du jedoch die iOS und Android Apps parallel, dann kommt man bei beiden Versionen gleichzeitig auf die gleichen Fragen und muss gleichzeitig warten, gleichzeitig Sachen umbauen usw. Entscheidet man sich erstmal für eine einzelne Plattform, so kann man damit für die zweite den Weg ebnen und dann nachziehen. Die zweite Version wird deutlich schneller und somit günstiger entwickelt.

Der geebnete Weg spart dir Kosten

Genau wie bei dem Beispiel zuerst nur eine Plattform zu bauen und die zweite nachzuziehen, kommt es in allen vorherigen Punkten auf den gleichen Kern raus: wie kannst du den Weg ebnen? Kannst du durch Weitsicht Hindernisse erkennen und diese frühzeitig vom Weg entfernen?

Somit kommen wir auch zum letzten Punkt dieses Artikels. Wenn du Hindernisse entfernen willst, dann begibst du dich selber auf und somit auch in den Weg.

Eine Lektion von Astronauten: Probiere eine 0 zu sein, keine +1

Vor einiger Zeit las ich das Buch „Anleitung zur Schwerelosigkeit“ vom kanadischen Astronauten Chris Hadfield und bin über diese Aussage gestolpert.

Wir Menschen wollen doch gerne in einem guten Licht da stehen. Dabei werden wir auch gerne vom Eifer erfasst und probieren eine „+1“ zu sein. Eine Person, die mit ihrem Handeln Gewinn bringt. Leider passiert es oft, dass wir damit die Leute blockieren, die eigentlich den Job haben, das zu tun, was wir erleichtern wollen. Das Resultat: wir sind keine Hilfe sondern eine Bürde, eine „-1“.

Was dann? Sei dir im Klaren, dass du nichts beweisen musst, weder dir selber noch dem Entwickler. Gerade in neuen Situationen für dich. Wenn du noch nie in einem Softwareprojekt beteiligt warst, dann ist das doch vollkommen ok. Mache dich erstmal mit der Situation vertraut und halte dich an deinen Experten (deinen Entwickler) und frage ihn was er genau braucht um weitermachen zu können. Wenn er das dann hat, dann kannst du ihn getrost machen lassen. Fordere ihn dazu auf sich bei dir zu melden, wenn er findet, dass du bei etwas helfen könntest um Aufwand zu sparen. Ansonsten: lass ihn machen.

Genau so wie du einen Handwerker in deinem Haus dazwischenfunkst brauchst du auch nicht deinem Entwickler ein Hindernis sein. Halte dir mal zum Beispiel vor Augen wie sich gute neue Angestellte bei deiner Arbeit verhalten. Sind sie voller Tatendrang und probieren erstmal krampfhaft überall mitzumischen und sind der Meinung zu allem eine bessere Lösung zu haben? Oder schauen sie zu, beobachten, fragen wo sie wie helfen können und packen dann mit an, wenn es überhaupt hilfreich ist? Die erste Verhaltensweise wird recht schnell auf den Keks gehen, weil diese Person im Übereifer erstmal übersieht, dass bestehende und noch unbekannte Prozesse einen Sinn haben. Es folgen unnötige Diskussionen, Erklärungen, sich gegenseitig im Weg stehen und Frustration.

Die Alternative ist niemandem etwas beweisen zu müssen und zu helfen, wenn es sinnvoll ist.

Zusammenfassung

Um alles nochmal auf einen Punkt zu bringen habe ich nochmal alle Aspekte für dich zusammengefasst:

• Unerfahrene Entwickler können dir mehr Kosten verursachen als du sparst.
• Kurzfristig gedachte Kosteneinsparungen können wir auf lange Sicht Kosten verursachen.
• Vermeide Feature und Scope Creeping
• Plane gut und bereite vor
• Probiere Regeln zu definieren wie deine Prozesse zu funktionieren haben. Merke: Regeln sind nur Regeln, wenn sie immer gelten!
• Starte klein, MVP zuerst. Dann Benutzer beobachten. Dann ausbauen.
• Baue die App zuerst für nur eine Plattform und ziehe die andere nach. Z.B. erst iOS und dann Android.
• Überlege dir wie du den Weg für die Entwicklung ebnen kannst. Halte Rücksprache dazu mit den involvierten Personen.
• Mantra von Chris Hadfield: Sei eine Null. Du musst zu Beginn nichts beweisen. Hilf, aber stehe nicht im Weg.

Artikel als Podcastfolge

Diesen Artikel gibt es auch vertont als Podcast-Folge auf allen großen Podcast-Plattformen und direkt hier im Web-Player:

Meiner Erfahrung nach bekommen Kunden erstmal ein mulmiges Gefühl, wenn theoretisch die Chance besteht, dass Apple deine App nicht in den AppStore lässt. Irgendwie verstehe ich diese Angst natürlich. Erst steckst du viel Arbeit und Geld in die Entwicklung und dann kann es sein, dass die App nie an den Kunden raus geht? Puh!

Daher dieser Artikel um dir die Angst zu nehmen. Hierfür ist das warum für den App Review der springende Punkt. Apple macht das nämlich nicht um dir Steine in den Weg zu legen. Zusätzlich gebe ich auch eine Übersicht auf was Apple denn so schaut. Für alle, die es genau wissen wollen werde ich auch am Ende vom Artikel das offizielle Dokument von Apple verlinken. Aber first things first.

Warum macht Apple das überhaupt?

Den Schlüssel zur Antwort findet man recht schnell in einer anderen Frage: Wofür ist Apple bekannt? Oder auch: was hebt Apple z.B. von Google ab.

Genau. Benutzerfreundlichkeit.

Jetzt wird es etwas schwierig. Einerseits: wie definiert man Benutzerfreundlichkeit? Und zweitens: wie stellt man Benutzerfreundlichkeit sicher, wenn man zwar die Plattform stellt (d.h. iPhone, iPad und AppStore), aber die Apps nicht selber entwickelt, sondern von einer breiten Masse an Anbietern entwickeln lässt?

Die Lösung: Man erstellt einen Katalog mit Anforderungen für die Entwickler und man führt eine Prüfung der Apps ein.

Es geht unter dem Strich also um Benutzerfreundlichkeit. Und das im weitesten Sinne, weil z.B. auch technische Details dazu führen können, dass Apps nicht gut funktionieren, dass Sicherheitslücken vorkommen die das gesamte Gerät lahmlegen können, oder dass Apps zum Beispiel nach einem iOS-Update nichtmehr richtig funktionieren könnten, weil man instabile Komponenten benutzt.

Es geht also nicht darum, dass dir Apple höchstpersönlich das Leben schwer machen will. Natürlich nicht! Sie sind doch mächtig froh, wenn jemand das Angebot im AppStore erhöht! Mehr Gründe für Endverbraucher auf ein iPhone umzusteigen oder um sich ein neues zu kaufen und nicht zu Android zu wechseln.

Apple ist interessiert an deiner App! Und gleichzeitig sind sie eben nicht bedürftig und abhängig von dir. Sie sitzen also am langen Hebel und wollen, dass nur Apps im AppStore landen bei denen sich Benutzer wohl und sicher fühlen können.

Wohl fühlen. Darum geht es. (Plus ein paar wirtschaftliche Interessen, dazu aber unten mehr.)

Eine Übersicht über Apples Kriterien

Also was sind denn so Sachen womit man dafür sorgen kann, dass sich Benutzer wohl fühlen? Oder auch: was sollte man vermeiden, weil sich dann Benutzer nicht wohl fühlen?

• Verbreitung von Inhalten, die schlichtweg angreifend, diffamierend oder absichtlich ekelerregend sind. Oder auch (schlecht übersetzbar) „content that is exceptionally bad taste or just plain creepy“. Was auch immer das heißen mag. Apple meint zwar, dass es ihnen wichtig ist, dass alle möglichen Meinungen vertreten sein dürfen, solange sie sich an sinnvolle Regeln des Diskurses halten. Satire und professioneller Humor ist jedoch erlaubt. Wo genau da Apple die Grenze zieht weiß keiner so richtig. Das hängt wahrscheinlich auch wieder persönlich vom Reviewer ab. Apple gibt aber auch ein paar Beispiele. Genannt werden hier Darstellung von Folter, Tötungen oder Missbrauch, Pornografie und verantwortungslosem Gebrauch von Waffen und Religiös motiviere Hetze. D.h. auch, dass wenn du ein neues soziales Netz aufbauen willst, dann bist du dafür verantwortlich solche Inhalte zu entfernen.
• Die App darf dem Benutzer keinen Schaden zufügen. Sowohl finanziell (also z.B. Scam bzw. Abzocke) als auch körperlich. Besonders werden medizinische Apps genannt. Medikamente dürfen z.B. nicht einfach so empfohlen/verordnet/dosiert werden. In solchen Fällen musst du Apple davon überzeugen können, dass du die Regulatoriken in deinem Land einhältst.
• Die App darf dem Handy/Tablet keinen Schaden zufügen. D.h. sie darf keine Malware oder Viren enthalten.
• Gibt es offensichtliche technische Probleme in deiner App? Ist sie extrem langsam? Hat Features, die noch nicht funktionieren? Stürzt sie ab? Dann wird deine App sicher abgelehnt. Das gilt auch für Beta-Versionen oder Demo-Apps. Hierfür gibt es andere Methoden um erste Versionen an Tester auszuliefern. Dazu werde ich in einem zukünftigen Artikel eingehen.
• Hast du akkurate Beschreibungstexte im AppStore? Stimmen die Screenshots oder die Beschreibungstexte nicht mit der App überein, so wird deine App abgelehnt. Benutzer sollen wirklich das bekommen was ihnen auch vor dem Kauf der App versprochen wurde.
• Eine App soll sich nicht so anfühlen wie ein Programm aus der Windows 95 Ära. Halte dich an Konventionen wie Apps unter iOS aufgebaut sind. Apps sollen sich eben anfühlen wie Apps. D.h. auch, dass eine App, die nichts anderes macht als eine Webseite/WebApp anzuzeigen, ebenso abgelehnt wird.
• Kein unnötiger Stromverbrauch. (Das heißt auch: keine Cryptowährtungs-Miner im Hintergrund laufen lassen!)
• Apps sollten nach einem iOS-Update noch funktionieren. Das bedeutet, dass der Entwickler nur bestimmte Schnittstellen benutzen darf, die von Apple als „öffentlich“ oder „public“ (d.h. stabil) deklariert sind. Dein Entwickler wird auf diesen Punkt achten.
• Die App darf nur mit spezifischen Gründen aktiv im Hintergrund laufen. Dies gilt auch zum Schutz vor Malware, die im Hintergrund schaden anrichten könnte oder unnötigen Stromverbrauch zur Folge haben könnte. Erlaubte Hintergrundaktivitäten sind:
  • VoIP (Telefonie)
  • Audiowiedergabe
  • GPS-Ortung und Navigation
  • Fertigstellung von rechenintensiven Prozessen wie z.B. Video-Exporte, Fertigstellung von Downloads etc.
• In-App-Käufe müssen über den Mechanismus von Apple gelöst sein. Benutzer kennen diesen Bildschirm und wissen, dass sie diesem ihre Zahlungsdaten anvertrauen können und dass diese nicht gestohlen werden.

Das sind die wichtigsten Punkte, die das Nutzererlebnis betreffen. Zusätzlich gibt es eben noch ein paar Sachen womit Apple entweder Sicherheit (im technischen Sinne) gewährleisten will, oder ihre Stellung und Provisionen verteidigen will. Zum Beispiel verbietet Apple andere AppStores auf iOS. Und als letzten Punkt will ich noch Legalitäten ansprechen. Findet Apple heraus, dass die App gegen Gesetze verstößt (wie z.B. Copyright), dann kann das ebenso folgen für dich haben.

Aber was, wenn die App doch abgelehnt wird?

Auch in diesem Fall kann ich dich beruhigen. Es kann durchaus mal passieren, dass ein Reviewer strenger ist als ein anderer. Auch kann es mal passieren, dass eine App durchgewunken wird und beim Review einer neueren Version der App eine alte und nicht angerührte Stelle der App bemängelt wird. Apple gibt bei jeder Ablehnung den Grund an und bittet dich darum diese Sache zu nachzubessern und es erneut zu probieren. Es ist also nicht so, dass Apple dich im Regen stehen lässt.

Wenn du jedoch offensichtlich bewusst und extrem fahrlässig gegen Apples Regeln verstößt oder probierst sie auszutricksen oder zu hintergehen, dann kann es durchaus passieren, dass dich Apple komplett vom AppStore ausschließt und deinen Account permanent sperrt.

Ja und Google? Was ist mit Android Apps und dem PlayStore?

Seit einiger Zeit hat auch Google einen Review für Apps, der jedoch deutlich schlanker ist als der von Apple. Googles Fokus liegt hier mehr auf das Aufspüren von Malware, Viren oder Copyright-Verletzungen. Android ist sehr viel offener entworfen und selbst wenn Google eine App nicht auf den PlayStore lässt, dann ist die App trotzdem möglicherweise über andere Stores verfügbar. Im Gegensatz zu Apple lässt Google ja auch Stores anderer Anbieter, wie z.B. den Amazon Appstore zu.

Details

Wenn du dich für die genauen Definitionen und alle weiteren Punkte interessierst, dann empfehle ich dir das offizielle Dokument von Apple: AppStore Review Guidelines

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören: