Zweiter Teil meiner Artikelserie über die Entwicklung unabhängiger Produkte

Der vorige Artikel beschrieb aus Sicht eines iOS-Entwicklers Ressourcen, um einen Bedarf zu bestimmen, eine unabhängige App zu entwickeln und sie zu veröffentlichen. Mit begrenzten Mitteln konnte ich nur Dienstprogramme fertigstellen, die in Apples App Store erhältlich waren.

Dieser Artikel betrachtet die plattformübergreifende Entwicklung eines vollwertigen Produkts, die dabei auftretenden Probleme und ihre Lösungen. Ich zeige, wie ich nach und nach ein vollständiges Produktökosystem aus einem öffentlichen WeChat-Konto, einem Mini-Programm und einer App aufgebaut habe.

1. Produktziele

Allgemein ist ein Produktziel der Wert, den ein Produkt schafft. Selbst wenn ein Anwendungsfall vorhanden ist, hat ein Produkt ohne Wert – eines, das kein Geld verdient und nur sehr wenige Nutzer hat – kaum einen Grund zu bestehen.

Oder wir könnten noch weiter ausholen und mit der Produktvision beginnen …

Stopp. Denke noch nicht über all das nach, sonst kommt dein Produkt womöglich nie über endlose Vorstellungen hinaus.

Wenn Ressourcen, Menschen und Investitionen begrenzt sind, wird unser Ziel klar: Welche Probleme soll das Produkt lösen, oder welche Funktionen muss es bieten?

Als ich beispielsweise File Manager entwickelte, hatte das MVP ein klares Ziel: Dateien zwischen Telefon und Computer übertragen.

Nach Abschluss des MVP ergaben sich auf natürliche Weise weitere Anforderungen. Einige stammten aus meinen Produktplänen, noch mehr aus Rückmeldungen der Nutzer:

  • 1.0.0 Dateien zwischen Telefon und Computer übertragen
  • 1.1.0 Bild-, Video- und Audiodateien anzeigen oder wiedergeben
  • 1.2.0 Dateien gruppieren, verschieben, löschen, komprimieren und teilen
  • 1.3.0 Den Player verbessern
  • 1.4.0 Sicherheitsprüfung hinzufügen: Gestencodes und Biometrie
  • 2.0.0 In-App-Käufe hinzufügen
  • 2.1.0 Dokumentenscan hinzufügen
  • …

Ursprünglicher File-Manager-Screenshot: Dateiansicht und Verwaltungsfunktionen

Ursprünglicher File-Manager-Screenshot: zusätzliche Dateiwerkzeuge und Oberfläche

Wähle ein Ziel. Es muss nicht groß, aber umsetzbar sein. Konzentriere dich auf eine Sache und mache weiter, selbst wenn sie falsch erscheint – wie willst du es wissen, ohne sie fertigzustellen ◔ ‸◔? Schließe sie ab und blicke dann zurück.

2. Produktprototypen

Im vorigen Artikel erwähnte ich, dass ich viele Prototyping-Werkzeuge ausprobiert hatte und zu dem Schluss gekommen war: In der Zeit für den Prototyp hätte ich die Ansichten mit xib bauen können.

Hier widerspreche ich mir selbst ,,Ծ‸Ծ,,

Bei einem persönlichen Dienstprogramm ohne Folgeplan, das man einfach fertigstellen und veröffentlichen möchte, ist dieser Gedanke verständlich.

Wenn sich das Produkt weiterentwickelt, verursacht ein schrittweises Vorgehen ohne Prototyp oder Plan ernste Probleme für die künftige Entwicklung. Das Entwerfen eines Prototyps ist in Wirklichkeit ein Ordnen der Produktlogik.

Hier sind einige Prototyping-Werkzeuge. Am häufigsten verwende ich derzeit MockingBot.

3. Projektmanagement

