Apps, die auf dem Homescreen bleiben.
Native iOS-, Android- und plattformübergreifende Apps — offline-first, instrumentiert und poliert auf den Standard, der Nutzer nach Woche eins zurückkommen lässt.
Downloads in Woche eins sind einfach. Retention in Woche zweiundfünfzig ist Engineering.
Die meisten Apps werden binnen Tagen aufgegeben — nicht weil die Idee falsch war, sondern weil die App auf einem drei Jahre alten Android langsam war, im Funkloch Daten verlor oder mit Benachrichtigungen nervte, die niemand wollte. Retention ist kein Marketingproblem; sie ist ein Engineering-Standard.
Unsere Apps betreiben Geschäfte: Kühlschränke, per Scan um 3 Uhr morgens entriegelt, Schichten, per NFC über Dutzende Standorte eingestempelt, Mahlzeiten, in zwei Taps bezahlt. Offline-First-Sync, native Payments und Analytics sind Fundamente in jedem Build — denn genau das braucht es, um auf einem Homescreen zu überleben.
Ausgeliefert in beide Stores.
Egal welche Plattformstrategie — der Standard ist identisch: schnell, offline-fähig, instrumentiert.
Natives iOS
Swift-Apps, die sich auf der Plattform selbstverständlich anfühlen — Widgets, App Clips und die Politur, die Apple-Nutzer bemerken.
Natives Android
Kotlin-Apps, abgestimmt auf das echte Gerätespektrum — inklusive der Mittelklasse-Hardware, die der Großteil der Welt in der Tasche trägt.
Plattformübergreifend
Flutter und React Native, wenn eine Codebase dem Geschäft besser dient — entschieden nach Engineering-Kriterien, nicht nach Mode.
Offline-First-Sync
Local-First-Daten mit konfliktfreier Synchronisation, damit die App in Kellern, Flugzeugen und Funklöchern funktioniert.
Payments, NFC & Push
In-App-Käufe, Wallets, Tap-to-Act-NFC und eine Benachrichtigungsstrategie, die den Nutzer genug respektiert, um aktiviert zu bleiben.
Store-Launch & danach
Review-feste Einreichungen, gestaffelte Rollouts, Crash-Monitoring und OS-Versionskompatibilität — lebenslang.
Politur ist ein Prozess, kein Schlusssprint.
Qualität, die die Store-Review und die Drei-Sterne-Wutrezension gleichermaßen übersteht.
01Auf dem Gerät prototypisieren
Klickbare Flows auf echter Hardware in Woche zwei — denn eine App wird in der Hand beurteilt, nicht in Figma.
02Offline-first bauen
Sync, Caching und Fehlerzustände von Anfang an engineert. Konnektivität wird als Bonus behandelt, nicht als Annahme.
03Auf echten Geräten testen
Eine Gerätewand aus günstigen Androids und alten iPhones — die Telefone Ihrer Nutzer, nicht das Ihres Gründers.
04Launchen & iterieren
Gestaffelte Rollouts, Crash-Free-Rate-Gates und analytics-getriebene Iteration. Die App wird mit jedem Release besser.
Wir haben das bereits ausgeliefert.
Die Mobile-App im Herzen eines $10M+-Connected-Retail-Geschäfts — stöbern, scannen, entriegeln, bezahlen.
FeelEat — Happy Fridge
Tagesmenüs durchstöbern, per Scan einen smarten Kühlschrank entriegeln, in der App bezahlen und genau sehen, was in jedem Gericht steckt — Nährwerte, Allergene und Herkunft inklusive.
Gewählt für das Problem, nicht für den Lebenslauf.
Nativ, wo es zählt, geteilt, wo es sich auszahlt — jede Entscheidung nach Engineering-Kriterien begründet.
Ein Team. Null Übergaben.
Die Disziplinen, die am häufigsten mit Mobile Apps kombiniert werden — gleiche Architektur, dieselben Engineers, ohne Integrationsaufschlag.
Fragen, beantwortet.
Was Käufer von Mobile Apps uns am häufigsten fragen. Alles andere — schreiben Sie es in ein Briefing, ein Senior-Engineer antwortet innerhalb eines Werktags.
Schreiben Sie es in ein Briefing. Ein Senior-Engineer — kein Vertriebler — antwortet innerhalb eines Werktags.
Q.01Nativ oder plattformübergreifend — was sollen wir wählen?
Es hängt davon ab, was die App tut — und wir argumentieren es mit Belegen. Tiefe Plattformintegration, Kamera- oder Hintergrundarbeit spricht für nativ; Content- und Commerce-Apps liefern auf Flutter oder React Native meist schneller und günstiger, ohne für Nutzer sichtbare Kompromisse.
Q.02Wie lange dauert es, bis wir im App Store sind?
Eine fokussierte v1 dauert typischerweise 10–16 Wochen inklusive Store-Review. Wir reichen früh ein, mit gestaffeltem Rollout — der Launch-Tag ist ein Knopfdruck, kein Stoßgebet an die Review-Warteschlange.
Q.03Übernehmen Sie die Freigabe in App Store und Play Store?
End-to-End — Listings, Datenschutzangaben, Review-Notizen und den unvermeidlichen Tanz der Neueinreichung. Wir haben genug Apps ausgeliefert, um zu wissen, was Reviewer beanstanden, bevor sie es tun.
Q.04Was passiert nach dem Launch?
Lebenslanger Support: OS-Versionskompatibilität, Sicherheits-Patches und Crash-Monitoring vom Team, das die App gebaut hat. Apps verrotten ohne Wartung — unsere holen nach Jahren noch Fünf-Sterne-Bewertungen.
Q.05Können Sie eine mobile App übernehmen, die eine andere Agentur gebaut hat?
Häufig. Wir beginnen mit einem einwöchigen Code-Audit, der eine Remediation-Roadmap erzeugt, dann übernehmen wir die Codebase in Phasen. Häufige Wechselgründe: instabile Architektur, verstecktes Offshore-Staffing oder zum Erliegen gekommene Feature-Velocity.
Q.06React Native oder Flutter, wenn wir cross-platform gehen?
React Native, wenn Ihr Team bereits React/TypeScript kennt und Sie Logik mit einer Web-App teilen wollen — Ökosystem und Hiring-Pool sind größer. Flutter, wenn Sie pixelidentische UI auf allen Plattformen wollen und Dart Sie nicht stört. Beide sind produktionsreif; entscheiden sollten Ihre vorhandenen Skills und mögliche Web-Code-Synergien, nicht der Hype.
Q.07Wie handhaben Sie In-App-Käufe und Abos?
Wir setzen RevenueCat über StoreKit und Google Play Billing, damit Belegvalidierung, Entitlements und plattformübergreifender Abo-Status an einer Stelle laufen statt in zwei fragilen nativen Integrationen. Sie bekommen außerdem die Abo-Analytics, die Apple und Google nicht liefern — und das Wiederherstellen von Käufen, ein häufiger Ablehnungsgrund, wird zuverlässig.
Q.08Wie liefern Sie Updates aus, ohne jedes Mal durch den App Store zu müssen?
Fixes auf der JavaScript-Ebene können in React Native per CodePush/EAS Update over-the-air ausgeliefert werden — innerhalb der Richtlinien von Apple und Google, ohne Review-Zyklus für berechtigte Änderungen. Nativer Code braucht weiterhin ein Store-Release. Zusätzlich bauen wir Remote-Feature-Flags und einen Forced-Update-Mechanismus, um Features dunkel zu starten und ein Upgrade zu erzwingen, wenn ein API-Bruch es verlangt.
Haben Sie eine App, die Ihre Nutzer
lieben sollten?
Sagen Sie uns, welchen Job die App erledigen muss und für wen. Ein Senior-Mobile-Engineer antwortet innerhalb eines Werktags mit Plattformberatung und einem ehrlichen Umfang.