Kinpal: Eine App mit KI-Agenten bauen – und was danach wirklich Zeit kostet

Die Idee

Eine Frau aus meinem Fitnessstudio hat sich etwas gewünscht: Auf dem Heimweg im Dunkeln so aussehen, als sei sie beschäftigt. Wer am Handy schreibt oder telefoniert, wird seltener angesprochen. Und wenn es doch brenzlig wird, sollen die Menschen, denen sie vertraut, es sofort erfahren, ohne dass das Gegenüber etwas merkt.

Daraus ist Kinpal geworden (kinpal.app):

Fake-Chat, der in menschlichem Rhythmus tippt und antwortet, mit echten Nachrichtentönen, im Look des eigenen Handys (iPhone oder Android, hell und dunkel).
Schein-Anruf: Man spricht frei, die Spracherkennung schreibt auf Wunsch ein Tagebuch mit und hört auf einen selbst gewählten Signalsatz.
Rettungsanruf: ein verzögerter eingehender Anruf, ausgelöst per Tipp, Schütteln oder Action-Taste am iPhone.
Ruhemodus: eine Hörbuch-Ansicht für alle, die in Bahn oder Wartezimmer einfach in Ruhe gelassen werden wollen.
Stiller Alarm: Fällt der Signalsatz, bekommen die Vertrauenskontakte einen Push mit Live-Standort. Kontakte ohne App bekommen einen Kartenlink per SMS vom eigenen Handy.

Kein Konto, keine Werbung, kein Tracking. Tagebuch, Wege und Aufnahmen bleiben auf dem Gerät.

Wo der Aufwand steckt

Das Produkt: Konzept und Marktrecherche, die App mit allen Modi, Tests am echten iPhone, der Alarm-Server auf Cloudflare samt einer Architektur-Korrektur, der Einmalkauf mit Länderpreisen, eine Umbenennung nach Markenprüfung, 15 Sprachen, die Website, Store-Texte, Screenshots, Grafiken, ein Demo-Video für Google und die Jagd nach einem Absturz, der nur im Android-Release-Build auftrat. KI-Agenten haben dabei den Großteil des Codes geschrieben. Die Entscheidungen, die Recherche und das Testen am Gerät haben sie nicht abgenommen.

Alles andere: Stand heute liegen iOS-Version 1.0 und der In-App-Kauf bei Apple in der Prüfung, der öffentliche TestFlight-Link wartet auf die Beta-Prüfung, und bei Google läuft ein geschlossener Test mit 45 Testerinnen und Testern, der mindestens 14 Tage dauern muss. Diese Zeit macht kein Agent kürzer.

Das ist die eigentliche Lektion dieses Projekts: Das Bauen ist nur ein Teil. Mindestens genauso schwer sind die Stores: Formulare, Erklärungen, Prüfungen, Fristen und die Schritte, die nur ein Mensch machen darf.

Deshalb steht dieser Teil hier vorne.

Der eigentliche Aufwand: in die Stores kommen

Wer noch nie eine App veröffentlicht hat, unterschätzt das. Hier ist die vollständige Liste dessen, was für Kinpal anfiel. Nicht als Anleitung für jede App, sondern als ehrliches Inventar.

Apple: App Store und TestFlight

