Hörbuch-App entwickeln: Lesen und Hören als ein Produkt

Wer eine Hörbuch-App entwickeln will, steht vor einer anderen Aufgabe, sobald dasselbe Buch auch am Bildschirm gelesen werden soll. Dann ist es keine App mit Audio-Knopf mehr. Es werden zwei Produkte, Text und Audio, die sich in einem Punkt einig sein müssen: wo die Person im Buch ist. UnderBooks, eine von Logics7 entwickelte Lese- und Hörplattform, ist um genau diese eine gemeinsame Stelle gebaut.

Diese Notiz legt die Produktlogik dahinter dar: was jeder Modus braucht, wie der Wechsel funktioniert und welche Entscheidungen geklärt sein müssen, bevor jemand Code schreibt. Sie trifft keine Aussagen über Publikum oder Katalogumfang.

UnderBooks ist eine Plattform für Bücher in zwei Modi: am Bildschirm lesen und hören, mit der Möglichkeit, dazwischen zu wechseln, ohne die Stelle zu verlieren. Sie ist für Smartphone, Tablet und Desktop konzipiert. Sie hält den Fortschritt geräteübergreifend synchron, erlaubt Offline-Zugriff auf heruntergeladene Titel und empfiehlt anhand des bereits Gewählten, was als Nächstes zu lesen oder zu hören ist.

In den Begriffen, die die meisten Briefings zur Entwicklung von Hörbuch-Apps verwenden, ist sie eine E-Book- und Hörbuch-App, keine Hörbuch-App mit angehängtem Reader. Diese Unterscheidung prägt jede der folgenden Entscheidungen.

Lesen und Hören sehen aus wie ein Feature und sind zwei verschiedene Produkte. Text braucht Typografie, Suche, Annotation und schnelles Rendering. Audio braucht Streaming, Pufferung, Hintergrundwiedergabe und eine Position, die einen Anruf übersteht. Was folgt, ist die Logik jedes Modus in jedem Produkt dieser Art. Es ist keine Featureliste von UnderBooks.

Lesen: EPUB, Typografie, offline

Die Entwicklung einer E-Reader-App beginnt beim Format. Der offene Standard für E-Books ist EPUB, inzwischen in der dritten Hauptversion, EPUB 3. Ein EPUB-Reader muss Text für jeden Bildschirm neu umbrechen, vom Smartphone bis zum Desktopfenster. Typografie ist hier keine Dekoration: Zeilenlänge, Schriftgröße, Ränder und Kontrast entscheiden, ob jemand eine Stunde liest oder die App schließt. Suche und Annotation, einschließlich Markierungen, Notizen und Lesezeichen, müssen an der richtigen Passage bleiben, wenn der Text neu umbricht. Offline-Zugriff bedeutet, dass Buch, Schriften und die Annotationen der lesenden Person auf dem Gerät sind, bevor die Verbindung abreißt.

Hören: Streaming, Kapitel, Tempo, Hintergrundwiedergabe

Hörbuch-Streaming ist ein Auslieferungsproblem, bevor es ein Player-Problem ist. Lange Aufnahmen werden meist in Segmenten über ein CDN ausgeliefert, damit die Wiedergabe schnell startet und bei schwacher Verbindung vorpuffert. Hörerinnen und Hörer betrachten Kapitelnavigation, Wiedergabegeschwindigkeit, Lesezeichen und einen Sleep-Timer als Grundausstattung jeder Hörbuch-App. Bei der Hintergrundwiedergabe zeigt sich das Mobile Engineering: Das Betriebssystem kann Audio jederzeit pausieren oder stoppen, und iOS und Android setzen unterschiedliche Regeln. Die Position muss einen Anruf, einen gesperrten Bildschirm und ein verlorenes Signal überstehen.

Die verbindende Logik ist eine einzige Stelle im Buch, die beide Modi teilen. Das richtig hinzubekommen ist der Unterschied zwischen einer App mit Audio-Knopf und einem Produkt, in dem Menschen den Modus tatsächlich wechseln. In UnderBooks kann eine Person vom Text zum Audio oder von einem Gerät zum anderen wechseln und an derselben Stelle weitermachen.

