Ist deine App eine gute Idee?

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

Wie du Kosten bei der Entwicklung sparen kannst

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:

Apps mit Benutzern testen

Im Artikel „Warum du keine Angst vor dem App Review haben musst“ bin ich ja eingegangen wie du eine App überhaupt an den Kunden bringst. Du lädst die fertig gebaute App auf eine Verwaltungsplattform von Google für den PlayStore und auf AppStoreConnect für den Apple AppStore hoch, trägst die Beschreibungstexte und -bilder ein und gibst die App durch den Review für den Go-Live.

Jetzt willst du die App aber nicht immer direkt an die Kunden raus geben, sondern möchtest sie auch mal an ausgewählten Kunden testen. Und zwar bevor die App öffentlich erhältlich ist.

Aber wie können die Kunden die App installieren? Wie bekommen sie die App zum Testen? Beziehungsweise auch: wie bekommst du selber denn die App zum testen, damit du siehst was der Entwickler so schafft?

Mal wieder: auf Android ist alles einfacher

Mit Android hat man einige Freiheiten. Sowohl bei den Funktionen, die eine App ausführen darf als auch bei der Verteilung und Installation von Apps. Wie im Artikel „Warum du keine Angst vor dem App Review haben musst“ angerissen legt Apple auch einen starken Fokus darauf, dass Benutzer möglichst nur über den AppStore Apps beziehen können. Es darf keine anderen App Store Apps geben. Auf Android ist das anders und dementsprechend könnte man hier Apps einfach per E-Mail an die Tester schicken.

Warum das bei Apple schwieriger ist hat mit einem sehr technisch komplexen Thema zu tun, das auch für Nutzersicherheit relevant ist. Um eine App auf einem iOS-Gerät installieren zu können muss es auf eine bestimmte Art digital signiert sein. D.h. das Handy will bei der Installation sicher gehen, dass die App von einer vertrauenswürdigen Quelle kommt und fälschungssicher „unterschrieben“ wurde. Das sorgt auch dafür, dass es unter iOS z.B. keine gefakten Apps gibt. Trotzdem verursacht es einige Schwierigkeiten, sodass viele Entwickler sich auch nicht gerne mit dem Thema auseinandersetzen und es daher auch nicht verstehen. Die technischen Details würden den Rahmen dieses Artikels sprengen, ich kann jedoch erklären welche Wege es gibt um auch iOS-Apps zu testen.

Testen im kleinsten Kreis

Sind alle Tester bekannt und idealerweise eng an’s Entwicklerteam angeschlossen, so lohnt es sich diese Variante zu nutzen. Der Entwickler braucht hierfür die sogenannten UDIDs („Unique Device Identifier“, also eindeutige Geräte-IDs) aller Geräte mit denen die App getestet werden soll. Das heißt, dass alle Tester die nervige Aufgabe haben ein Mal diese ID herauszufinden und dem Entwickler zukommen zu lassen. Diese UDIDs müssen danach in Apples Entwicklerportal eingetragen werden, damit die App in der digitalen Signatur miteinbezieht welche Geräte die App überhaupt installieren dürfen. Wird man so eine App auf einem anderen und nicht vermerkten Gerät installieren wollen, so wird es einfach eine Fehlermeldung ausspucken. Die Liste mit UDIDs ist auch auf maximal 100 Einträge beschränkt, weswegen wir mit diesem Vorgehen größere Testerkreise direkt ausschließen können. Der Vorteil ist, dass eine App sofort installiert werden kann. Der Nachteil wie gesagt, dass man jeden einzelnen Tester nach seiner Geräte-ID fragen muss.

Die Apps können dann über Beta-Test-Plattformen wie AppCenter von Microsoft oder Firebase von Google verteilt werden. Wird eine neue Version hochgeladen, so bekommen die angemeldeten Tester eine E-Mail und können sich dann die Version herunterladen. So können übrigens auch Android-Apps an deine Tester verteilt werden, ohne, dass du alles manuell per E-Mails machen musst.

Testen im größeren Kreis

