App entwickeln lassen: Native, Cross-Platform oder Web-App?

Muss es überhaupt eine App sein?

Eine App ist die aufwendigste Art, Menschen eine digitale Funktion bereitzustellen. Sie wird über App Store oder Google Play verteilt, muss geprüft werden und wird bei jeder Betriebssystem-Generation angepasst. Fragen Sie deshalb zuerst, was eine App leistet, das eine Webanwendung nicht kann.

Für eine App sprechen typischerweise:

• Zugriff auf Kamera, Bluetooth, NFC, Sensoren oder Hintergrunddienste,
• Betrieb ohne Netz (Offline) mit späterem Abgleich,
• Push-Benachrichtigungen mit hoher Zuverlässigkeit,
• eine erwartete Präsenz im Store, etwa für Endkunden.

Typische Beispiele (illustrativ): eine Servicetechniker-App mit Offline-Auftragsliste und Fotoerfassung, eine Mitglieder-App eines Verbands, eine Scan-Anwendung im Lager.

Native, Cross-Platform oder Web-App

Entscheidungstabelle nach Kriterien

Bei Cross-Platform-Frameworks sparen Sie häufig Aufwand, aber nicht automatisch Wartung: Auch Flutter oder React Native erhalten regelmäßig Updates, die in Ihre App einfließen müssen.

Die Tabellen zeigen typische Tendenzen, keine Regeln. Entscheidend ist Ihr konkreter Funktionsumfang. Lassen Sie sich vom Dienstleister begründen, warum er eine Technik empfiehlt, und fragen Sie nach den Grenzen für Ihre wichtigsten Funktionen.

Entwicklerkonten und Stores

Zur Veröffentlichung brauchen Sie Entwicklerkonten bei den Plattformbetreibern. Die Gebühren wurden am 9. November 2026 auf den offiziellen Seiten geprüft:

• Apple Developer Program: 99 US-Dollar pro Jahr; Preise können regional abweichen und werden bei der Anmeldung in Landeswährung angezeigt. Für Organisationen verlangt Apple eine D-U-N-S-Nummer, eine rechtsfähige Organisation und eine öffentlich erreichbare Website.
• Google Play: einmalige Registrierungsgebühr von 25 US-Dollar. Für neue persönliche Konten nennt Google zusätzliche Test- und Verifizierungsanforderungen vor der Veröffentlichung.

Wichtig ist die Frage, wem die Konten gehören. Registrieren Sie sie auf Ihr Unternehmen und geben Sie dem Dienstleister Rollen darin. Dann bleiben App, Bewertungen und Nutzer bei einem Anbieterwechsel bei Ihnen. Beide Stores prüfen Apps vor der Veröffentlichung; planen Sie Zeit für Rückfragen und Nachbesserungen ein, ohne feste Dauer zu unterstellen.

Release-Prozess: Testen, Prüfung, gestufte Auslieferung

Bevor eine App im Store erscheint, durchläuft sie typischerweise diese Stationen:

• Interne Tests: Bei Apple über TestFlight, bei Google Play über den internen Testtrack. TestFlight erlaubt laut Apple bis zu 100 interne Tester aus Ihrem Entwicklerteam; Google nennt für den internen Test ebenfalls bis zu 100 ausgewählte Tester.
• Externe Tests: Bei TestFlight sind bis zu 10.000 externe Tester möglich, die erste Version muss dafür von der App-Prüfung freigegeben werden. Bei Google gibt es geschlossene Tests mit ausgewählten Personen und offene Tests, denen jeder Nutzer über den Store-Eintrag beitreten kann.
• Prüfung: Apple und Google prüfen die App vor der Veröffentlichung. Planen Sie Puffer für Rückfragen oder Ablehnungen ein; Dauer und Ergebnis lassen sich nicht zusagen.
• Gestufte Auslieferung: Bei Updates bestehender Apps können Sie bei Google Play einen Prozentsatz der Nutzer wählen, der das Update zuerst erhält. Für die Erstveröffentlichung ist das laut Google nicht möglich. Eine neue Version kann erst veröffentlicht werden, wenn eine gestufte vorherige vollständig ausgerollt ist.

Fragen Sie den Dienstleister, wie Testversionen bereitgestellt werden und wer bei Ihnen die Testgruppe stellt. Ein Test mit echten Anwendern auf echten Geräten findet Fehler, die Entwickler am eigenen Gerät nicht sehen.

Was Sie für den Store-Start brauchen

• Entwicklerkonten bei Apple und Google auf Ihr Unternehmen, mit Rollen für den Dienstleister
• D-U-N-S-Nummer, falls Sie sich als Organisation bei Apple anmelden
• Öffentlich erreichbare Datenschutzerklärung mit Verlinkung im Store-Eintrag (bei Apple ist eine URL Pflicht, bei Google wird die Verlinkung ebenfalls verlangt)
• App-Datenschutzangaben bei Apple (Privacy Details in App Store Connect): welche Daten erhoben werden, wofür, ob sie dem Nutzer zugeordnet werden und ob Tracking stattfindet
• Data-Safety-Formular bei Google Play: Erhebung, Weitergabe, Verschlüsselung bei der Übertragung, Löschmöglichkeit; auch Daten von eingebundenen Drittanbieter-Bibliotheken zählen mit
• Screenshots, Beschreibung, Icon und Kontaktangaben für beide Stores
• Support-Kontakt und Verantwortliche für Nutzerbewertungen

