App-Entwicklung: Hirnworx liefert iOS- und Android-Apps aus einer Flutter-Codebasis, mit nativen Modulen dort, wo Cross-Platform an Grenzen stößt, und Backend, Store-Listing und Submission aus derselben Hand. MVPs liegen bei 25.000 bis 45.000 €, Cross-Platform-Apps bei 60.000 bis 120.000 € (Stand: September 2026). Referenzen: Travl Tracker im App Store und die Silk Road Rally App.
App-Entwicklung – iOS, Android und Cross-Platform
Apps, die im Alltag benutzt werden – nicht nur in der Demo funktionieren.
Stand: September 2026 · Verantwortlich: David De Matteo, Hirnworx Langenzenn
Wir liefern mobile Produkte end to end: Discovery und Scope, UX und klickbarer Prototyp, Sprint-Entwicklung mit testbaren Builds in TestFlight und Google Play Internal Testing, danach Store-Release und Wartung. Für die meisten Projekte ist Flutter die richtige Grundlage – eine Codebasis für beide Plattformen, native Module nur dort, wo Kamera, Hintergrund-Standort oder Bluetooth es verlangen.
Richtwerte netto: MVP 25.000 bis 45.000 €, Cross-Platform-App mit Backend und Push 60.000 bis 120.000 €, Enterprise und IoT 100.000 bis 250.000 €. Erweiterungen nach dem Launch alternativ ab 120 €/h. Festpreis nach Scope-Workshop, in Etappen – kein offener Stundenzettel. Stand: September 2026. Aufschlüsselung unter /kosten/app-entwicklung.
Zwei Apps zeigen die Spannweite: Travl Tracker rekonstruiert aus der Fotobibliothek automatisch besuchte Länder und Städte, vollständig offline (/referenzen/travl-tracker). Die Silk Road Rally App begleitet eine Rallye über rund 15.000 Kilometer mit Live-Etappenkarte, Geofence-Quests und Offline-Roadbook (/referenzen/silkroad-rally-app). Ein Ansprechpartner über die gesamte Laufzeit: David De Matteo, Entwickler seit 2011, über 350 Projekte.
Was umfasst professionelle App-Entwicklung?
App-Entwicklung ist der Weg von der Produktidee zur veröffentlichten mobilen Anwendung: Scope und Plattformentscheidung, UX und Oberfläche, Implementierung gegen die Schnittstellen von iOS und Android, Backend für Daten, Push und Anmeldung, Store-Einreichung mit allen Pflichtangaben sowie der laufende Betrieb. Der Unterschied zu einer Website liegt nicht im Design, sondern in den Rahmenbedingungen: Zwei Plattformbetreiber prüfen jede Veröffentlichung, jede Version muss auf Geräten mehrerer Jahrgänge laufen, und eine installierte App lässt sich nicht stillschweigend austauschen.
Drei Produkttypen fallen unter denselben Begriff. Eine Consumer-App lebt von Aktivierung und Bindung: Der erste Start entscheidet, das Geschäftsmodell läuft über Kauf oder Abonnement im Store. Eine Begleit-App zu einem Ereignis, einem Gerät oder einer Dienstleistung hat eine klar umrissene Aufgabe und einen definierten Nutzerkreis – sie misst sich daran, ob sie im entscheidenden Moment funktioniert. Eine Enterprise-App ersetzt Zettel und Tabellen im Außendienst oder im Lager; hier zählen Datenintegrität, Rollen und Offline-Betrieb.
Diese Einordnung entscheidet über Budget und Technik, nicht der Geschmack. Eine Consumer-App braucht Onboarding und ein sauberes Store-Listing, eine Begleit-App Robustheit bei schlechtem Netz, eine Enterprise-App Berechtigungen, Protokollierung und eine Verteilung auch ohne öffentlichen Store. Wer die Fälle vermischt, zahlt für Funktionen, die niemand nutzt, oder stellt drei Monate nach dem Start fest, dass die Architektur die eigentliche Anforderung nicht trägt.
Abgrenzung nach innen: Alles, was serverseitig passiert – Schnittstellen zu ERP und Warenwirtschaft, Datenmodelle, Integrationen – beschreiben wir unter /softwareentwicklung. Öffentliche Websites und Web-Apps mit Sichtbarkeitsziel laufen unter /webentwicklung. Viele App-Projekte enthalten beides; im Angebot weisen wir die Teile getrennt aus.
Woran App-Projekte typischerweise scheitern
Die meisten Anfragen erreichen uns nicht auf der grünen Wiese, sondern nach einem ersten Versuch. Die Muster wiederholen sich.
Die App wurde gebaut, aber nie veröffentlicht
Der Code ist fertig, doch niemand hat sich um Zertifikate, Bereitstellungsprofile, Datenschutzangaben und Store-Texte gekümmert. Die Einreichung scheitert an formalen Punkten, das Projekt bleibt in der letzten Meile liegen – obwohl der eigentliche Aufwand dort nur wenige Tage beträgt.
Zwei native Teams, doppelte Rechnung
iOS und Android wurden getrennt beauftragt. Jedes Feature wird zweimal spezifiziert, zweimal gebaut, zweimal getestet – und die beiden Versionen driften auseinander. Bei einer App ohne hardwarenahe Spezialanforderung ist das die teuerste Variante ohne erkennbaren Gegenwert.
Kein Backend eingeplant
Die App war im Angebot, der Server nicht. Sobald Daten zwischen Geräten geteilt, Push-Nachrichten versendet oder Nutzer angemeldet werden sollen, fehlt die halbe Architektur. Nachträglich eingezogen kostet sie regelmäßig mehr als die ursprüngliche App-Position.
Offline wurde nie getestet
Im Büro mit WLAN läuft alles. Im Tunnel, im Keller oder auf der Landstraße bricht die App ab, weil jede Ansicht eine Live-Abfrage braucht. Offline-Fähigkeit ist eine Architekturentscheidung, keine Option, die man am Ende einschaltet.
Die App veraltet im Store
Apple und Google verlangen regelmäßig neue Build-Werkzeuge und Ziel-Versionen, Abhängigkeiten bekommen Sicherheitsupdates, Geräte und Bildschirmformate ändern sich. Ohne Wartungsbudget ist eine App nach zwei bis drei Jahren nicht mehr wirtschaftlich aktualisierbar, weil zu viele Versionssprünge gleichzeitig anstehen.
Niemand hat den Nutzen definiert
Die Anforderung lautete „wir brauchen auch eine App“, nicht „dieser Vorgang dauert heute acht Minuten und soll zwei dauern“. Ohne messbaren Zweck entsteht eine Sammlung von Bildschirmen, die nach dem Launch niemand öffnet. Diesen Punkt klären wir im Discovery – notfalls mit dem Ergebnis, dass eine mobile Website reicht.
Travl Tracker — iOS App
Native SwiftUI-App, die aus der Fotobibliothek automatisch besuchte Länder & Städte erkennt — komplett offline, ohne Cloud, mit Karte, Statistiken und Reise-Pass.
Was wir liefern
Cross-Platform-Apps mit Flutter
Eine Codebasis für iOS und Android: gleicher Funktionsstand auf beiden Plattformen, ein Release-Zug, deutlich geringerer Wartungsaufwand als zwei getrennte native Teams.
Native iOS- und Android-Entwicklung
Swift und Kotlin dort, wo es nötig ist – tiefer Systemzugriff, Hintergrundverarbeitung, Widgets und Hardwareanbindung. Travl Tracker ist als native SwiftUI-App für iOS 17 und neuer gebaut.
MVP in Etappen
Erste marktfähige Version mit zwei bis drei tragenden Funktionen ab 25.000 €, geschnitten im Discovery – statt einer Wunschliste, die das Budget aufbraucht, bevor Nutzer die App sehen.
Backend, Push und Synchronisation
REST- oder GraphQL-Schnittstelle, Authentifizierung, Rollen, Push-Infrastruktur und Abgleich zwischen Geräten – aus derselben Hand wie die App, damit die Abstimmung nicht zum Risiko wird.
Offline-First und Geodaten
Lokales Datenmodell, Änderungswarteschlange, Konfliktauflösung, Geofencing und Kartenfunktionen bis hin zu vollständig geräteseitiger Geokodierung ohne Server.
Store-Release und Betrieb
Store-Listing, Screenshots, Datenschutzangaben, Einreichung und danach laufender Betrieb mit SDK-Updates, Anpassung an neue Plattformversionen und Fehler-Monitoring.
Was belegt ist
Nur Angaben mit benannter Quelle. Marktforschungszahlen ohne nachprüfbare Herkunft stehen hier bewusst nicht.
Zeitfenster, in dem laut Apple die Mehrheit der eingereichten Apps geprüft wird
Die Prüfung ist planbar, aber nicht garantiert: Eine Ablehnung startet den Zyklus mit der nächsten Einreichung neu. Wir planen für den Release deshalb ein bis zwei Wochen ein, nicht einen einzelnen Tag.
Reduzierte Provision im App Store Small Business Program statt der regulären 30 %
Für Anbieter unterhalb der Umsatzschwelle halbiert sich die Abgabe auf Käufe im Store nahezu. Die Anmeldung gehört deshalb vor den ersten Verkauf, weil sie nicht rückwirkend gilt.
App Store Privacy Details und Google Play Data Safety müssen vor der Veröffentlichung vollständig ausgefüllt sein
Beide Plattformen verlangen eine Erklärung, welche Daten erhoben, wofür sie genutzt und ob sie mit Dritten geteilt werden. Falsche Angaben sind ein Ablehnungsgrund – deshalb inventarisieren wir Datenflüsse und eingebundene SDKs vor der ersten Einreichung.
Apple Developer, App Privacy Details; Google Play Console-Hilfe, Datensicherheit, 2026
Für wen wir Apps entwickeln
Wir sind eine Ein-Personen-Agentur mit Partnernetzwerk, unter anderem der Runourcode GmbH in Langenzenn. Das macht uns für bestimmte Vorhaben sehr gut und für andere erkennbar falsch geeignet.
Mittelstand mit einem klaren Prozess
Außendienst, Service, Logistik, Instandhaltung: Wenn ein wiederkehrender Vorgang heute auf Papier oder in einer Tabelle läuft, ist der Nutzen messbar und der Umfang schneidbar. Solche Projekte starten oft als MVP für eine Plattform und wachsen danach kontrolliert.
10–250 Mitarbeitende
Produkt- und Event-Anbieter mit Begleit-App
Rallyes, Touren, Messen, Geräte mit Bluetooth-Anbindung: eine App mit klarem Anlass, klarer Nutzergruppe und hartem Termin. Robustheit bei schlechtem Netz zählt hier mehr als Funktionsumfang – wie bei der Silk Road Rally App.
Einmalige oder wiederkehrende Events
Gründerinnen und Gründer mit finanziertem MVP
Eine erste marktfähige Version mit den zwei bis drei Funktionen, die die Hypothese testen, statt einer Wunschliste aus dreißig Bildschirmen. Voraussetzung: ein Budget ab etwa 25.000 € und die Bereitschaft, den Umfang zu schneiden.
Budget ab 25.000 €
Wann Sie besser jemand anderen fragen
- —Ihr Budget liegt unter 15.000 €. Eine veröffentlichte App mit Backend und Store-Prozess ist darunter nicht seriös zu liefern – dann ist eine mobil optimierte Web-App der ehrlichere Weg, und die bauen wir unter /webentwicklung.
- —Sie möchten ein Spiel entwickeln. Grafik-Pipelines, Engine-Arbeit in Unity oder Unreal und Game-Design sind ein eigenes Handwerk, das wir nicht anbieten.
- —Sie brauchen 24/7-Bereitschaft mit vertraglicher Reaktionszeit unter einer Stunde. Wir arbeiten mit definierten Servicezeiten, nicht im Schichtbetrieb.
- —Der Auslöser ist „wir brauchen auch eine App“, ohne benannten Vorgang, Nutzergruppe und messbares Ziel. Das klären wir im Discovery – wenn kein tragfähiger Nutzen herauskommt, raten wir ab, statt zu bauen.
- —Die App soll in zwei Wochen live sein und der Umfang steht noch nicht fest. Allein die Store-Prüfung ist ein eigener Schritt mit Unwägbarkeiten; ohne geklärten Scope machen wir keinen Festpreis, und ohne Festpreis fangen wir nicht an.
Was App-Entwicklung kostet
Wir arbeiten mit Festpreisen nach einem Scope-Workshop, abgerechnet in Etappen. Die Spannen unten sind Erfahrungswerte aus vergleichbaren Vorhaben; den verbindlichen Preis nennen wir, wenn Funktionsumfang, Backend, Plattformen und Offline-Anforderungen geklärt sind. Für Erweiterungen nach dem Launch gibt es alternativ einen Stundensatz ab 120 €/h.
Stand: September 2026 · Festpreis nach Scope
MVP (Kernfunktionen)
Flutter, eine Plattform plus schlankes Backend. Erste marktfähige Version mit zwei bis drei tragenden Funktionen. Stand: September 2026.
- ·Discovery mit User Stories und geschnittenem MVP-Umfang
- ·UX-Flows, Designsystem und klickbarer Prototyp vor der Entwicklung
- ·Flutter-Umsetzung für iOS oder Android, die zweite Plattform bleibt technisch offen
- ·Schlankes Backend für Anmeldung, Daten und Push
- ·Store-Listing, Datenschutzangaben und Einreichung inklusive
Beispiel: Begleit-App für einen Serviceprozess mit Anmeldung, Auftragsliste, Foto-Upload und Statusmeldung – im unteren Bereich der Spanne, wenn die Daten aus einer dokumentierten bestehenden Schnittstelle kommen.
Cross-Platform-App
iOS und Android aus einer Codebasis, eigenes Backend, Push-Infrastruktur und mehrere zusammenhängende Funktionsbereiche.
- ·Gemeinsame Codebasis für beide Plattformen mit plattformspezifischen Anpassungen
- ·Backend mit REST- oder GraphQL-Schnittstelle, Authentifizierung und Rollen
- ·Push-Nachrichten, Hintergrundaktualisierung und Synchronisation
- ·Offline-Speicher mit definierter Konfliktauflösung
- ·Automatisierte Builds, Testverteilung und beide Store-Einreichungen
Beispiel: Die Silk Road Rally App mit Live-Etappenkarte, Checkpoints, Höhenprofil, Wetterwarnungen, Geofence-Quests mit Foto-Nachweis, Rangliste, Live-Feed und Offline-Roadbook – mehrere Funktionsbereiche, die alle auch ohne Netz tragfähig sein müssen.
Enterprise / IoT
Native Module, Anbindung an Bestandssysteme, Compliance-Anforderungen und vereinbarte Servicezeiten.
- ·Native Module in Swift und Kotlin für Bluetooth, Hintergrundprozesse oder Hardwarezugriff
- ·Integration in ERP, Warenwirtschaft oder Identitätsverwaltung
- ·Rollen- und Rechtekonzept, Protokollierung und Auditierbarkeit
- ·Verteilung über die Stores oder als interne Unternehmens-App
- ·Betriebsvereinbarung mit Servicezeiten, Monitoring und Release-Plan
Beispiel: Außendienst-App mit Offline-Auftragsbearbeitung, BLE-Anbindung an Messgeräte, Synchronisation gegen das ERP und getrennten Rollen für Monteure und Disposition.
Unverbindliche Richtwerte netto, projektabhängig. Verbindlich wird der Preis nach dem Scope-Workshop und dann als Festpreis in Etappen.
Was den Preis nach oben treibt
Die Spanne oben entsteht nicht zufällig. Diese sechs Faktoren erklären, warum ein Projekt am unteren oder am oberen Ende liegt.
Anzahl der Plattformen
Mit Flutter teilen sich iOS und Android den größten Teil des Codes; der Aufschlag für die zweite Plattform entsteht durch plattformspezifische Anpassungen, Geräteprüfung und einen zweiten Store-Prozess. Zwei getrennte native Codebasen kosten annähernd das Doppelte, weil jedes Feature zweimal entsteht.
Backend und Synchronisation
Sobald Daten zwischen Geräten geteilt, Nutzer angemeldet oder Push-Nachrichten ausgelöst werden, braucht es einen Server mit Datenmodell, Schnittstelle, Rechteprüfung und Monitoring. Ein reiner Lesezugriff auf eine bestehende API liegt am unteren Ende, eine bidirektionale Synchronisation am oberen.
Offline-Betrieb
Offline heißt nicht zwischenspeichern. Es braucht ein lokales Datenmodell, eine Warteschlange für nicht gesendete Änderungen, eine Regel für konkurrierende Bearbeitungen und Tests im Flugmodus. Bei Travl Tracker geht das bis zur vollständigen Geokodierung auf dem Gerät, ganz ohne Server.
Zugriff auf Gerätefunktionen
Kamera, Fotobibliothek, Hintergrund-Standort, Geofencing, Bluetooth Low Energy oder NFC bringen jeweils eigene Berechtigungsdialoge, Hintergrundregeln und Tests auf echten Geräten mit. Hintergrund-Standort ist der aufwendigste Posten, weil zusätzlich Energieverbrauch und Plattformregeln geprüft werden.
Gestaltungstiefe und Animationen
Eine App aus Systemkomponenten ist schnell gebaut. Ein eigenes Designsystem mit abgestimmten Übergängen, Zuständen für Laden, Leere und Fehler sowie Dunkelmodus und Schriftskalierung ist ein eigener Arbeitsstrang – sichtbar für Nutzer, aber nicht kostenlos.
Betrieb, Store-Pflege und Plattformgebühren
Enthalten sind Abhängigkeits- und SDK-Updates, Anpassung an neue Plattformversionen, Fehler-Monitoring, Store-Pflege und ein kleines Änderungsbudget. Dazu kommen die Plattformgebühren: Apple Developer Program 99 USD pro Jahr, Google Play Console einmalig 25 USD.
Native, Cross-Platform oder Web-App
Alle drei Wege sind legitim. Die Frage ist nicht, was technisch am besten ist, sondern was zu Budget, benötigten Gerätefunktionen und Lebensdauer des Produkts passt.
| Kriterium | Native pro Plattform | Cross-Platform (Flutter) | Web-App / PWA |
|---|---|---|---|
| Kosten Erstentwicklung | am höchsten, zwei getrennte Codebasen | eine Codebasis, MVP ab 25.000 € | am niedrigsten, häufig unter 15.000 € |
| Wartungsaufwand | doppelt, jedes Feature entsteht zweimal | ein Release-Zug für beide Stores | gering, aber Browser- und Geräteprüfung nötig |
| Zugriff auf Gerätefunktionen | vollständig ab dem Tag der Systemveröffentlichung | vollständig über Plugins, native Module bei Lücken | eingeschränkt, kein Hintergrund-Standort |
| Store-Präsenz | App Store und Play Store | beide Stores aus einem Projekt | keine, Installation über den Browser |
| Performance bei Animationen | Referenzwert | sehr nah an nativ durch eigenen Renderer | browserabhängig, bei aufwendigen Übergängen schwächer |
| Offline-Fähigkeit | vollständig über lokale Datenbank | vollständig über lokale Datenbank | begrenzt, Service Worker und Speicherkontingent |
| Push-Nachrichten | Standardfunktion | Standardfunktion | auf iOS erst ab 16.4 und nur für Web-Apps auf dem Home-Bildschirm |
| Time-to-Market | am längsten, zwei Entwicklungsstränge | am kürzesten für zwei Plattformen | kurz, der Store-Prozess entfällt |
Kurz: Wenn die Anwendung überwiegend Inhalte zeigt und kein Gerätezugriff nötig ist, nehmen Sie eine Web-App. Wenn die App auf beiden Plattformen laufen und Kamera, Standort oder Offline-Betrieb nutzen soll, ist Flutter fast immer die wirtschaftlichste Wahl. Rein native Entwicklung lohnt sich, wenn eine einzige Plattform reicht und die App tief in Systemfunktionen greift – so wie bei Travl Tracker, wo der Foto-Scan auf PhotoKit und SwiftData aufsetzt.
Wie wir die Plattform entscheiden
Die Entscheidung fällt im Discovery und folgt drei Fragen: Welche Gerätefunktionen braucht die App, wie viele Plattformen sollen bedient werden, und wer pflegt sie in drei Jahren. Flutter ist unsere Standardantwort für UI-lastige Apps und schnelle MVPs, weil eine Codebasis beide Stores bedient und der eigene Renderer auch aufwendige Übergänge flüssig darstellt. React Native nehmen wir, wenn im Unternehmen bereits ein React-Team arbeitet und die App später intern weiterlaufen soll.
Nativ in Swift oder Kotlin bauen wir dort, wo Cross-Platform an Grenzen stößt: tiefer Zugriff auf Systemframeworks, Hintergrundverarbeitung großer Datenmengen, Hardwareanbindung über Bluetooth Low Energy, Widgets und Systemintegrationen. Travl Tracker ist so ein Fall – die App liest die komplette Fotobibliothek über PhotoKit aus, verarbeitet sie im Hintergrund und speichert das Ergebnis in SwiftData. Ein Cross-Platform-Zwischenlayer hätte hier Aufwand erzeugt statt gespart.
Die Mischform ist der Normalfall, kein Kompromiss: Flutter für Oberfläche und Geschäftslogik, ein natives Modul für den einen Bereich, der es braucht. Diese Grenze gehört früh gezogen, weil sie den Zuschnitt des Datenmodells beeinflusst. Nachträglich lässt sich ein natives Modul einziehen, es kostet dann aber regelmäßig mehr als die ursprüngliche Entscheidung.
- Flutter als Standard für UI-lastige Apps und MVPs auf zwei Plattformen
- React Native, wenn ein bestehendes React-Team die App später übernimmt
- Swift oder Kotlin für Systemframeworks, Hintergrundarbeit und Hardwarezugriff
- Native Module gezielt einzeln, nicht als vollständige zweite Codebasis
- Plattformgrenze im Discovery festlegen, nicht während der Entwicklung
Offline-Betrieb und Daten auf dem Gerät
Mobile Anwendungen laufen nicht im Büro-WLAN, sondern im Tunnel, im Keller und in Regionen ohne verlässliches Netz. Offline-Fähigkeit ist deshalb eine Architekturentscheidung am Anfang, keine Funktion am Ende. Konkret: ein lokales Datenmodell als führende Quelle für die Anzeige, eine Warteschlange für noch nicht übertragene Änderungen und eine explizite Regel, was passiert, wenn dieselbe Information auf zwei Geräten geändert wurde.
Die Silk Road Rally App zeigt, warum das keine akademische Frage ist. Auf rund 15.000 Kilometern entlang der Seidenstraße liegen ganze Etappen außerhalb der Netzabdeckung. Das Roadbook mit Streckenverlauf, Checkpoints und Etappenhinweisen ist deshalb lokal verfügbar; Positionen, Quest-Ergebnisse und Feed-Beiträge werden nachgereicht, sobald wieder Verbindung besteht.
Travl Tracker treibt das Prinzip auf die Spitze: Dort verlässt überhaupt nichts das Gerät. Die Umkehr-Geokodierung läuft vollständig offline – Länder über den Natural-Earth-Datensatz per Point-in-Polygon-Test, Städte über GeoNames mit Suche nach dem nächstgelegenen Ort. Kein Konto, kein Server, keine Übertragung von Koordinaten an Dritte. Das spart Betriebs- und Abfragekosten und macht das Datenschutzversprechen technisch überprüfbar statt nur behauptet.
- Lokales Datenmodell als Anzeigequelle, Server als Abgleichspartner
- Warteschlange für nicht übertragene Änderungen mit Wiederaufnahme
- Explizite Regel für konkurrierende Bearbeitungen, nicht „zuletzt gewinnt“ per Zufall
- Tests im Flugmodus und bei absichtlich gedrosselter Verbindung
- Wenn möglich: Verarbeitung auf dem Gerät statt Übertragung an einen Dienst
Was der Store-Release wirklich verlangt
Der Weg in die Stores ist ein eigener Projektschritt mit eigenen Regeln und der häufigste Grund für Verzögerungen kurz vor dem Ziel. Zu erledigen sind Entwicklerkonten, Zertifikate und Bereitstellungsprofile, Signierung, das Store-Listing mit Name, Untertitel, Beschreibung und Schlüsselwörtern, Screenshots in den geforderten Geräteformaten, Altersfreigabe, eine erreichbare Datenschutzerklärung und die Angaben zur Datennutzung.
Die Datenschutzangaben sind kein Formular zum Abhaken. Apple verlangt unter App Privacy Details und Google unter Data Safety eine Erklärung, welche Daten erhoben, wofür sie verwendet und ob sie mit Dritten geteilt werden – einschließlich der Daten, die eingebundene SDKs für Analyse oder Absturzberichte sammeln. Eine falsche Angabe ist ein Ablehnungsgrund, und jede Ablehnung startet den Prüfzyklus neu.
Zur Planung: Apple gibt an, dass die Mehrheit der Einreichungen innerhalb von 24 Stunden geprüft wird. Wir kalkulieren trotzdem ein bis zwei Wochen, weil Rückfragen und ein zweiter Durchlauf realistisch sind. Vorher verteilen wir Builds über TestFlight und Google Play Internal Testing an einen definierten Testkreis, damit Fehler nicht über Store-Bewertungen zurückkommen. Sind Erlöse über die App geplant, melden wir vor dem ersten Verkauf das App Store Small Business Program an, das die Provision unterhalb der Umsatzschwelle auf 15 % statt 30 % senkt.
- Entwicklerkonten, Zertifikate und Signierung früh klären, nicht in der Release-Woche
- Datenflüsse und eingebundene SDKs vor der ersten Einreichung inventarisieren
- Testverteilung über TestFlight und Play Internal Testing vor jedem Release
- Ein bis zwei Wochen Puffer für Prüfung, Rückfragen und einen zweiten Durchlauf
- Store-Listing als Teil des Angebots, nicht als Zusatzleistung nach dem Launch
Backend, Push und Synchronisation aus derselben Hand
Eine App ohne Server ist die Ausnahme. Sobald Inhalte gepflegt, Nutzer angemeldet, Daten zwischen Geräten geteilt oder Push-Nachrichten ausgelöst werden, gehört ein Backend dazu: Datenmodell, REST- oder GraphQL-Schnittstelle, Authentifizierung, Rechteprüfung, Protokollierung, Monitoring. Wir liefern diesen Teil selbst, statt ihn zu vergeben – weil die Abstimmung zwischen App und Schnittstelle sonst zum eigentlichen Projektrisiko wird.
Die Umsetzung entscheidet der Anwendungsfall. Für schlanke MVPs reicht oft eine verwaltete Plattform mit Authentifizierung, Datenbank und Push, was mehrere Wochen Einrichtung spart. Für eigene Fachlogik, Anbindung an Bestandssysteme oder Anforderungen an den Speicherort der Daten bauen wir ein eigenes Backend – die zugehörigen Schnittstellen und Integrationen beschreiben wir unter /softwareentwicklung.
Push-Nachrichten sind der am häufigsten unterschätzte Posten. Es braucht Schlüssel und Zertifikate je Plattform, eine Verwaltung der Gerätetoken samt abgelaufener Einträge, eine Einwilligungslogik, Segmentierung der Empfänger und die Abgrenzung zwischen stillen Hintergrundmeldungen und sichtbaren Hinweisen. Ohne diese Arbeit gibt es entweder keine Zustellung oder zu viele Meldungen – und dann schaltet der Nutzer sie dauerhaft ab.
Zusammenarbeit, Übergabe und Wartung
Sie sprechen von der ersten Anfrage bis zum Betrieb mit derselben Person; es gibt keinen Projektmanager, der zwischen Ihnen und dem Entwickler übersetzt. Für größere Vorhaben skalieren wir über ein Partnernetzwerk, unter anderem die Runourcode GmbH in Langenzenn – Architektur, Qualitätssicherung und Verantwortung bleiben bei Hirnworx: David De Matteo, Ziegelstraße 2, 90579 Langenzenn bei Nürnberg, tätig seit 2011 mit über 350 Projekten.
Abgerechnet wird zum Festpreis nach Scope-Workshop, in Etappen, die an sichtbare Zwischenstände gekoppelt sind. Jeder Sprint endet mit einem installierbaren Build in TestFlight oder Google Play Internal Testing – Sie prüfen die App auf Ihrem eigenen Gerät, statt einen Statusbericht zu lesen. Änderungswünsche außerhalb des Umfangs bekommen ein eigenes kleines Angebot; alternativ rechnen wir Erweiterungen mit 120 €/h ab.
Am Ende erhalten Sie Repository, Deployment-Pipeline und eine Übergabedokumentation mit Zugängen, Signierungsschlüsseln und Release-Ablauf. Der Stack ist Standard – Flutter und Dart, Swift, Kotlin – kein Hirnworx-Eigenbau. Der Betrieb beginnt bei 450 € monatlich und umfasst SDK- und Abhängigkeits-Updates, Anpassung an neue Plattformversionen, Fehler-Monitoring, Store-Pflege und ein kleines Änderungsbudget. An dieser Position wird am häufigsten gespart – mit dem absehbaren Ergebnis, dass nach zwei bis drei Jahren ein Neubau statt eines Updates ansteht.
- Ein Ansprechpartner über die gesamte Laufzeit, Skalierung über das Partnernetzwerk
- Festpreis in Etappen, jeder Sprint endet mit einem installierbaren Build
- Übergabe mit Repository, Pipeline, Schlüsseln und Dokumentation
- Betrieb ab 450 €/Monat, zuzüglich 99 USD pro Jahr für das Apple Developer Program
Projekte, die Sie ansehen können
Travl Tracker — iOS App
Native SwiftUI-App, die aus der Fotobibliothek automatisch besuchte Länder & Städte erkennt — komple…
Silk Road Rally — iOS App
Begleit-App der Silk Road Rally: Live-Etappen-Tracking auf der Karte, Geofence-Quests mit Foto-Nachw…
Ablauf eines App-Entwicklung-Projekts
Vier Etappen mit Dauerangabe und einem Ergebnis pro Etappe. Von der Beauftragung bis zur veröffentlichten App liegt eine Cross-Platform-App typisch bei 14 bis 20 Wochen, ein schlanker MVP bei 8 bis 12 Wochen – gerechnet ab geklärtem Umfang und vorliegenden Inhalten.
- 011–2 Wochen
Discovery & Scope
User Stories, Nutzergruppen und messbares Ziel klären, MVP-Umfang schneiden, Plattform- und Backend-Entscheidung treffen. Bestehende Schnittstellen und Datenquellen werden dabei geprüft, nicht angenommen.
Ergebnis: Scope-Dokument mit User Stories, Plattformentscheidung und Festpreis
- 022–3 Wochen
UX/UI & Prototyp
Flows, Navigationsmodell und Designsystem inklusive Zuständen für Laden, Leere und Fehler. Ergebnis ist ein klickbarer Prototyp, an dem sich der Umfang vor der Entwicklung korrigieren lässt.
Ergebnis: Designsystem und klickbarer Prototyp aller Kernflows
- 036–12 Wochen
Sprint-Entwicklung mit Testverteilung
Umsetzung in Sprints, am Ende jedes Sprints ein installierbarer Build über TestFlight und Google Play Internal Testing. Tests auf echten Geräten mehrerer Jahrgänge, inklusive Flugmodus und gedrosselter Verbindung.
Ergebnis: Abnahmefähige Builds im Testkanal beider Plattformen
- 041–2 Wochen, danach laufend
Store-Release & Wartung
Store-Listing, Screenshots, Datenschutzangaben, Altersfreigabe und Einreichung bei Apple und Google. Danach Betrieb mit SDK-Updates, Anpassung an neue Plattformversionen und Fehler-Monitoring.
Ergebnis: Veröffentlichte App, Repository, Signierungsschlüssel und Übergabedokumentation
Förderung für Digitalisierungsvorhaben in Bayern
Für bayerische Unternehmen mit weniger als 50 Beschäftigten kann der Digitalbonus einen Teil der Kosten abdecken. Entscheidend ist die Reihenfolge.
Digitalbonus Bayern (Standard)
bis 7.500 €Bayern · unter 50 Beschäftigte
Zuschuss von bis zu 50 % der förderfähigen Ausgaben für Digitalisierungsvorhaben — etwa Einführung oder Verbesserung digitaler Produkte, Dienstleistungen und Prozesse. Antragsberechtigt sind bayerische Unternehmen mit weniger als 50 Beschäftigten und höchstens 10 Mio. € Umsatz oder Bilanzsumme. Laufzeit des Programms bis 31.12.2027.
Programm beim Fördergeber →Digitalbonus Bayern Plus
bis 30.000 €Bayern · besonderer Innovationsgehalt
Für Vorhaben mit nachgewiesenem Innovationsgehalt, ebenfalls bis zu 50 % Fördersatz. Der Neuheitsgrad muss im Antrag detailliert beschrieben werden; in Grenzfällen entscheidet ein Expertengremium der Bezirksregierung. Plus ist während der Programmlaufzeit nur einmal möglich und nicht mit dem Standard für dieselbe Maßnahme kombinierbar.
Programm beim Fördergeber →Stand: September 2026. Über Bewilligung, Höhe und Bedingungen entscheidet allein die Förderstelle — wir liefern die technische Leistungsbeschreibung und das Angebot für den Antrag, keine Förderberatung.
App-Entwicklung — Begriffe kurz erklärt
Die Begriffe, die in Angeboten und Gesprächen ständig vorkommen und selten erklärt werden.
- MVP (Minimum Viable Product)
- Erste marktfähige Version mit genau den Funktionen, die die zentrale Annahme überprüfbar machen. Ziel ist nicht eine reduzierte App, sondern eine vollständige Antwort auf eine einzige Frage – bei uns typisch im Bereich von 25.000 bis 45.000 €.
- Cross-Platform-Framework
- Technologie, mit der iOS und Android aus einer gemeinsamen Codebasis bedient werden, etwa Flutter oder React Native. Plattformspezifische Anpassungen bleiben möglich, entfallen aber für den Großteil von Oberfläche und Geschäftslogik.
- TestFlight und Internal Testing
- Die Testverteilungskanäle von Apple und Google. Builds gehen vor der Veröffentlichung an einen definierten Kreis von Testerinnen und Testern, die die App auf ihren eigenen Geräten installieren und Rückmeldungen geben.
- Deployment Target
- Die niedrigste Systemversion, auf der eine App läuft. Ein höheres Ziel reduziert Test- und Entwicklungsaufwand, schließt aber ältere Geräte aus. Travl Tracker setzt beispielsweise iOS 17 als Untergrenze.
- Privacy Details und Data Safety
- Pflichtangaben beider Stores darüber, welche Daten eine App erhebt, wofür sie genutzt und ob sie mit Dritten geteilt werden – einschließlich der Daten eingebundener SDKs. Sie müssen vor der Veröffentlichung vollständig und zutreffend ausgefüllt sein.
- Offline-First
- Architekturprinzip, bei dem die lokale Datenhaltung die führende Quelle für die Anzeige ist und der Server nur abgleicht. Änderungen werden lokal gespeichert, in einer Warteschlange gehalten und nach Wiederherstellung der Verbindung übertragen.
App-Entwicklung nach Branche
Service×Branche — eine getrennte Achse von Service×Stadt, ohne kombinierte URLs.
Alle Branchen →App-Entwicklung nach Stadt
Stadt-Landingpages mit lokalem Marktkontext, branchenspezifischen Leistungen und echten Referenzen. Sitz ist und bleibt Langenzenn — Entfernung und Servicegebiet stehen auf jeder Seite.
Alle Standorte →App-Entwicklung — häufige Fragen
Kosten & Förderung
Ein MVP mit Kernfunktionen liegt bei 25.000 bis 45.000 €, eine vollständige Cross-Platform-App für iOS und Android mit Backend und Push bei 60.000 bis 120.000 €, Enterprise- und IoT-Vorhaben mit nativen Modulen, Compliance und Servicezeiten bei 100.000 bis 250.000 €. Alle Werte netto und unverbindlich, Stand: September 2026. Den verbindlichen Festpreis nennen wir nach dem Scope-Workshop. Die Aufschlüsselung steht unter /kosten/app-entwicklung.
Technik & Plattformen
Ablauf & Store
Bereit für Ihr Projekt?
Beschreiben Sie Ziel und Rahmen — Sie bekommen eine Einschätzung zu Umfang, Dauer und Budget, bevor irgendetwas beauftragt wird.
Projekt anfragen →