Wie ich Anılog entwickelt habe: ein Entscheidungsprotokoll von der Idee bis zum Store

Das Schwierige beim Bau einer App ist nicht, Code zu schreiben. Das Schwierige ist zu entscheiden, welchen Code man nicht schreibt. Anılog — eine App, in der eine Freundesgruppe zu selbst gewählten Zeiten ein paar Sekunden aufnimmt und am Abend alles zu einem Vlog wird — war dafür ein gutes Beispiel.

In diesem Beitrag geht es um die Entscheidungen, nicht um den Code: was ich gewählt habe, warum, was mich später eingeholt hat und was sich bewährt hat.

Was dabei herauskam:

• 39 Dart-Dateien, rund 7.400 Zeilen
• 15 PHP-Dateien, rund 2.000 Zeilen — ohne Framework, ohne Composer
• 8 MySQL-Tabellen
• iOS und Android, beide mit Homescreen-Widget

Entscheidung 1: Firebase nur für die Identität

Das war die erste und folgenreichste Entscheidung. Firebase komplett zu nutzen (Auth + Firestore + Storage) wäre der schnellste Weg gewesen. Ich habe es nicht getan.

Der Grund sind die Speicherkosten. Anılog ist eine Video-App: jede Person lädt jeden Tag mehrere Clips hoch. Bei Firebase Storage heißt das eine Rechnung, die mit der Nutzerzahl wächst und schwer vorhersehbar ist. Ein Hostinger-Paket hatte ich ohnehin; Speicher und Traffic lagen dort zum Festpreis bereit.

Die Grenze wurde so gezogen:

• Firebase Auth → Anmeldung mit Google und Apple. Zu beweisen, wer jemand ist, ist Googles Aufgabe; die schreibe ich nicht neu.
• Mein eigener PHP- und MySQL-Server → Gruppen, Clips, Kommentare, Reaktionen, Mediendateien. Also alle Daten und alle Kosten.

Der Preis dieser Trennung: der Server muss das Firebase-ID-Token selbst prüfen. Wie das in reinem PHP ohne Composer geht, habe ich in einem eigenen Beitrag beschrieben.

Entscheidung 2: keine sozialen Medien bauen

Der erste Entwurf von Anılog hatte einen Explore-Feed, öffentliche Profile und ein Follower-System. Ich habe alles gelöscht.

Nicht nur der Einfachheit halber. Öffentliche Inhalte bedeuten:

• Moderation. Melden, Blockieren, eine Prüfschlange.
• App-Store-Richtlinie 1.2. Apps mit nutzergenerierten Inhalten müssen Melde- und Blockierfunktionen haben.
• Eine Speicherrechnung, die nicht skaliert.

Geschlossene Gruppen (höchstens 10 Personen, Beitritt per Einladungscode) beseitigen alle drei Punkte. Und sie machen das Produkt besser: wo es keine Follower-Zahl gibt, teilen Menschen tatsächlich ihren gewöhnlichen Alltag.

Lehre: Funktionen zu streichen spart mehr Zeit, als Funktionen hinzuzufügen.

Entscheidung 3: das Aufnahmefenster ist das Produkt

Eine App, in der jeder jederzeit aufnehmen kann, ist nur eine gemeinsame Galerie. Was einen gemeinsamen Moment schafft, ist die Beschränkung.

Das Modell: die Gruppe legt einige Aufnahmezeiten fest (höchstens 8). Nach jeder Zeit öffnet sich ein Fenster; schließt es, ist der Moment vorbei. Wie lange es offen bleibt, wählt die Gruppe ebenfalls — 10 Minuten, 30 Minuten, 1 Stunde oder 2 Stunden. Standard sind 30 Minuten.

Diese Logik liegt auf dem Server, nicht im Client. Die Uhr im Client gehört der Nutzerin oder dem Nutzer; wer die Handyzeit ändert, könnte das Fenster beliebig öffnen. Nach dem Umzug auf den Server habe ich 13 Szenarien lokal getestet, inklusive Mitternachtswechsel und Upload-Karenz. Ein Fenster über Mitternacht (23:50 + 30 Min) schrieb in der ersten Fassung auf den falschen Tag — ohne die Tests hätte ich das nie bemerkt.

