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.
Inhalt geprüft:
Bis Freitag gelöscht — oder jahrelang behalten.
Die meisten Apps verschwinden binnen Tagen vom Telefon, und selten, weil die Idee schlecht war. Die App war langsam auf einem drei Jahre alten Android, verlor Daten im Funkloch, nervte mit Benachrichtigungen, die niemand wollte. Das zu beheben ist Engineering-Arbeit — und sie beginnt lange vor dem Launch.
Unsere Apps betreiben Geschäfte: Kühlschränke, per Scan Tag und Nacht 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 Grossteil der Welt in der Tasche trägt.
Plattformübergreifend
Flutter und React Native, wenn eine Codebase dem Geschäft besser dient — eine Entscheidung, die wir im Einzelfall technisch begründen.
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 und Crash-Monitoring, OS-Updates im optionalen Support-Plan.
Qualität mit Terminplan.
Qualität, die die Store-Review und die Drei-Sterne-Wutrezension gleichermassen übersteht.
01Auf dem Gerät prototypisieren
Klickbare Flows auf echter Hardware in Woche zwei — denn eine App wird zuerst in der Hand beurteilt.
02Offline-first bauen
Sync, Caching und Fehlerzustände sind von Anfang an mitgebaut, damit Signalverlust mitten in der Aufgabe folgenlos bleibt.
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.
Ihr Produkt könnte der nächste Fall auf dieser Seite sein.
Kostenloser 4-Stunden-WorkshopFeelEat im Taschenformat.
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.
Zwei Plattformen, ein Werkzeugkasten.
Nativ, wo es zählt, geteilt, wo es sich auszahlt — und wir legen die Begründung offen, bevor die Wahl fällt.
Der Rest des Produkts.
Eine App braucht ein Backend, eine Designsprache und manchmal Hardware dahinter. All das entsteht hier im Haus.
Plattform offen? Starten Sie hier.
Nativ oder plattformübergreifend, Store-Freigabe, das Leben nach dem Launch — was wir jedem Gründer sagen, der fragt.
Schreiben Sie es in ein Briefing. Ein Senior-Engineer liest es und antwortet innerhalb eines Arbeitstages.
Nativ 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.
Wie 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, die Review längst erledigt.
Ü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.
Was passiert nach dem Launch?
30 Tage Gewährleistung, danach ein optionaler Support-Plan: 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.
Kö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.
React 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össer. 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.
Wie 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 ausserdem die Abo-Analytics, die Apple und Google nicht liefern — und das Wiederherstellen von Käufen, ein häufiger Ablehnungsgrund, wird zuverlässig.
Wie 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.
Eine Idee, die zwischen iOS und Android
feststeckt?
Sagen Sie uns, welchen Job die App erledigen muss und für wen. Ein Senior-Mobile-Engineer antwortet innerhalb eines Werktags mit einer Plattform-Empfehlung und einem realistischen Umfang.