Swift IdeasiOS & Android apps
iOS and Android apps with the release process built in.
We build Expo and React Native apps that share business rules and design settings with your web product, take in-app payments through RevenueCat, and ship through Expo's build service. Backend, sync and AI features are built by the same two people, so nothing is lost between three contractors. Every release passes a written gate before it reaches a store.
What clients arrive with
- We have a web product and customers keep asking for the app.
- It works on the simulator and crashes on real phones.
- In-app purchases and web subscriptions disagree about who has paid.
- Every release is a nervous afternoon and nobody is sure what was tested.
- Our people work without signal and lose what they entered.
What you get
- One codebase for iOS and Android
- Expo and React Native, with native modules where the platform needs them. Screens, navigation and gestures are designed for each platform's conventions, not scaled-down web pages.
- Shared packages with your web app
- Types, validation, business logic and design tokens live in a monorepo that both apps import. A rule changes in one place, and both apps pick it up in the next build.
- Payments that agree across platforms
- RevenueCat for App Store and Google Play purchases, Stripe on the web, and one server-side entitlement model with webhooks from both, so a user is never paid on one device and locked out on another.
- Offline-first data and sync
- A local store the app reads first, with queued writes that sync when a connection returns, for people who work in basements, fields and plant rooms.
- AI features on the phone
- Camera and screenshot capture sent to a server-side extraction pipeline with validation and cost logging, and results shown back on the device for review.
- Release engineering
- EAS builds, TestFlight and the Play internal track, a preflight script that runs tests, type checks, Expo Doctor and exports for every platform, and an evidence file in which a missing row blocks the release.
- Crash and product telemetry
- Sentry for crashes and PostHog for product events, set up before launch so the first real users produce useful data.
How the work runs
Choose the platform on purpose
Expo and React Native for most apps; a game engine when the product is a game. We decide from what the app must do on the device, not from habit.
Share the core
Types, rules and tokens move into shared packages first, so the app starts from the same truth as your web product.
Build on real devices
Features are exercised through real gestures on simulators and physical phones, not only in unit tests, with performance watched on older hardware.
Gate, then submit
The preflight and evidence checks must pass before a store build. Submissions go to TestFlight and the Play internal track first; public release is a separate, deliberate step.
How engagements start
- Prototype to production in 4–8 weeks for a focused first release on both stores.
- Web-to-app projects start from your existing product, reusing its logic through shared packages.
- Retained releases afterwards: SDK upgrades, store policy changes and new features on a steady cadence.
Built with
Where each number comes from
Each figure names where it comes from.
- commits in the Expo app, July to September 2026
- 305
- Source: Astro Golf: the Expo app's commit history, all branches
- release certification gates a script checks before Astro Golf can ship
- 52
- Source: Astro Golf: our release test record, 30 July 2026
- automated test files, plus 15 database test suites
- 269
- Source: Astro Golf: counted in the project's test suite, latest development version
The work behind it
Questions, answered
Something else on your mind? hello@swiftideas.com
Native or cross-platform?
Cross-platform with Expo and React Native for most business apps: one codebase, native performance for typical screens, and code shared with the web. We recommend fully native or a game engine when the app depends on heavy graphics or platform-specific APIs.
How do you handle subscriptions on web and mobile together?
Store purchases go through RevenueCat, web payments through Stripe, and both write to one entitlement record on the server. Every paid feature checks that record, whichever platform the user paid on.
Do you use over-the-air updates?
We decide per app. For Astro Golf's first release we disabled remote updates, so any change to executable code ships only in a new signed store build. For other apps, controlled over-the-air updates for JavaScript fixes are a reasonable choice.
What if the App Store rejects the app?
We plan for review from the start: account deletion, privacy labels, purchase restore and sign-in rules are on the release checklist. If a review raises something new, we fix it and resubmit as part of the project.
Can you take over an existing React Native app?
Yes. We start with an audit of SDK version, dependencies and crash data, then upgrade in small, tested steps rather than a single large rewrite.