Nachdem ich eigenständig eine iOS-App entwickelt und veröffentlicht hatte, fiel mir ein ernstes Problem auf: Ich hatte kein Verständnis von Projektmanagement. Ich arbeitete, wenn ich Zeit hatte oder daran dachte, und tat nichts, wenn ich träge war.

Es war mein eigenes Produkt, von mir entworfen und entwickelt. Das MVP hatte wahrscheinlich keine zahlenden Nutzer, also fühlte ich mich ihnen gegenüber nicht verantwortlich.

Das bremst ein Projekt erheblich. Zu langes Arbeiten ohne Plan kann es sogar scheitern lassen.

Nach mehreren Jahren Iterationsmanagement bei der Arbeit stellte ich fest, dass Projektmanagement-Werkzeuge auch für persönliche Projekte gut funktionieren. Haben wir klare Produktziele und einen logisch stimmigen Prototyp, ergibt sich die Aufteilung in Aufgaben von selbst.

Für das Projektmanagement verwende ich coding.net; dort lässt sich auch Quellcode hosten.

Ursprünglicher Projektmanagement-Screenshot: Arbeit in einzelne Aufgaben aufgeteilt

Zerlege Aufgaben in Einheiten von wenigen Stunden. So lassen sie sich leichter verwalten und Testfälle einfacher schreiben. Heute ist es meine Gewohnheit, die Testfälle vor dem Programmieren fertigzustellen. Das ist wesentlich.

Ein Prototyp ordnet die Produktlogik; Testfälle ordnen die Umsetzungsdetails. Vollständige Testfälle führen uns zur richtigen Geschäftslogik ✅ und verhindern viele fachliche Fehler ❌.

4. Technologiewahl

Bis hierhin war alles Vorbereitung; mit der Entwicklung haben wir noch nicht begonnen. Die zentrale Schwierigkeit: Ich bin der einzige Entwickler und möchte dennoch das vollständige Ökosystem aus einem öffentlichen WeChat-Konto, einem Mini-Programm und einer App bauen.

Dafür wären Kenntnisse in Mini-Programmen, iOS und Android nötig. Eine Programmiersprache zu lernen ist nicht besonders schwer, doch dieselbe Geschäftslogik dreimal umzusetzen kostet den dreifachen Aufwand. Das ist eindeutig unrealistisch.

Normalerweise könnten wir mit dem Web mehrere Plattformen bedienen oder sogar ganz auf die App verzichten und uns auf öffentliches Konto und Mini-Programm konzentrieren. In der Anfangsphase, wenn Produktanforderungen schnell geprüft werden müssen, ist das ein sehr vernünftiger Ansatz.

Eine kurze Suche zeigt viele plattformübergreifende Technologien. Um App und Mini-Programm mit einer Codebasis auf drei Plattformen zu entwickeln, können wir Uni-App verwenden. Es basiert auf dem Frontend-Framework Vue.js; iOS und Android werden über Weex unterstützt.

Für persönliche Produkte oder kleine kommerzielle Produkte reicht das aus.

5. Datenverwaltung

Nachdem der Ansatz für Mini-Programm und App feststeht, bleibt eine weitere entscheidende Frage: Wo sollen die Daten liegen?

Für ein Dienstprogramm genügt es, Daten lokal in der App zu speichern. Was aber, wenn das Ziel eine Informationsplattform mit vollständigem Nutzersystem oder sogar eine komplexere Community mit nutzergenerierten Inhalten ist?

Uni-App bietet einen eigenen uniCloud-Dienst. Die Serverentwicklung kann in JavaScript erfolgen, und Mini-Programme sowie Apps können den Server ohne Domainnamen verwenden.

Ich wählte einen anderen Weg und hostete die Daten auf der serverlosen Plattform LeanCloud. Mini-Programm und App greifen über das JavaScript-SDK von LeanCloud auf die gehostete Datenbank zu.

Der Entwicklungstarif unterstützt 30.000 kostenlose API-Anfragen pro Tag und bietet zudem SMS-Dienste. Das reicht für ein Nutzersystem, das Hochladen von Nutzerdaten und das Abrufen von Plattformdaten.