Kommt die erste Variante nicht infrage, weil du die Kunden nicht mit technischen Details wie die UDID nerven und ihnen das einfachste Erlebnis bieten willst, so kommt kein Weg um TestFlight vorbei. TestFlight ist ein Tool von Apple mit dem du die App an Tester verteilen kannst. Der Haken ist, dass du nur Apps testen lassen kannst, wenn sie den App Review von Apple bestanden haben. Das heißt eine App kann nicht sofort an deine Tester geschickt werden, sondern du musst wieder mit 1-2 Tagen rechnen bis die App durch den Review ist. Haben deine Tester die App „TestFlight“ installiert, so bekommen sie dann sogar Push-Nachrichten, wenn eine neue Version deiner App zum Testen verfügbar ist. Das heißt: der Nachteil dieser Variante ist, dass die App durch den Review muss und somit 1-2 Tage Wartezeit verbunden sind. Der Vorteil ist, dass deine Tester nur die TestFlight App installieren und auf einen Link von dir klicken müssen. Kein manuelles herausfinden der UDID, weniger Schwierigkeiten mit Zertifikaten und Codesignierung usw. Ebenso können deine Tester direkt via TestFlight Feedback an dich senden.

Zusammenfassung

Unter’m Strich kann man also wieder sagen: Testen ist auf Android leichter zu lösen als auf iOS. Du musst dich entscheiden, on du im kleinen Kreis testen willst und ob deine Tester technisch versiert genug sind um dir die Informationen (Geräte UDIDs) zuschicken zu können, die du brauchst. Ein guter Entwickler wird dich an dieser Stelle auch beraten was für den aktuellen Zeitpunkt die bessere Wahl ist. Ändern kann man das Vorgehen natürlich zu jeder späteren Zeit immernoch.

Podcast Folge zum hören

Diesen Artikel kannst du auch über meinen Podcast anhören. Falls dir mein Podcast gefällt kannst du ihn natürlich auf jeder Podcast-App finden und abonnieren, damit du nie eine Folge verpasst.

Wie funktioniert so eine App überhaupt?!

Diese Frage wurde mir neulich von einer Hörerin gestellt. Für mich als Entwickler war erstmal eine Rückfrage nötig was sie denn genau damit meint. So in meiner gedanklichen Welt gefangen wäre ich nie auf diese Frage gekommen. Einmal gestellt hat sie mich aber nicht losgelassen.

Ich glaube ein guter Start um das zu erklären ist erstmal den Blick weg von Apps und hin auf Webseiten zu richten. Ich schätze, dass meine Hörer und Leser eher mal mit der Verwaltung einer Webseite zu tun hatten als mit einer App. Aber auch wenn nicht, dann ist es ein guter Moment für Grundlagen.

Wie funktioniert eine Webseite?

Also eine Webseite liegt auf einem Server. Also auf einem Rechner, der an das Internet angeschlossen ist und der weiß, was er machen soll, wenn jemand zum Beispiel „janbrinker.de“ in die Adresszeile eingibt. Dafür benutzt du in der Regel einen sogenannten Hoster. Der ist einfach ein Dienstleister für dich um genau diesen Rechner für dich bereitzustellen und so zu konfigurieren, dass du einfach loslegen kannst. In meinem Fall ist auf diesem Server ein WordPress installiert (eine von vielen Softwares um Webseiten zu verwalten) und das wiederum weiß was zu tun ist, wenn die Startseite angezeigt werden soll, oder wenn in der URL noch was anderes drin steht, wie z.B. „janbrinker.de/applify“.

Dieses WordPress oder eine andere Software erzeugt dann eine Datei und schickt sie zu dir. Dein Browser, also Firefox, Chrome, Safari oder Edge weiß dann wie es mit dieser Datei umzugehen hat. Wie eine PDF. Diese Datei enthält auch irgendwelche Daten und dein PDF Reader weiß einfach wie es diese Datei anzeigen soll, wenn du sie öffnest. Nur mit Webseiten funktioniert das automatisch, wenn du eine Webseite öffnest.

In dieser Datei steht also drin was der Titel der Seite ist, wie das Menu aufgebaut ist, was der Inhalt der Seite ist und enthält auch Informationen für den Browser wie die einzelnen Elemente auszusehen haben. Also Farbe, Schriftart, Hintergrundbilder, Abstände usw. Der Browser weiß was zu tun ist und zeigt die Webseite dann genau so an wie du sie siehst.

Klickst du auf einen Link, dann wird eine neue Seite aufgemacht und das Spiel geht von vorne los. Der Server wird zu dieser spezifischen URL (also Adresse) gefragt, dieser baut sich die Datei zusammen, schickt sie dir zurück und der Browser zeigt sie wieder an.