Die Datenschutzangaben müssen zur tatsächlichen Datenverarbeitung der App passen; falsche Angaben können zu Beanstandungen führen. Klären Sie sie mit Ihrer Datenschutzbeauftragten oder Ihrem Datenschutzbeauftragten.

Backend, Offline und Push

Die meisten Apps sind nur die Oberfläche. Dahinter liegt ein Backend mit Datenhaltung, Benutzerverwaltung und Schnittstellen. Es verursacht Kosten für Entwicklung, Hosting und Betrieb, und es gelten dieselben Anforderungen an Sicherheit und Datenschutz wie bei einer Webanwendung. Eine Schnittstelle zu Ihren bestehenden Systemen beschreibt die Seite Schnittstellen und Integration.

• Offline: Sobald Daten ohne Netz bearbeitet werden, braucht die App Regeln für den Abgleich und für Konflikte, etwa wenn zwei Personen dieselben Daten ändern. Das ist einer der größten Aufwandstreiber.
• Push: Benachrichtigungen laufen über die Dienste von Apple und Google. Klären Sie, welche Inhalte versendet werden und ob dabei personenbezogene Daten betroffen sind.
• Sicherheit: Auch für mobile Anwendungen ist fehlerhafte Zugriffskontrolle ein bekanntes Risiko; die OWASP-Top-10-Ausgabe 2025 führt sie für Webanwendungen an erster Stelle.

Was Sie als Auftraggeber liefern

• ein klares Ziel und eine Liste der wichtigsten Abläufe,
• die Zielgeräte und Betriebssystemversionen, die unterstützt werden sollen,
• Corporate Design und Texte,
• Zugang zu Systemen und Daten, die angebunden werden,
• einen Ansprechpartner für Fachfragen und für Tests auf echten Geräten.

Sammeln Sie diese Angaben mit Projekt vorbereiten und halten Sie sie in einem Lastenheft fest.

Projektphasen

1. Konzept und Prototyp: Abläufe klären, Klick-Modell testen, Technik festlegen.
2. Umsetzung in Abschnitten: App und Backend gemeinsam, mit regelmäßigen Testversionen auf echten Geräten.
3. Test: Gerätevielfalt, schwache Netze, Berechtigungen, Datenschutz.
4. Veröffentlichung: Store-Einträge, Prüfung, Datenschutzangaben.
5. Betrieb: Monitoring, Fehlerbehebung, Updates.

Betrieb und Wartung

Jährliche Pflege durch neue Betriebssystemversionen

Die großen Plattformen bringen in der Regel jedes Jahr neue Hauptversionen ihrer Betriebssysteme. Für Ihre App bedeutet das jährlich wiederkehrende Aufgaben: Testen auf der neuen Version, Anpassung an geänderte Systemfunktionen oder Berechtigungen, Aktualisierung von Bibliotheken und eine neue Veröffentlichung. Der Aufwand schwankt je nach Jahr und App-Komplexität; eine feste Größenordnung lässt sich ohne Kenntnis Ihrer App nicht nennen. Vereinbaren Sie deshalb ein laufendes Wartungsbudget oder Stundenkontingent, statt Wartung bei Bedarf neu auszuhandeln, und klären Sie, wer die Einhaltung neuer Store-Vorgaben überwacht.

Zwei Gründe machen Wartung bei Apps unvermeidlich: Betriebssysteme ändern sich regelmäßig, und die Stores setzen neue Anforderungen. Eine App, die nicht gepflegt wird, kann nach einem Systemupdate Fehler zeigen oder aus dem Store entfernt werden. Planen Sie daher dauerhaft Budget und Verantwortlichkeiten ein: Wer testet neue Betriebssystemversionen, wer veröffentlicht Updates, wer beantwortet Nutzerbewertungen und Support?

Kostentreiber

Verlässliche Preise ohne Kenntnis Ihres Vorhabens gibt es nicht. Die wichtigsten Treiber sind:

• Zahl der Plattformen und Gerätetypen,
• Offline-Fähigkeit und Synchronisation,
• Umfang des Backends und der Schnittstellen,
• Gerätefunktionen (Kamera, Scanner, Bluetooth),
• Gestaltung und Barrierefreiheit,
• laufende Kosten: Entwicklerkonten, Hosting, Wartung, Support.

Eine Einordnung finden Sie im Ratgeber Was kostet Individualsoftware. Was eine App kostet, lässt sich ohne Anforderungen nicht seriös beantworten; wer sofort einen Festpreis nennt, hat meist wichtige Fragen nicht gestellt.

Warnzeichen im Angebot

• Entwicklerkonten laufen auf den Namen des Anbieters.
• Keine Aussage zu Wartung nach der Veröffentlichung.
• Kein Backend im Angebot, obwohl die App Daten speichert.
• Technik wird festgelegt, ohne Alternativen zu nennen.
• Quellcode und Dokumentation sind nicht Teil der Lieferung.
• Keine Regelung zu Nutzungsrechten (siehe Individualsoftware).

Hilfreiche Fragen für den Vergleich enthält der Ratgeber Softwaredienstleister auswählen. Ob der Dienstleister in Heidelberg sitzt oder remote arbeitet, ist dabei weniger wichtig als nachweisbare Erfahrung mit Apps im Store-Betrieb.

Nächster Schritt

Prüfen Sie zuerst, ob eine Web-App genügt: Die Seite Webanwendungen beschreibt die Alternative. Wenn eine App nötig ist, halten Sie Funktionen, Geräte und Offline-Anforderungen mit dem Werkzeug Projekt vorbereiten fest.