Entwicklerkonto im Apple Developer Program (99 $ im Jahr), dazu Vereinbarungen, Steuer- und Bankdaten, sobald es etwas zu kaufen gibt.
App-Eintrag in App Store Connect mit Bundle-ID.
Signieren. Unser Team-API-Schlüssel darf keine von Apple verwalteten Zertifikate nutzen. Also: lokal vorhandenes Distribution-Zertifikat suchen (das erste gefundene war abgelaufen), per API ein App-Store-Profil dafür erzeugen, exportieren, hochladen.
Purpose-Strings für jede Berechtigung. Kinpal braucht acht: Mikrofon, Spracherkennung, Standort (zwei Stufen), Bewegung, Kamera und zweimal Fotomediathek. Die Fotomediathek hatten wir nicht auf dem Zettel; ein Expo-Modul referenziert sie. Der Upload scheiterte daran still: Die API zeigt keinen Build, nur die Weboberfläche zeigt den Fehler.
Store-Texte in 16 Store-Sprachen: Name, Untertitel, Beschreibung, Schlüsselwörter, Werbetext, Support- und Marketing-URL. Mit Zeichenlimits je Feld, die ein Skript vor dem Hochladen prüft.
Wortwahl in den Texten. Keine fremden Marken, kein „Prank“, keine „Nummer 1“-Behauptungen. Apple lehnt Scherz-Apps ab (Richtlinie 1.1.6), dazu kommen die Regeln zu Metadaten.
Screenshots im Format des 6,9-Zoll-iPhones, 1320 × 2868 Pixel, pro Sprache.
Kategorie, Altersfreigabe, Inhaltsrechte.
Review-Kontakt und Review-Hinweise. Bei Kinpal wichtig: klarstellen, dass die App Vertrauenskontakte benachrichtigt und kein Rettungsdienst ist (Richtlinie 5.1.5), und dass der Messenger-Look ein eigener ist (4.1, keine Nachbauten).
Preis: App gratis, dazu den In-App-Kauf anlegen, mit Länderpreisen von Hand.
Prüfscreenshot für den In-App-Kauf. Muss ein echtes Geräteformat haben. Ein zugeschnittenes Bild bleibt ohne Fehlermeldung auf „fehlende Angaben“ stehen.
App-Datenschutz („Nutrition Labels“): Standort, Name, Geräte-ID, jeweils Zweck, Verknüpfung, Tracking. Gibt es nicht per API, nur im Browser.
Was beim Einreichen noch fehlte. Apple meldet Blocker nicht als Liste, sondern versteckt sie in einer Fehlerantwort. Bei uns waren es: die DAC7-Erklärung, die App-Datennutzung und das Copyright-Feld.
Der erste In-App-Kauf geht nur zusammen mit einer App-Version in die Prüfung, und diese Verknüpfung geht nur in der Weboberfläche.
TestFlight öffentlich: externe Testgruppe, öffentlicher Link, Beta-Texte, Review-Kontakt, und dann eine eigene Beta-Prüfung, bevor der Link funktioniert.
Push-Schlüssel (APNs) für Sandbox und Produktion. Unser vorhandener galt nur für die Sandbox; Expo meldete TopicDisallowed. Neuer Schlüssel, neu hinterlegen.

Google: Play Console

Entwicklerkonto mit Identitäts- und Zahlungsprofil-Verifizierung. Das läuft über Google, nicht über uns.
Release-Bundle (AAB), signiert. Und vorher am echten Gerät starten: Unsere erste Release-Version stürzte sofort ab, weil R8 eine Klasse entfernt hatte, die WorkManager per Reflection lädt. Der Build war grün, Debug lief. Fix: zwei Keep-Regeln über expo-build-properties.
Store-Eintrag: Texte, Icon 512 × 512, Feature-Grafik 1024 × 500, Screenshots.
App-Inhalte, ein Formular nach dem anderen: Datenschutz-URL, Werbung, App-Zugang, Behörden-App, Finanzfunktionen, Gesundheit, Werbe-ID, Zielgruppe (bei uns 16–17 und 18+).
Datensicherheit: Standort, Name und Push-Token angeben, je mit Zweck, Pflicht oder optional, verschlüsselt ja/nein. Dazu eine Seite zum Löschen der Daten, die es vorher nicht gab. Wichtig: Die Weitergabe an selbst gewählte Kontakte gilt bei Google als vom Nutzer veranlasste Übertragung, nicht als „Teilen“.
Altersfreigabe per IARC-Fragebogen. Dafür muss man den IARC-Bedingungen zustimmen. Das ist ein Klick, den ein Mensch machen muss.
Berechtigungen aufräumen. Expo-Module bringen Berechtigungen mit, die man nicht braucht und die Google trotzdem prüft. Wir haben Overlay, Speicherzugriff, Aktivitätserkennung und Hintergrund-Standort ausdrücklich blockiert.
Erklärung zu Vordergrund-Diensten, mit Video. Kinpal zeichnet den Heimweg in einem Standort-Vordergrunddienst auf. Google verlangt eine Begründung und ein Video, das die Funktion in der App zeigt. Das Video haben wir gedreht und hochgeladen.
Push für Android: Firebase-Projekt, Konfigurationsdatei in die App, FCM-Schlüssel zu Expo hochladen.
In-App-Kauf anlegen und Lizenztester eintragen, bevor man selbst kauft. Sonst ist es eine echte Bestellung. Uns ist genau das passiert; wir haben sie erstattet.
Geschlossener Test: 12 Personen, 14 Tage am Stück. Dazu gleich mehr.
Antrag auf Produktionszugang nach den 14 Tagen, mit einer Zusammenfassung des Tester-Feedbacks. Ob er durchgeht, entscheidet Google.

