StartseiteServicesiOS-App-Entwicklung
Native iOS-App-Entwicklung mit Swift und SwiftUI
iOS-App-Entwicklung umfasst Konzeption, Entwicklung und Veröffentlichung von Apps für iPhone, iPad und Apple Watch, nativ geschrieben in Swift und SwiftUI und über den App Store verteilt. Woltrio entwickelt iOS-Apps für Healthcare-Unternehmen, Start-ups und Konzerne und berücksichtigt HealthKit, Push-Benachrichtigungen, Offline-Synchronisierung und die Datenschutzvorgaben des App Store ab dem ersten Sprint.
Was wir entwickeln für iPhone, iPad und Apple Watch
Diese fünf App-Typen teilen dieselbe native Grundlage: Swift, SwiftUI, Apples Datenschutzregeln und das App Review. Unterschiedlich sind die Daten, die Verteilung und das Erlösmodell.
Healthcare- und mHealth-Apps
Gesundheits-Apps unter iOS lesen und schreiben häufig HealthKit-Daten wie Schritte, Herzfrequenz oder Schlaf. HealthKit fragt die Berechtigung je Datentyp ab, und eine App kann nicht erkennen, ob jemand den Lesezugriff verweigert hat. Apples Regeln verbieten, HealthKit-Daten für Werbung zu nutzen, sie an Datenhändler zu verkaufen oder personenbezogene Gesundheitsdaten in iCloud zu speichern. Für Forschungs- und Versorgungsprogramme bietet Apple ResearchKit und CareKit, und HealthKit kann FHIR-Behandlungsdaten lesen, die Nutzer bei unterstützten Einrichtungen abrufen. Datenschutzerklärung, Nutzungsbeschreibungen und Einwilligungsabläufe bereiten wir so vor, wie das App Review sie erwartet.
HealthKit-Berechtigungen · Keine PHI in iCloud · Klinische Daten (FHIR) · ResearchKit und CareKit
Telemedizin- und Patienten-Apps
Patienten-Apps bündeln Terminbuchung, sichere Nachrichten, Videosprechstunden, Anamnesebögen und Erinnerungen. Unter iOS heißt das: Kamera- und Mikrofonberechtigungen mit klaren Begründungen, APNs-Benachrichtigungen ohne PHI auf dem Sperrbildschirm und Anmeldung per Face ID oder Code über die Systemframeworks. Video läuft über einen Anbieter Ihrer Wahl oder einen eigenen WebRTC-Stack, mit einem Backend, für das ein BAA unterzeichnet ist. Wir binden die App über FHIR-APIs an Ihr EHR oder Portal an und speichern Besuchsdaten nur dann auf dem Gerät, wenn es nötig ist.
Videosprechstunde · Push ohne PHI · Anmeldung per Face ID · EHR über FHIR
Enterprise- und B2B-Apps
Interne und B2B-Apps unterstützen Außendienst, Vertrieb, medizinisches Personal oder Lagerteams. Meist brauchen sie Single Sign-on über Ihren Identity Provider, Offline-Arbeit mit späterer Synchronisierung, Barcode- oder Dokumentenscan und die Verteilung über Mobile Device Management. Mit Apples Custom-App-Verteilung ist eine freigegebene App nur für die Organisationen sichtbar, die Sie benennen; diese verteilen sie per MDM oder Einlösecodes. Auch Custom Apps durchlaufen das App Review, deshalb stellen wir Demo-Zugänge und Beispieldaten bereit. Rollenrechte und Audit-Logs liegen im Backend, nicht nur in der App.
Single Sign-on · Offline im Außendienst · Custom-App-Verteilung · MDM-Rollout
Consumer- und Abo-Apps
Bei Consumer-Apps entscheiden Onboarding, Performance und Bindung. Nach App Store Review Guideline 3.1.1 erfordert das Freischalten digitaler Funktionen oder Inhalte grundsätzlich In-App-Kauf; deshalb bauen wir Abos mit StoreKit, prüfen Transaktionen auf Ihrem Server und behandeln Verlängerungen, Erstattungen und Kulanzzeiträume. Für einzelne Storefronts gibt es Ausnahmen, daher prüfen wir die aktuelle Richtlinie, bevor Sie ein Zahlungsmodell festlegen. Wer für das Hauptkonto einen Social Login eines Drittanbieters anbietet, braucht nach Guideline 4.8 eine gleichwertige datenschutzfreundliche Login-Option. Analytics richten wir so ein, dass Datenschutzangaben und ATT-Abfrage zur tatsächlichen Datenerhebung passen.
StoreKit-Abos · Guideline 3.1.1 · Datenschutzfreundlicher Login · Bindungsanalyse
Apple-Watch- und iPad-Apps
Apple-Watch-Apps eignen sich für kurze Aufgaben: Medikamentenerinnerungen, Trainingsaufzeichnung, Warnungen und schnelle Antworten. Trainingssitzungen auf der Watch stimmen die Sensoren auf die gewählte Aktivität ab und erfassen Herzfrequenzwerte in hoher Frequenz; die App muss klar anzeigen, wann eine Sitzung läuft, und das Speichern oder Verwerfen ermöglichen. iPad-Apps brauchen Layouts für den größeren Bildschirm, Tastatur- und Zeigerunterstützung und oft Apple Pencil für Formulare, Unterschriften oder Anmerkungen. Mit SwiftUI teilen iPhone, iPad und Apple Watch Modelle und Logik, während jedes Gerät seine eigene Oberfläche behält.
watchOS-Trainings · Komplikationen und Hinweise · iPad-Layouts · Apple-Pencil-Eingabe
Die Bausteine einer produktiven iOS-App
Jede iOS-App, die wir ausliefern, besteht aus denselben sechs Bausteinen, zugeschnitten auf Ihr Produkt.
SwiftUI-Oberfläche und Designsystem
Wir gestalten die Screens in Figma und setzen sie in SwiftUI mit einer gemeinsamen Komponentenbibliothek um, von Anfang an mit Dynamic Type, Dark Mode und VoiceOver-Beschriftungen. UIKit ergänzt dort, wo SwiftUI noch nicht ausreicht, etwa bei komplexer Texteingabe oder Kameraansichten.
Learn moreOffline-Daten und Synchronisierung
SwiftData oder Core Data hält eine lokale Kopie der benötigten Daten, sodass die App auch ohne Netz startet und funktioniert. Änderungen werden auf dem Gerät gesammelt und bei Verbindung mit Ihrem Server abgeglichen, mit klaren Konfliktregeln und ohne sensible Daten länger als nötig zu speichern.
Backend und APIs
Die meisten Apps brauchen ein Backend für Konten, Geschäftslogik, Dateien und Integrationen. Wir entwickeln REST- oder GraphQL-APIs mit Authentifizierung, Rate Limiting und Audit-Logs, gehostet in einer Cloud-Region Ihrer Wahl und für Gesundheitsdaten auf Infrastruktur mit BAA.
Learn morePush-Benachrichtigungen mit APNs
Die App registriert sich beim Apple Push Notification service, erhält bei jedem Start ein Geräte-Token und übermittelt es verschlüsselt an Ihren Server. Wir berücksichtigen mehrere Geräte pro Nutzer, neue Tokens nach Wiederherstellungen, Kategorien und Ruhezeiten und halten PHI aus den Payloads heraus.
Datenschutz und App-Store-Vorgaben
Wir pflegen das Privacy Manifest (PrivacyInfo.xcprivacy) mit erhobenen Datentypen und Required-Reason-APIs, prüfen jedes Drittanbieter-SDK gegen Apples Liste der SDKs mit Manifest- und Signaturpflicht und füllen die App-Datenschutzangaben so aus, dass das Label im App Store zum Code passt.
Tests und Veröffentlichung
Unit- und UI-Tests laufen bei jedem Pull Request in der CI. Builds gehen per TestFlight an interne Tester und, sobald Apple den ersten Build geprüft hat, an externe Tester. Wir erstellen App-Store-Texte, Screenshots, Hinweise für das Review und Demo-Zugänge und übernehmen Einreichung und Updates.
Cross-Platform vs. natives iOS
Wann natives iOS die richtige Wahl ist
Cross-Platform-Frameworks wie Flutter und React Native sind für viele Apps eine gute Wahl, besonders wenn iOS und Android gleich wichtig sind und das Budget knapp ist. Natives Swift lohnt sich, wenn die App auf HealthKit, Apple Watch, Widgets oder neue Apple-APIs angewiesen ist, wenn Ihre Zielgruppe vor allem iPhone nutzt oder wenn Plattformgefühl und Barrierefreiheit zentral sind.
Eine App für iOS und Android
Off-the-Shelf
Eine gemeinsame Codebasis für beide Plattformen. Meist schneller und günstiger, wenn beide Zielgruppen gleich wichtig sind.
Custom-Built with Woltrio
Eigene Swift-Codebasis. Android entsteht parallel oder später nativ durch ein Kotlin-Team mit demselben Backend und denselben APIs.
HealthKit, Apple Watch und Widgets
Off-the-Shelf
Über Plugins oder native Module möglich, Watch-Apps und Widgets brauchen aber meist trotzdem Swift-Code.
Custom-Built with Woltrio
Direkter Zugriff auf HealthKit, watchOS, Widgets und Live Activities ohne Brückenschicht.
Neue Apple-APIs
Off-the-Shelf
Verfügbar, sobald Framework oder Plugin sie unterstützen, oder über eigenen nativen Code.
Custom-Built with Woltrio
Nutzbar, sobald Apple sie im SDK bereitstellt.
Budget und Markteinführung
Off-the-Shelf
Geringere Gesamtkosten, wenn Sie auf beiden Plattformen gleichzeitig starten.
Custom-Built with Woltrio
Effizient für einen iOS-first-Start; eine zweite native App kostet später zusätzlich.
Plattformgefühl und Barrierefreiheit
Off-the-Shelf
Für die meisten Business-Apps gut; manches Systemverhalten erfordert Zusatzaufwand.
Custom-Built with Woltrio
Systemelemente, VoiceOver, Dynamic Type und Gesten verhalten sich genau so, wie iOS-Nutzer es erwarten.
Wir entwickeln beides und empfehlen die Variante, die zu Ihren Nutzern, Ihrer Roadmap und Ihrem Budget passt.
Ab dem ersten Release integriert
Vier Dinge, die jede iOS-App von uns enthält, unabhängig von ihrer Kategorie.
Tokens und Schlüssel liegen im Schlüsselbund, die Anmeldung unterstützt Face ID und Touch ID über die Systemframeworks, und der gesamte Datenverkehr läuft über TLS. Gesundheits-Apps werden mit HIPAA-Schutzmaßnahmen konzipiert. Woltrio ist nach ISO/IEC 27001:2022 zertifiziert, und wir unterzeichnen mit Healthcare-Kunden ein BAA, bevor PHI geteilt werden.
Wie wir iOS-Projekte angehen
Sorgfalt auf Healthcare-Niveau für jede App, ob sie PHI verarbeitet oder nicht.
App Review von Anfang an eingeplant
Wir lesen die relevanten App Store Review Guidelines, bevor das Design beginnt: Gesundheitsdaten, Zahlungen, Login, Kontolöschung und Datenschutz. Hinweise für das Review, Demo-Zugänge und das Datenschutz-Label gehören zum Plan und entstehen nicht erst in der Woche vor dem Launch.
Datenschutz in der Architektur
Bevor wir Code schreiben, klären wir, welche Daten die App erhebt, wo sie gespeichert werden und wer sie erhält. Gesundheitsdaten bleiben aus iCloud und Werbe-Tools heraus, PHI aus Push-Payloads und Logs, und jedes SDK wird auf sein Privacy Manifest geprüft.
Ein Team von Design bis Backend
Designer, iOS-Entwickler, Backend-Entwickler und QA arbeiten in denselben Sprints. Sie erhalten in jedem Sprint einen TestFlight-Build und geben Feedback auf echten Geräten. Dasselbe Team kann später Android oder ein Webportal ergänzen, ganz ohne Übergabe.
Von der Idee in den App Store
- 01
Discovery und Plattformentscheidung
Wir klären Nutzer, Kernfunktionen, Datenflüsse und regulatorischen Rahmen und empfehlen natives iOS, Cross-Platform oder beides, mit einem abgegrenzten ersten Release und einer Schätzung.
- 02
UX-Design und Prototyp
Wir gestalten die wichtigsten Abläufe nach Apples Human Interface Guidelines und testen einen klickbaren Prototyp mit echten Nutzern, bevor die Entwicklung beginnt.
- 03
Entwicklung in Sprints
Zweiwöchige Sprints liefern funktionierende Features in Swift und SwiftUI, mit automatisierten Tests und einem neuen TestFlight-Build für Ihre eigenen Geräte.
- 04
Datenschutz, Sicherheit und Review-Vorbereitung
Wir finalisieren Privacy Manifest, App-Datenschutzangaben, Berechtigungstexte und Review-Hinweise, führen Sicherheits- und Barrierefreiheitsprüfungen durch und öffnen den externen TestFlight-Test.
- 05
Launch und laufender Support
Wir reichen die App im App Store ein, beantworten Rückfragen des Reviews, überwachen Abstürze nach dem Release und halten die App mit jeder iOS-Version und Richtlinienänderung aktuell.
Häufig
gestellte Fragen
Sie suchen Basisinfos? In unseren FAQs finden Sie präzise Antworten auf die wahrscheinlichsten Fragen.
Wann sollten wir eine native iOS-App statt einer Cross-Platform-App entwickeln?
Welche Regeln gelten bei Apple für HealthKit-Daten?
Muss eine Gesundheits-App unter iOS HIPAA erfüllen?
Welche Datenschutzangaben verlangt der App Store?
Wie funktioniert der Betatest vor dem Launch einer iOS-App?
Kann eine iOS-App offline arbeiten und später synchronisieren?
Müssen Abos in unserer App über Apples In-App-Kauf laufen?
Wie fügt sich iOS in ein größeres Mobile-Produkt ein?
Sources & Standards
- App Store Review Guidelines (developer.apple.com)
- HealthKit: Protecting user privacy (developer.apple.com)
- HealthKit: Accessing health records (developer.apple.com)
- App-Datenschutzangaben im App Store (developer.apple.com)
- User privacy and data use (developer.apple.com)
- Privacy manifest files (developer.apple.com)
- TestFlight (developer.apple.com)
- Mobile Health App Interactive Tool (ftc.gov)
Weiter entdecken
Verwandte Seiten.
Ready to Build Your Healthcare Software.
Let's discuss your project requirements and build something that delivers real clinical and business value.