Entscheidung 4: niemanden zu etwas zwingen

Mein erster Kamerabildschirm zwang das Handy ins Querformat, damit Videos horizontal werden. Beim Benutzen meiner eigenen App habe ich das gehasst und wieder ausgebaut.

Das Endverhalten: die Oberfläche ist im Hochformat fixiert, die Kamera aber frei. Hoch- oder querformatig aufnehmen, ganz wie man will. Der Vlog-Schritt akzeptiert beides (wie, steht im ffmpeg-Beitrag).

Dasselbe Prinzip beim Auslöser: ein Tippen nimmt auf, Gedrückthalten ebenfalls. Beim Halten zoomt ein Wischen nach oben; ein Doppeltippen wechselt die Kamera — auch mitten in der Aufnahme. Statt zu raten, wie jemand das Handy hält, habe ich jeden Fall unterstützt. Die technischen Details stehen in einem eigenen Beitrag.

Entscheidung 5: den Vlog auf dem Handy rendern, nicht auf dem Server

Die Clips eines Tages zu einem Video zu verbinden heißt, irgendwo ffmpeg laufen zu lassen. Auf Shared Hosting ist das entweder unmöglich oder quälend langsam.

Ich habe das Rendern aufs Handy verlegt. Die Vorteile machen die Entscheidung offensichtlich:

• Keine CPU-Kosten auf dem Server
• Die Vlog-Datei wird nie hochgeladen → kein Speicher, kein Traffic
• Ein Ergebnis, das das Gerät nie verlässt → die Datenschutzaussage stimmt wirklich

Der Preis: ein paar Minuten Rechenzeit auf dem Handy und getrennte ffmpeg-Tests pro Plattform. Ein akzeptabler Preis.

Wie der Name entstand

Ein langweiliger, aber praktischer Schritt: der Name muss in den Stores frei sein. Ich habe jeden Kandidaten im Play Store und im App Store gesucht. "Anılog" blieb übrig, weil es sowohl das türkische Wort anı (Erinnerung) als auch log enthält — und weil die Suche danach nichts anderes zutage förderte.

Domain und Paketname wurden gleichzeitig geprüft: com.anilog. Den Namen vor der ersten Codezeile festzulegen heißt, nie einen Paketnamen ändern zu müssen. Das muss man nur einmal erlebt haben.

Wo kommt KI ins Spiel?

Anılog entstand größtenteils mit KI-Unterstützung — nach der Vibe-Coding-Methode. Keine der fünf Entscheidungen oben hat das Modell getroffen. Beschleunigt hat es:

• Die erste Fassung eines Bildschirms
• Das Durchprobieren der ffmpeg-Filterkette (und das Messen der Versuche an echten Dateien)
• Das Schreiben der PHP-Endpunkte
• Denselben Bildschirm in drei Sprachen zu bringen

Gar nicht geholfen hat es hier, weil es das nicht kann:

• Zu entscheiden, welche Funktion gestrichen wird
• Zu erraten, wie jemand sein Handy hält
• Zu sehen, wo die Kosten explodieren

Ist diese Grenze klar, beschleunigt KI wirklich. Ist sie es nicht, bekommt man einen Haufen plausibel aussehenden, in sich widersprüchlichen Code.

Aktueller Stand

Anılog wird auf die Store-Einreichung vorbereitet. Datenschutzerklärung und Kontolöschung über das Web sind live, das Datenschutz-Manifest (PrivacyInfo.xcprivacy) und die Verschlüsselungserklärung sind fertig.

Im Rückblick war die wertvollste Gewohnheit, jede Zahl an genau einer Stelle zu halten: Clip-Länge, Gruppengröße, Bearbeitungsfenster, Aufnahmefenster. Alles in einer einzigen Einstellungsdatei auf dem Server. App, Server und Produktseite nennen dieselbe Zahl, weil sie sie an derselben Stelle lesen.

Die weiteren Teile der Serie:

• Flutter-Kamera ohne erzwungene Ausrichtung
• Firebase Auth mit eigenem PHP-Server
• Videos auf dem Handy mit ffmpeg zusammenfügen