Wenn die Anfragen das Entwicklungskontingent überschreiten, hat dein Produkt eine gewisse Nutzergröße erreicht. Ich glaube, dass die Einnahmen aus diesem Verkehr dann den kommerziellen Tarif mit nutzungsabhängiger Abrechnung decken sollten.

Eine freche Art der Datenbeschaffung

Was, wenn du eine Wetter- oder Informations-App entwickeln möchtest, aber keine Wetter- oder Nachrichtendaten hast?

In China gibt es viele API-Marktplätze, darunter:

Alibaba Cloud API Marketplace

Tencent Cloud API Marketplace

Baidu Cloud API Marketplace

Juhe Data

EastApi

und weitere.

Diese Marktplätze bieten sowohl kostenpflichtige als auch kostenlose APIs.

  • Wenn dein Produkt den Datenverkehr gut monetarisieren kann, kommen kostenpflichtige APIs infrage.

  • Andernfalls kannst du die kostenlosen Kontingente nutzen. Doch 100 Testanfragen sind beim Testen schnell verbraucht. Was dann?

Du kannst die serverlose LeanCloud-Datenbank mit einem API-Marktplatz kombinieren. Frage beispielsweise beim täglichen Wetter zunächst die Datenbank ab. Fehlen die Daten, rufst du sie vom Marktplatz ab und speicherst sie anschließend in der Datenbank.

Und wenn 100 Anfragen weiterhin nicht für alle Städte reichen? Bleib erfinderisch und beantrage Kontingente bei mehreren Plattformen.

6. Veröffentlichung und Betrieb

Nun haben wir Mini-Programm, App und Server entwickelt. Wie veröffentlichen wir sie?

Mini-Programme sind recht unkompliziert: Folge auf der Plattform für öffentliche WeChat-Konten den Anweisungen zur Beantragung eines Mini-Programms.

Für eine iOS-Veröffentlichung ist ein kostenpflichtiges Entwicklerkonto erforderlich. Das ist eine Hürde, doch für einen langfristigen Betrieb empfehle ich die Anmeldung auf Apples Entwicklerwebsite. Das ist inzwischen einfach: Lade die Developer-App auf ein iPhone und bezahle dort.

Für die Android-Verteilung benötigst du eine Registrierung des Softwareurheberrechts. Ein regulärer Antrag kann 1-2 Monate dauern; alternativ kannst du einen Drittanbieter damit beauftragen.

Bleiben wir beim kreativen Sparen: Wo können wir Bilder, Audio und Video für Werbeplätze in App und Mini-Programm speichern?

Die Medienbibliothek des öffentlichen Kontos löst dieses Problem. Speichere Bilder, Audio und Video dort, rufe ihre ursprünglichen URLs ab, und App sowie Mini-Programm können darauf zugreifen.

7. Einnahmen erzielen

Eine einfache Möglichkeit zur Monetarisierung von Reichweite ist Werbung.

Die Zulassungsvoraussetzungen der Plattformen für Publisher steigen jedoch stetig, sodass die Einbindung von Werbung für unabhängige Entwickler schwierig ist.

  • Uni-App bietet eine Ein-Klick-Integration; siehe die Dokumentation.

  • Sobald ein öffentliches Konto ein Publikum aufgebaut hat, kann es Werbeplätze in Artikeln aktivieren.

  • Ein Mini-Programm kann nach 1.000 eindeutigen Besuchern die Publisher-Monetarisierung aktivieren.

8. Schlussgedanken

Damit haben wir das eingangs beschriebene Ökosystem aus öffentlichem WeChat-Konto, Mini-Programm und App fertiggestellt.

Nach diesen Schritten habe ich den Prozess für drei Produkte abgeschlossen. Scanne die Codes, um sie auszuprobieren:

Ursprüngliche QR-Codes historischer Produkte; ihre Verfügbarkeit kann sich geändert haben