Am Ende funktioniert also alles über diese Datei, die sagt wie das, was genau jetzt in diesem Moment angezeigt wird, definiert ist. Klickst du also auf einen neuen Link, dann ändert sich rein technisch betrachtet nicht nur der Inhaltsbereich der Seite, sondern auch alles andere wird komplett neu geladen. Also der Header, der Footer, das Menu usw., auch wenn sich visuell nichts verändern soll.

Und wie ist das jetzt mit Apps?

Jetzt ist das bei Programmen, also auch bei Apps ziemlich anders. Das liegt im großen und ganzen an der Art und Weise wie sich die Funktionsweise einer Webseite von einem Programm unterscheidet.

Wie eben beschrieben ist eine Webseite einfach ein Dokument, eine Datei, die von deinem Browser angezeigt wird. Lass es uns mal komplett vereinfachen und sagen, dass die Webseite ein Bild ist. Alles ist genau definiert wie es aussehen soll und wo was wie in welcher Größe mit welchen Abständen usw. platziert ist.

Ein Programm ist kein Bild. Ein Programm ist ein Rezept, eine Anleitung die deinem Rechner oder deinem Smartphone sagt was es tun soll, damit am Ende ein Bild rauspurzelt. Also wenn du eine App auf deinem Smartphone öffnest, dann fängt es an sich die „Zutaten“ beim Gerät zu holen. Zum Beispiel Speicherplatz, damit die App Bilder und Texte laden kann, sodass sie später angezeigt werden können. Dann wird die App Schritt für Schritt die Anleitungen vom Rezept abarbeiten. Das kann zum Beispiel so ablaufen:

  • Bitte liebes Smartphone, erstelle mir mal eine leere Seite, damit ich da drauf gleich Sachen anzeigen kann.
  • Auf die leere Seite platziere mir bitte eine Navigationsleiste
  • Unten drunter möchte ich eine Liste haben, damit ich später die Liste meiner Kontakte anzeigen kann.
  • Jetzt lade aus den gespeicherten Daten die Kontakte selber.
  • Sortiere zuerst die Kontakte nach dem Alphabet
  • Sortiert nach dem Vornamen oder nach dem Nachnamen? Ok, ich sortiere.
  • Für jeden Kontakt muss jetzt ein Listeneintrag erzeugt werden, damit diese in der Liste angezeigt werden können.
    • Genau nach folgendem Schema baust du dir jetzt die Anzeigefläche für den Listeneintrag:
      • Wie ist die App eingestellt? „Vorname Nachname“ oder „Nachname, Vorname“?
      • Ach ja, wir benutzen übrigens folgenden Font in jener Größe und dieser Textfarbe und folgende Abstände zu den Seiten
      • Hat der Kontakt auch ein Foto hinterlegt? Dafür haben wir hier einen Platzhalter, der mit dem Bild gefüllt werden kann.
  • Gebe der Liste die Listeneinträge
  • OK, für jetzt sind wir erstmal fertig mit dem Anzeigen der Liste.
  • Aber bitte liebe Liste, wenn der Benutzer ein Element antippt, dann sage mir bitte Bescheid, weil dann muss ich wieder Sachen machen.

Das heißt während eine Webseite schon „fertig“ definiert hat wie die Webseite aussieht, muss eine App dem Smartphone sagen was wo hin kommt und wie es auszusehen hat. Ähnlich wie man einem Umzugsunternehmen aktiv sagen muss was wo hin kommt, beziehungsweise dem man auch die Baupläne für die einzelnen Möbelstücke geben muss.

Ähnlich ist es auch, wenn der Benutzer auf einen Button oder eine Schaltfläche drückt, also z.B. im Beispiel oben auf ein Listenelement mit einem Kontakt. Die Liste wird irgendwann melden „Element in Zeile 5 wurde gedrückt“.

Dann schaut die App nach welches „Rezept“ dann ausgeführt werden soll. Dieses kann dann wie folgt aussehen:

  • Zeile 5… lass uns mal nachschauen welcher Kontakt überhaupt in Zeile 5 genannt wurde.
  • Smartphone, bitte öffne mir doch eine neue frische und leere Seite für die Kontaktdetails, animiere den Übergang und füge oben in die Navigationsleiste einen zurück-Button ein.
  • Auf die neue Seite platziere mir mal bitte folgende Elemente:
    • Einen Platz wo das Bild vom Kontakt angezeigt werden kann
    • Einen Platz wo der Name rein kommt (mit folgendem Text-Layout)
    • Einen Platz für die Telefonnummer. Ach so, dieser Platz ist auch ein Button: wenn dieser gedrückt wird, dann sage mir bitte Bescheid)
    • Einen Platz für die Email-Adresse, der auch ein Button ist. Auch hier sage mir bitte Bescheid, wenn der Button gedrückt wird.

