Android app development
Native Android apps in Kotlin for phones, tablets and rugged devices, published on Google Play or deployed privately through Android Enterprise.
When an app needs to feel at home on iPhone and iPad, or rely on Apple features such as Face ID, Apple Pay or Apple Pencil, native development is usually the right choice. We build iOS and iPadOS apps in Swift, publish them on the App Store or distribute them privately, and keep them current with each year's iOS release.
iOS app development is the design, build and release of native apps for iPhone and iPad using Apple's own languages and frameworks. Native apps give the smoothest performance, the fullest access to device features and the behaviour Apple users expect. We build new apps, extend existing ones and modernize older code, for customers and for staff.
Our tools are Swift, SwiftUI and UIKit, with Xcode, TestFlight and automated build pipelines. We also maintain Objective-C code and migrate it to Swift over time.
Many organizations have an iOS app that has fallen behind: crashes after an iOS update, dependencies that are no longer maintained, an ageing Objective-C codebase or a developer who has moved on. We start with a technical review of the code, crash reports and store feedback, stabilize the most urgent problems, then modernize in stages so the app keeps working for your users throughout. The review is written down, so you can decide how far to go.
Many iOS apps are for internal use and should never appear in the public App Store. Apple Business Manager allows custom apps to be distributed privately to your organization, and a device management tool such as Microsoft Intune can install and configure them automatically on company-owned devices. Because Promatics also provides managed IT services, we can align app deployment with how your devices are enrolled and secured. Staff sign in with their existing work accounts through Microsoft Entra ID or another identity provider.
We follow Apple's Human Interface Guidelines, test on real devices, and check accessibility with VoiceOver and Dynamic Type. Apple requires apps to disclose the data they collect, and some apps must include a privacy manifest; we prepare these from what the app actually does. Privacy obligations under PIPEDA and provincial laws, including PHIPA for health information in Ontario, shape what the app collects. Where your users are bilingual, the app is localized in English and French. This is general information, not legal advice.
Apple releases a major iOS version every year, and App Store requirements change with it. We plan maintenance around that cycle so your app keeps working and keeps meeting store rules. If you also need Android, see Android app development, or consider hybrid and cross-platform app development to share code across both. Managed-service clients can include the app's backend in 24/7 monitoring and support, with response targets set in the service agreement.
The exact list is agreed in writing for each project. These are the usual deliverables and the usual boundaries.
Most delays in this kind of work come from access and decisions, not from the technical build. Knowing these early keeps the project predictable.
Each stage ends with something you can review before the next one starts.
For a new app, define users, features and a first release. For an existing app, review code quality, crashes, dependencies and store feedback.
Output: Discovery summary or technical review.
Design screens that follow Apple's conventions and your brand, and test a prototype with users.
Output: Approved designs and prototype.
Develop in Swift in short iterations, sharing TestFlight builds on real devices as features arrive.
Output: TestFlight builds.
Test across devices and iOS versions, check accessibility and privacy disclosures, then submit to the App Store or distribute privately.
Output: Released app.
Plan updates around each year's iOS release, keep dependencies current and act on crash reports.
Output: Maintenance plan and regular updates.
We do not publish package prices. Each estimate is based on an agreed scope, in Canadian dollars, with taxes shown separately. These are the things that move the number most:
SwiftUI is our default for new screens because it is Apple's current direction and needs less code. UIKit is still the right tool for some complex screens and for existing apps, and the two work together, so we mix them where it makes sense.
Yes. Apple Business Manager supports private distribution of custom apps to your organization, usually combined with a device management tool such as Microsoft Intune. Apple's Enterprise Program is another route, with stricter eligibility rules.
Usually the current version and one or two before it, which covers most active devices. For staff apps you can match the versions your devices run. Supporting older versions adds testing cost, so we decide this with you.
Yes. We review the code, stabilize it and then migrate screens to Swift gradually, so the app keeps working throughout. A full rewrite is only recommended when the review shows it is cheaper.
We can build a matching native Android app, or discuss whether a cross-platform framework would serve both platforms better.
Native Android apps in Kotlin for phones, tablets and rugged devices, published on Google Play or deployed privately through Android Enterprise.
One codebase for iOS and Android using Flutter, React Native or .NET MAUI, with native code only where the app genuinely needs it.
One app taken from idea to the App Store and Google Play, through discovery, design, build, testing, release and improvement based on real use.
Tell us what the app should do, who uses it and whether you have existing code. We will reply to arrange a conversation before anything is priced.