Zusammen sind das 28 Punkte, ohne den Code. Fast jeder davon kann eine Einreichung aufhalten.

Die Testerpflicht bei Google

Neue private Entwicklerkonten bei Google dürfen nicht einfach veröffentlichen. Vorher muss ein geschlossener Test mit mindestens 12 Personen laufen, die 14 Tage am Stück dabeibleiben. Erst danach darf man den Produktionszugang beantragen.

12 Menschen mit Android-Handy, die zwei Wochen lang eine App installiert lassen, hat man nicht einfach so. Wir haben es über Fiverr gelöst und dafür eine kleine Ausschreibung geschrieben. Was darin steht, und warum:

Verkäufer mit Hunderten abgeschlossenen Aufträgen und einer Bewertung ab 4,8. Wer nach drei Tagen abspringt, hilft niemandem.
20 statt 12 bestellen. Puffer, falls jemand aussteigt. Aktuell sind 45 dabei.
Erst bestellen, wenn Google den geschlossenen Test freigegeben hat. Vorher gibt es keinen Einladungslink, und die Tage zählen nicht.
Echte Geräte, echte Nutzung. Die Tester sollen die App in den 14 Tagen mehrmals öffnen: Chat, Anruf, Heimweg aufzeichnen, Ruhemodus, sich als Vertrauenskontakt eintragen.
Kurzes schriftliches Feedback pro Person. Das braucht man für den Antrag auf Produktionszugang.
Keine echten Alarme an Fremde, keine Fake-Bewertungen. Steht ausdrücklich drin.
Keinem Garantieversprechen glauben. Google entscheidet selbst.

Der Ablauf danach: Gmail-Adressen der Tester in die Testerliste eintragen, Einladungslink („Join on the web“) an den Verkäufer, 14 Tage warten, Produktionszugang beantragen. Für Android-Interessierte außerhalb von Fiverr steht auf der Website: Mail mit der Google-Konto-Adresse, dann kommt die Einladung.

Diese zwei Wochen sind eine feste Größe. Man kann sie nicht beschleunigen, nur früh genug starten.

Was der Agent dabei übernimmt und was nicht

Hier lohnt sich ein genauer Blick, denn auch im Store-Teil hat der Agent viel gemacht, nur eben anders.

Der Agent schreibt Werkzeuge. Für Apple gibt es im Projekt jetzt Skripte für Metadaten, Screenshots, Review-Einstellungen, In-App-Kauf mit Länderpreisen, TestFlight und eine Prüfung der Store-Texte gegen die Limits. Alles über die App-Store-Connect-API, alles wiederverwendbar für die nächste App.

Der Agent schreibt Ausfüllzettel. Wo es keine API gibt, also bei der Play Console, beim IARC-Fragebogen und den Apple-Datenschutzangaben, hat der Agent eine Datei geschrieben: welches Feld, welcher Haken, welche Begründung. Ich klicke, der Agent hat vorher gelesen, was die Richtlinie verlangt.

Der Agent findet die versteckten Blocker. Etwa die Gründe, die Apple in einer Fehlerantwort versteckt, oder den R8-Absturz im Log.

Der Agent kann nicht:

Bedingungen akzeptieren (IARC, Store-Vereinbarungen)
Konten und Zahlungsprofile verifizieren
CAPTCHAs lösen und Zwei-Faktor-Anmeldungen bestätigen
DNS bei der Domain eintragen
ein Demo-Video vom echten Handy aufnehmen
Tester finden und bezahlen
auf Apple und Google warten

Der Stack

App: Expo SDK 58

Expo SDK 58 mit React Native 0.88 und React 19.3, Expo Router mit typisierten Routen, der React Compiler ist eingeschaltet.
i18next mit 15 Sprachen: Englisch, Deutsch, Spanisch, Portugiesisch, Französisch, Italienisch, Türkisch, Polnisch, Arabisch (von rechts nach links), Hindi, Bengalisch, Indonesisch, Vietnamesisch, Swahili, Chinesisch.
Native Bausteine fast nur aus dem Expo-Baukasten: expo-speech-recognition für Tagebuch und Signalsatz, expo-location für Heimweg und Alarm, expo-camera für den Notfall-Modus, expo-sqlite für lokale Daten, expo-notifications für Push, expo-app-intents für die Action-Taste, expo-quick-actions, expo-iap für den Kauf.
Keine Expo-Go-Spielerei: wegen der nativen Module von Anfang an ein Development Build.

Eine Warnung zu Expo und KI: Expo ändert mit jeder SDK-Version APIs. Ein Agent, der aus dem Gedächtnis schreibt, schreibt veralteten Code. In unserem Projekt steht deshalb ganz oben in der AGENTS.md: erst die Doku zur passenden SDK-Version lesen, dann programmieren. Das hat mehr Fehler verhindert als jede Nachkorrektur.

Alarm-Server: ein Cloudflare Worker

Der Server ist ein einziger Worker, der Alarme weiterreicht. Er kennt nur zwei Dinge:

Empfänger im KV-Speicher: eine nicht erratbare ID, ein Anzeigename und ein Push-Token. Wer die App ein Jahr lang nicht öffnet, verschwindet automatisch.
Laufende Alarme, jeder als eigenes Durable Object mit SQLite und WebSocket für die Live-Karte. Ein Alarm löscht sich nach 48 Stunden selbst.

Push geht über den Expo-Push-Dienst an APNs und FCM. Die App fragt danach die Zustellbestätigungen ab und zeigt an, wie viele Kontakte wirklich erreicht wurden. Für Kontakte ohne App gibt es eine Live-Kartenseite.

Gegen Missbrauch hängen Rate Limits von Cloudflare davor: 30 neue Alarme oder Empfänger pro Minute und IP, 120 Positionen pro Minute und Alarm. Bewusst großzügig, weil sich im Mobilfunk viele Menschen eine IP teilen. Lehnt der Server ab, fällt die App auf SMS zurück.

Die wichtigste Architektur-Korrektur kam aus der Recherche, nicht aus dem Code. Der erste Entwurf speicherte Live-Positionen in KV. Die Recherche gegen die Cloudflare-Doku ergab: KV erlaubt einen Schreibvorgang pro Sekunde und Schlüssel, Lesevorgänge können bis zu 60 Sekunden alt sein, und im Free-Plan ist nach 1.000 Schreibvorgängen am Tag Schluss. Für einen Notfall-Alarm untauglich. Also ein Durable Object pro Alarm und der Workers-Paid-Plan für 5 $ im Monat. Der Umbau selbst war Code. Die richtige Frage zu stellen war die eigentliche Arbeit.

Website: statisches HTML als Worker-Assets

kinpal.app ist reines HTML und CSS, ausgeliefert als Assets eines Workers mit eigener Domain; www leitet auf die Hauptdomain um. Dazu:

eine llms.txt, die Sprachmodellen in Klartext erklärt, was die App kann, was sie kostet und was nicht (zum Beispiel: kein Notruf-Dienst mit Leitstelle),
FAQ als JSON-LD für die Suchmaschinen,
Sitemap, Anmeldung in der Google Search Console und IndexNow.

Kein Framework, kein Build-Schritt. Für eine Produktseite reicht das.