Programmieren

Genau das ist programmieren. Der Entwickler macht nichts anderes als Abläufe bis auf’s kleinste Detail zu definieren. Nehmen wir doch nochmal das Umzugs-Beispiel zur Hand. Stell dir vor du willst umziehen, du selber und deine Verwandten, Freunde usw. dürfen aber selber keine Hand anlegen und keiner außer die Leute vom Umzugsunternehmen dürfen beim Umzug präsent sein. Alles was dir übrig bleibt ist ganz genau zu beschreiben was wie zu tun ist. Jeden Arbeitsschritt, den du vergisst oder auslässt wird entweder gar nicht getätigt oder die Leute vom Umzugsunternehmen machen eine Sache so wie sie diese Sache sonst auch immer machen. Egal ob das die Art und Weise ist die dir lieb ist. Du hast ja nichts definiert, also wird’s schon OK sein.

Alles was du am Ende siehst ist die neue und fertig eingerichtete und eingeräumte Wohnung. Stehen die Gläser mit dem Rand nach oben oder umgedreht im Schrank? Gehen die Schranktüren überhaupt so auf wie sie sollen, oder blockieren sich die Türen gegenseitig? Oder steht der Schrank vielleicht sogar mit der Vorderseite gegen die Wand? Hättest du das lieber besser beschreiben sollen? So entstehen übrigens auch Bugs und Fehler in Software.

Der gravierende Unterschied in der Funktionsweise zwischen Webseite und Programmen ist auch einer der Gründe warum es keine fertigen Layouts oder Themes gibt, die man einfach mit Inhalt befüllen kann und gut ist. Die App soll ja etwas tun, nicht nur anzeigen. Der Fokus liegt also auf der Funktion und daher ist programmieren auf das Tun fokussiert und nicht auf’s „so sieht es aus“.

Ein Blick zurück auf Webseiten

Jetzt mit den Grundlagen zu „was Softwareentwicklung überhaupt ist“ können wir jetzt auch nochmal einen interessanten Exkurs zurück zu den Webseiten machen. Oben meinte ich, dass ich „WordPress installiert habe“ und dass es „wiederum weiß was zu tun ist“. Fällt dir das Wort tun in’s Auge? WordPress und jede andere Verwaltungssoftware für Webseiten sind Programme. Ganz spezialisierte Programme, die nichts anderes können als dir die ganze Arbeit abzunehmen, damit du dich um das ganze „tun“ nicht kümmern musst. Das funktioniert weil technisch jede Webseite im Endeffekt immer das gleiche macht, nur eben immer anders aussehen und anderen Inhalt haben soll. Aber die Funktion ist immer gleich. Das heißt du bist Anwender der Software und konfigurierst sie nur, damit das Ergebnis so ist wie du willst. Die Anwendung an sich, also das, was am Ende die Arbeit verrichtet und die Webseite für dich nach deiner Konfiguration aufbaut, wird dir in dem Fall bereits gestellt. Das heißt die Anwendung gibt es schon.

In deinem Fall gibt es ja noch nicht mal die Anwendung. Darum geht es ja. Die Anwendung gibt es noch nicht, du siehst den Bedarf für so eine Anwendung und willst sie dann entwickeln lassen. Und ja, damit die Anwendung benutzbar ist brauchst du auch ein Layout zum Anzeigen. Aber der Unterschied zwischen Webseite und App ist eben der, dass es bereits viele spezialisierte Anwendungen gibt um Webseiten zu verwalten und für deinen Anwendungsfall eben nicht.

Daher ist auch die Entwicklung einer App per se deutlich teurer als die einer reinen Webseite. Die Software, die Funktion, muss erst noch entstehen. Man muss erst rausfinden wie man die metaphorischen Umzugshelfer mit Anleitungen versehen muss, damit am Ende alles so abläuft wie du willst.

Warum du keine Angst vor dem App Review haben musst

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: