Mobile apps
iOS and Android apps, native or cross-platform, built to keep shipping
iOS and Android apps built one of two ways: fully native in Swift and Kotlin, or cross-platform with React Native and Expo, Ionic or .NET MAUI. The choice is recommended in writing, with the trade-offs, before the build. Every app ships with automated builds, test releases and crash reporting.
- Typical timeline
- 3–6 monthsTo a first store release after discovery, depending on scope
- How it’s quoted
- IndividuallyAfter a 30-minute call
- Who edits it
- Your teamThrough an admin or CMS we connect to the app
- Stack
- Swift and Kotlin for native buildsReact Native and Expo, Ionic or .NET MAUI for cross-platform
In your name Accounts and repositories, from day one Yours The code and documentation, under the signed agreement
Is it the right call?
When it’s the right call
- Customers need your product in their pocket, not just in a browser tab
- The app needs the camera, location, notifications or offline access
- You want one team and one release process covering both iOS and Android
- An existing app is hard to update or keeps failing store review
When it isn’t
- People will use it a few times a year and would rather not install anything We’d suggest: A fast, installable web app
- The product is a game built around a game engine We’d suggest: A studio that specializes in games
Sound like you? The first step is a 30-minute scoping call with the engineer who would lead the work.Request a scoping call
Two ways to start small
- Fixed scope, usually 2–3 weeks
Discovery sprint
Research into your users, systems and constraints, the architecture decisions written down, and a written plan and quote, yours to take to any team.
Start with a discovery sprint What the written plan covers - Scoped and quoted on its own
Already have an app that won’t build or keeps failing review?
Modernization audit
The code, dependencies, data, hosting and releases reviewed, the risks ranked in a written report, and a step-by-step plan. Nothing beyond the audit is committed until you decide to go further.
Start with an audit What the audit report contains See a sample report
Standard equipment
What we usually hand over on a project like this. Your proposal lists exactly what’s included.
- Swift
- Kotlin
- React Native
- Expo
- .NET MAUI
- Ionic
- iOS
- Android
- TypeScript
Product and technical plan
Screens, data flows and the native or cross-platform decision written down, with the trade-offs, before the build.
Store-ready apps
iOS and Android builds published under your own developer accounts.
Build and release pipeline
Automated builds and test releases, plus over-the-air updates where the framework supports them.
Monitoring
Crash reporting and core analytics, so problems can surface before they reach app store reviews.
Handover documentation
Release runbooks, signing details and a codebase tour for your next engineer.
Specialties
React Native & Expo
One TypeScript codebase for iOS and Android, with fixes shipped over the air instead of through review.
What we build
Customer apps that sit alongside a web product, field tools that work offline, booking and ordering apps, companion apps for SaaS platforms, built against the same API as the web product, and the back ends they talk to, from custom APIs to managed services such as Firebase. Every app is led by a senior engineer.
Native or cross-platform
Both are first-class options, and we build both. Fully native apps, in Swift for iOS and Kotlin for Android, give the deepest platform integration and first access to new OS features. They suit apps whose value depends on the platform: demanding graphics, complex background work, close hardware access, or a team that already maintains native code.
Cross-platform apps share one codebase across both stores. React Native and Expo suit teams already working in React or TypeScript. Ionic suits apps that grow out of a web product. .NET MAUI suits organizations standardized on C# and .NET. We weigh the features, your team’s skills, the release cadence and who maintains the app after launch, and recommend one in writing.
iOS
Apps that follow Apple’s Human Interface Guidelines, support Dynamic Type and VoiceOver, and are built to Apple’s App Store Review Guidelines. We build fully native iOS apps in Swift, or Swift modules and widgets inside a cross-platform app, and we run TestFlight betas, prepare privacy labels and handle review responses.
Android
Apps that behave the way Android users expect, from back navigation to notification channels, tested across screen sizes and OS versions. We build fully native Android apps in Kotlin, or Kotlin modules inside a cross-platform app, and manage Play Console tracks, data safety forms and staged rollouts.
Questions about mobile apps
What drives the cost of a mobile app?
We quote every app individually and don’t publish rates. The biggest cost drivers are native or cross-platform, the number of screens and user roles, offline sync, payments and in-app purchases, the back end and integrations, and how much an existing app needs rescuing first. The written proposal covers scope, timeline and price.
How long does it take to build a mobile app?
Most apps take 3–6 months to a first store release after discovery, depending on scope. You test real builds on your own devices throughout, through TestFlight and Google Play test tracks, and App Store and Google Play review is planned into the schedule rather than discovered at the end.
Whose developer accounts will the app be published under?
The app is published under your own Apple Developer and Google Play accounts, set up in your organization’s name from the start, together with the signing credentials and store listings. We work as invited team members, so you can remove our access at any time and keep publishing without us.
Can you take over an app another team built?
Yes, we take over apps other teams built, native or cross-platform. We audit the codebase, dependencies, build setup and store accounts, fix whatever blocks releases first, such as outdated SDKs, broken builds or signing problems, then upgrade the app in steps, each shipped as a working release.
Every build, any stack
One standard.
Performance
A performance budget is set before launch and enforced on every change.
Accessibility
Built to WCAG 2.2 AA and tested against it, with automated checks and manual keyboard and screen-reader passes on client builds.
Security
Least-privilege access, secrets kept out of code, dependencies monitored and security headers configured.
Handover
Accounts and repositories in your name from day one. The code and documentation are yours under the signed agreement, written so another team could take over.
Start a project
Tell us what the app has to do.
Who uses it, on which phones, and what it talks to are enough to start. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call