HomeServicesiOS App Development
Native iOS app development, in Swift and SwiftUI
iOS app development is the design, build and release of apps for iPhone, iPad and Apple Watch, written natively in Swift and SwiftUI and distributed through the App Store. Woltrio builds iOS apps for healthcare companies, startups and enterprises, with HealthKit, push notifications, offline sync and App Store privacy requirements handled from the first sprint.
What we build for iPhone, iPad and Apple Watch
These five app types share the same native foundation: Swift, SwiftUI, Apple's privacy rules and App Store review. What changes is the data they handle, how they are distributed and how they make money.
Healthcare & mHealth apps
Health apps on iOS often read and write HealthKit data such as steps, heart rate or sleep. HealthKit asks for permission per data type, and an app cannot tell whether a person denied read access. Apple's rules forbid using HealthKit data for advertising, selling it to data brokers, or storing personal health information in iCloud. For research and care programs, Apple offers ResearchKit and CareKit, and HealthKit can read FHIR clinical records that people download from supported providers. We add the privacy policy, usage descriptions and consent flows App Review expects.
HealthKit permissions · No PHI in iCloud · Clinical records (FHIR) · ResearchKit and CareKit
Telemedicine & patient apps
Patient apps combine scheduling, secure messaging, video visits, intake forms and reminders in one place. On iOS that means camera and microphone permissions with clear usage strings, APNs notifications that never put PHI on the lock screen, and Face ID or passcode sign-in through the system frameworks. Video runs on a vendor you choose or your own WebRTC stack, with a backend that signs a BAA. We connect the app to your EHR or portal through FHIR APIs and keep visit data off the device when it does not need to stay there.
Video visits · PHI-free push · Face ID sign-in · EHR via FHIR
Enterprise & B2B apps
Internal and B2B apps serve field teams, sales staff, clinicians or warehouse workers. They usually need single sign-on with your identity provider, offline work with later sync, barcode or document scanning, and deployment through mobile device management. Apple's Custom App distribution makes an approved app visible only to the organizations you name, who then deploy it through MDM or redemption codes. Custom apps still pass App Review, so we prepare demo accounts and sample data for reviewers. Role-based access and audit logs live on the backend, not only in the app.
Single sign-on · Offline field work · Custom App distribution · MDM deployment
Consumer & subscription apps
Consumer apps live or die on onboarding, performance and retention. Under App Store Review Guideline 3.1.1, unlocking digital features or content generally requires In-App Purchase, so we build subscriptions with StoreKit, verify transactions on your server and handle renewals, refunds and grace periods. Storefront-specific exceptions exist, and we check the current guideline before you choose a payment model. If you add third-party social login for the primary account, Guideline 4.8 requires an equivalent privacy-focused login option. Analytics are set up so the privacy label and ATT prompt match what the app really collects.
StoreKit subscriptions · Guideline 3.1.1 · Privacy-focused login · Retention analytics
Apple Watch & iPad apps
Apple Watch apps suit glanceable tasks: medication reminders, workout tracking, alerts and quick replies. Workout sessions on the watch fine-tune its sensors for the chosen activity and record high-frequency heart rate samples, and the app must clearly show when a session is running and let people save or discard it. iPad apps need layouts that use the larger screen, keyboard and pointer support, and often Apple Pencil for forms, signatures or annotations. SwiftUI lets one codebase share models and logic across iPhone, iPad and Apple Watch while each device keeps its own interface.
watchOS workouts · Complications and alerts · iPad layouts · Apple Pencil input
The parts of a production iOS app
Every iOS app we ship is built from the same six building blocks, sized to what your product needs.
SwiftUI interface and design system
We design screens in Figma, then build them in SwiftUI with a shared component library, Dynamic Type, Dark Mode and VoiceOver labels from the start. UIKit fills the gaps where a SwiftUI view is not yet enough, such as complex text editing or camera views.
Learn moreOffline data and sync
SwiftData or Core Data keeps a local copy of the data people need, so the app opens and works without a signal. Changes queue on the device and sync to your server when the connection returns, with clear conflict rules and nothing sensitive cached longer than needed.
Backend and APIs
Most apps need a backend for accounts, business logic, files and integrations. We build REST or GraphQL APIs with authentication, rate limiting and audit logs, hosted in a cloud region you choose, and for health data on infrastructure covered by a BAA.
Learn morePush notifications with APNs
The app registers with Apple Push Notification service, receives a device token on each launch and forwards it securely to your server. We handle multiple devices per user, token refresh after restores, notification categories and quiet hours, and keep PHI out of payloads.
Privacy and App Store compliance
We maintain the privacy manifest (PrivacyInfo.xcprivacy) with collected data types and required reason APIs, check every third-party SDK against Apple's list of SDKs that need a manifest and signature, and fill in the App Privacy details so the App Store label matches the code.
Testing and release
Unit and UI tests run in CI on every pull request. Builds go to internal testers through TestFlight, then to external testers once Apple reviews the first build. We prepare App Store metadata, screenshots, review notes and demo accounts, then manage submission and updates.
Cross-platform vs. native iOS
When native iOS is the right choice
Cross-platform frameworks such as Flutter and React Native are a sound choice for many apps, especially when iOS and Android matter equally and the budget is tight. Native Swift makes more sense when the app relies on HealthKit, Apple Watch, widgets or new Apple APIs, when iPhone users are your main audience, or when platform feel and accessibility are central to the product.
One app on iOS and Android
Off-the-Shelf
One shared codebase for both platforms. Usually the faster and cheaper route when both audiences matter equally.
Custom-Built with Woltrio
Separate Swift codebase. Android is built natively alongside, or later, by a Kotlin team sharing the same backend and APIs.
HealthKit, Apple Watch and widgets
Off-the-Shelf
Possible through plugins or native modules, but watch apps and widgets usually still need Swift code.
Custom-Built with Woltrio
Direct access to HealthKit, watchOS, widgets and Live Activities without a bridge layer.
New Apple APIs
Off-the-Shelf
Available once the framework or a plugin supports them, or through custom native code.
Custom-Built with Woltrio
Usable as soon as Apple ships them in the SDK.
Budget and time to market
Off-the-Shelf
Lower total cost when you launch on both platforms at once.
Custom-Built with Woltrio
Efficient for an iOS-first launch; a second native app adds cost later.
Platform feel and accessibility
Off-the-Shelf
Good for most business apps; some system behaviors need extra work to match.
Custom-Built with Woltrio
System controls, VoiceOver, Dynamic Type and gestures behave exactly as iOS users expect.
We build both, so we recommend the option that fits your users, roadmap and budget.
Built in from the first release
Four things every iOS app we deliver includes, whatever its category.
Tokens and keys live in the Keychain, sign-in supports Face ID and Touch ID through the system frameworks, and all traffic uses TLS. Health apps are designed with HIPAA safeguards. Woltrio is ISO/IEC 27001:2022 certified, and we sign a BAA with healthcare clients before PHI is shared.
How we approach iOS projects
Healthcare-grade discipline applied to every app, whether it handles PHI or not.
App Review planned from day one
We read the relevant App Store Review Guidelines before design starts: health data, payments, login, account deletion and privacy. Reviewer notes, demo accounts and the privacy label are part of the plan, not a scramble the week before launch.
Privacy built into the architecture
We map what data the app collects, where it is stored and who receives it before writing code. Health data stays out of iCloud and advertising tools, PHI stays out of push payloads and logs, and every SDK is reviewed for its privacy manifest.
One team from design to backend
Designers, iOS engineers, backend engineers and QA work in the same sprints. You see a TestFlight build every sprint, so feedback comes from real devices, and the same team can add Android or a web portal later without a handover.
From idea to App Store
- 01
Discovery and platform decision
We clarify users, core features, data flows and regulatory scope, then recommend native iOS, cross-platform or both, with a scoped first release and estimate.
- 02
UX design and prototype
We design key flows following Apple's Human Interface Guidelines and test a clickable prototype with real users before engineering begins.
- 03
Build in sprints
Two-week sprints deliver working features in Swift and SwiftUI, with automated tests and a new TestFlight build you can install on your own devices.
- 04
Privacy, security and review prep
We finalize the privacy manifest, App Privacy details, permission strings and reviewer notes, run security and accessibility checks, and open external TestFlight testing.
- 05
Launch and ongoing support
We submit to the App Store, answer reviewer questions, monitor crashes after release and keep the app current with each new iOS release and policy change.
Frequently
Asked Questions
Seeking basic information? Our FAQ section is a ready reckoner with precise answers to the most probable queries.
When should we build a native iOS app instead of a cross-platform app?
What are Apple's rules for using HealthKit data?
Does a health app on iOS have to comply with HIPAA?
What privacy information does the App Store require?
How does beta testing work before an iOS app launches?
Can an iOS app work offline and sync later?
Do subscriptions in our app have to use Apple In-App Purchase?
How does iOS fit into a larger mobile product?
Sources & Standards
- App Store Review Guidelines (developer.apple.com)
- HealthKit: Protecting user privacy (developer.apple.com)
- HealthKit: Accessing health records (developer.apple.com)
- App privacy details on the 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)
Keep exploring
Related pages.
Ready to Build Your Healthcare Software.
Let's discuss your project requirements and build something that delivers real clinical and business value.