Das Preismodell

Alles, was im Notfall schützt, ist gratis: Notfall-Modus, Signalsatz-Alarm, Rettungsanruf, Live-Standort, Vertrauenskontakte. Für Empfängerinnen und Empfänger ist die App immer kostenlos.
Ein einziger Einmalkauf „Vollversion“ für die Extras: 2,99 € in Deutschland. Kein Abo, keine Werbung.
Länderpreise von Hand. Die automatischen Preise der Stores folgen dem Wechselkurs, nicht der Kaufkraft: Die 2,99-$-Stufe kostet in Indien ₹ 299. Deshalb setzen wir für Mitteleinkommensländer die 0,99-$-Stufe und für Niedrigeinkommensländer die 0,49-$-Stufe. Ein Skript legt Produkt und Preise per App-Store-Connect-API an.

Ein Bezahl-Download kam nicht infrage. Jede Nutzerin bringt ihre Vertrauenskontakte in die App, und das funktioniert nur, wenn der Download nichts kostet.

Der Name

Die App hieß zuerst „Beschäftigt“, dann „Sawa“. Vor dem Store-Start lief eine Markenrecherche: Beim DPMA ist „S SAWA“ für App-Software und Sicherheitsdienste eingetragen, dazu kamen weitere Treffer im Ausland. Also umbenannt in Kinpal: keine Marke in den relevanten Klassen gefunden, kinpal.app war frei. Name, Texte, Grafiken und Store-Einträge in allen Sprachen mussten mit. Ohne die Recherche wäre das nach dem Launch passiert, und dann wird es teuer.

Worauf du achten solltest

Store-Aufwand einplanen, nicht den Code. Die Liste oben ist länger als die Feature-Liste der App.
Bei Google die 14 Tage sofort starten. Geschlossenen Test so früh wie möglich freigeben lassen und Tester bestellen; alles andere kann parallel laufen.
Berechtigungen und Purpose-Strings vor dem ersten Build klären. Jede überflüssige Berechtigung ist ein weiteres Formular.
Release-Builds am Gerät testen. Debug und Release verhalten sich anders.
Store-Regeln vor der Positionierung lesen. Ob eine App als „Streich“ oder als „Sicherheitshilfe“ auftritt, entscheidet über die Prüfung.
Recherche vor Architektur. Die teuerste Korrektur (KV statt Durable Objects) hätte sonst erst im Ernstfall zugeschlagen.
Versionierte Doku statt Gedächtnis. Bei Expo zwingend.
Markencheck vor dem Launch. Ein Name ist schnell gewählt und spät teuer.

Der Stack auf einen Blick

App:        Expo SDK 58, React Native 0.88, React 19.3, React Compiler
Routing:    Expo Router (typisierte Routen)
Sprachen:   i18next, 15 Sprachen inkl. Arabisch (RTL)
Kauf:       expo-iap, Einmalkauf, Länderpreise von Hand
Server:     Cloudflare Worker, Durable Objects (je Alarm), KV (Empfänger), Rate Limits
Push:       Expo Push -> APNs / FCM, mit Zustellbestätigung
Website:    statisches HTML als Worker-Assets, llms.txt, FAQ-JSON-LD
Stores:     App-Store-Connect-API-Skripte, Ausfüllzettel für die Play Console
Entwicklung: Claude Code

Fazit

KI-Agenten verschieben, wo die Arbeit liegt. Code entsteht schneller als früher, aber eine App für zwei Plattformen ist mehr als Code: Architektur, Recherche, Recht, Tests am Gerät. Die andere Hälfte sind 28 Store-Schritte, eine 14-tägige Testpflicht, Prüfungen und Klicks, die nur ein Mensch machen darf. Wer das einplant, ist nicht enttäuscht. Wer es nicht einplant, sitzt mit fertiger App vor einer Zwei-Wochen-Frist.

Kinpal ist im Test. Wer mitmachen will: Für das iPhone gibt es TestFlight, für Android eine kurze Mail an [email protected] mit der Google-Konto-Adresse.