Der schwierige Teil ist unsichtbar. Eine Position im Text ist eine Stelle im Buch; eine Position im Audio ist ein Zeitpunkt in einer Aufnahme. Synchronisation von Lesen und Hören bedeutet, für jeden Titel das eine auf das andere abzubilden, und das hält nur, wenn Text und Aufnahme dieselbe Ausgabe sind. Beim Entwickeln einer Hörbuch-App ist diese Zuordnung Teil der Katalogarbeit, keine Player-Einstellung.

Lesen in zwei Modi ist keine Nischenidee mehr. Amazon bietet Whispersync for Voice seit Jahren an: Man wechselt zwischen einem Kindle-E-Book und seiner Audible-Hörfassung, ohne die Stelle zu verlieren. Wer eine App wie Audible bauen will, sollte damit rechnen, dass Leserinnen und Leser dieselbe Kontinuität verlangen.

Bei einer Content-Plattform beginnt die Produktlogik außerhalb des Codes, und die Entwicklung einer Hörbuch-App ist keine Ausnahme. Die folgenden Fragen sind Produktentscheidungen, keine Engineering-Entscheidungen, und sie müssen vor dem ersten Sprint geklärt sein. Genau das heißt „keine Entwicklung ohne Produktlogik“ in der Praxis.

Katalog und Rechte

Rechte und Katalog kommen zuerst: was angeboten werden darf, wo, zu welchen Bedingungen und wie das nachgehalten wird. Lizenzen für Text und für Audio werden oft getrennt verhandelt, mit unterschiedlichen Rechteinhabern und Verlagen, sodass ein Titel in einem Modus existieren kann und im anderen nicht. Die Katalog-Metadaten müssen festhalten, welche Ausgabe, welches Territorium und welches Format jede Lizenz abdeckt. Wird KI-Vertonung oder Text-to-Speech erwogen, ist die Frage, ob eine Lizenz das erlaubt, eine Frage für den Rechteinhaber und eine Anwältin oder einen Anwalt. DRM für E-Books und Hörbücher folgt aus diesen Bedingungen: Es ist eine Lizenzanforderung, ausgedrückt in Code.

Die Audio-Auslieferung gehört in dasselbe Gespräch. Lange Aufnahmen, gestreamt und heruntergeladen, machen Speicher und CDN-Traffic zu laufenden Kosten, die das Preismodell tragen muss.

Formatökonomie und Bindung

Als Nächstes kommt die Ökonomie des Formats: Abo, Einzelkauf oder eine Mischung, und die Bindung, die jede Variante verlangt. Ein Abo verdient nur, solange Menschen weiterlesen oder weiterhören; die Bindung ist bei einer Lese-App also das Geschäftsmodell, keine Kennzahl daneben. Credits und Einzelkäufe hängen am nächsten Kauf, und In-App-Käufe über mobile App-Stores bringen eigene Gebühren und Regeln mit. Kontinuität zwischen den Modi und Empfehlungen auf Basis des bereits Gewählten sind Bindungsmechanik, keine Extras.

Barrierefreiheit schließt die Liste. Für manche Menschen ist Hören keine Bequemlichkeit, sondern der einzige Zugang. Ein Produkt, das Audio als Zusatz behandelt, lässt sie zuerst im Stich.

Dieselbe Struktur trägt jedes Content- oder Medienprodukt, nicht nur die Entwicklung von Hörbuch-Apps: Lernplattformen mit Text und Audio, unternehmensinterne Wissensbibliotheken, Abo-Medien-Apps, Kinderinhalte mit Familienkontrolle. Logics7 baut sie mit der Mobile-Engineering-Erfahrung aus Spielen und Echtzeitsystemen (Hintergrundwiedergabe, Offline-Toleranz, Synchronisation) und betreibt sie nach dem Launch.

Für ein neues Produkt ist die Route eine Product Partnership: Wir prüfen Markt, zahlenden Nutzer und Monetarisierungslogik, bevor über Entwicklung gesprochen wird. Für ein live laufendes Lese- oder Audioprodukt mit Nutzern, dessen Wachstum stockt, ist ein Existing Product Review der Weg, auf dem Logics7 entscheidet, ob es eine Beteiligung eingeht. Beide Routen enden mit einer Entscheidung am Leadership Gate, beschrieben unter So funktioniert unser Prozess.

Wenn Sie an einem Content- oder Medienprodukt arbeiten, beginnen Sie mit der richtigen Route.