We build native iPhone and iPad apps for small and medium businesses — sales floors, field engineers, delivery crews, property agents, and customer-facing apps. Native Swift, an architecture designed before the first screen, App Store submission under your own developer account, and someone still answering the phone after launch.
Not a folder of files and an invoice. A working iOS app in the App Store, the backend it talks to, the accounts it depends on in your company's name, and enough written material that a different engineer could pick it up without calling us. Concretely:
The ownership point matters more than it sounds. A common trap with cheap offshore shops is that the App Store listing sits in their developer account and the cloud bill goes to their credit card. The day the relationship ends, you cannot ship an update to your own customers. We set the accounts up the other way around on purpose, before writing code.
Every serious iOS project has a fork in the road in the first two weeks, and almost nobody notices it. Do you store data on the device or fetch it every time? Does the app talk directly to a payment provider or to your own server? Is a "branch" a column in a table or a real boundary in the data model? These are not engineering aesthetics. They decide whether your second branch, second country, or second product line costs a fortnight or a rewrite.
Cheap development shops skip that fork because they are paid by the hour to produce visible screens. The result demos beautifully and then calcifies. When your business changes — and it will — the honest estimate for the change comes back higher than the original build, and you are told the app needs to be "version 2". That is not bad luck. That is the bill for a system nobody designed.
So before we build screens we write down the shape of the system: what the data looks like, where the boundaries are, what happens on a network failure, and which third parties we can replace later without touching the app. You get that as a short document in plain language, and you can challenge it. Then we build in one-to-two-week increments you can open on your own phone, so scope drift is visible while it is still cheap.
The other half is that we operate what we ship. We run our own products in production — including an AI accounting platform used by Japanese tax firms — so the cost of a shortcut lands on us too. That is a materially different incentive from a vendor whose involvement ends at handover.
We will not quote a number on a web page, because anyone who does is guessing. But the drivers are not mysterious, and you can estimate your own position on them before you talk to us.
One kind of user is one app. A customer app plus a driver app plus a back-office console is three products sharing a backend, and it costs closer to three than to one. Cutting a role out of version one is the single most effective way to shorten a build.
Talking to your existing accounting system, ERP, or a bank's payment gateway is usually the longest pole. Sandbox access, approval processes, and undocumented behaviour add weeks that have nothing to do with the app itself. We surface these in week one rather than month three.
An app that requires connectivity is straightforward. An app that keeps working in a warehouse basement and reconciles conflicting edits afterwards is real engineering. Worth it when your staff work where signal fails; a waste when they do not.
The moment payments, refunds, or personal data are involved, you need audit trails, idempotent handling so a retry cannot double charge, and Apple's own payment rules respected. Add time, and be suspicious of anyone who does not.
Roughly: a focused single-role internal app is typically a 6–10 week build. A customer-facing app with accounts, payments, and an admin console runs longer. A multi-role platform with offline sync and integration into systems you already depend on is a multi-month engagement, and we would rather phase it than pretend otherwise.
Stock checks and transfers from the shop floor on an iPad, a manager's app showing yesterday's numbers per branch, clienteling apps that let staff look up a customer's history mid-conversation. Often paired with our POS and payment work.
Engineers, installers, inspectors, and delivery crews filling in job sheets, capturing photos and signatures, and scanning assets — usually offline, syncing when they are back in coverage. Replaces the paper form and the WhatsApp photo.
Agents doing viewings with listing data, documents, and offers on an iPad; accounting and legal firms giving clients a private app to submit documents and see status. Frequently sits on top of a web platform we build alongside it.
You can open our own software right now, without registering: the CEO's Cockpit executive dashboard and simulator runs on fictional data but is the real product. Alongside client work, our AI systems are in production at more than 200 Japanese firms and the POS platform we architected runs in more than 10,000 retail stores. Two case studies are especially relevant to mobile projects:
A React Native marketplace with multi-currency settlement and bilingual listings, shipped to both app stores.
Offline-first point of sale, multi-tenant cloud, and a payment-hardware abstraction layer carrying $50M+ in annual transactions.
The fastest way to waste your money is to hire us for something we are wrong for. So, plainly:
React Native and Flutter apps that ship to both stores from a single codebase, when the app is business logic rather than heavy device work.
Android apps and on-device software for staff, drivers, and counters — including hardware-attached builds on scanners, printers, and payment terminals.
Internal platforms, customer portals, dashboards, and marketplaces — the system your business runs on, not a brochure website.
A focused single-purpose app — one type of user, a handful of screens, a straightforward backend — is typically a 6 to 10 week build from signed scope to App Store submission. Add multiple user roles, offline operation, payments, or integration with an existing system you did not build, and it runs longer, usually into a three to five month range. The honest driver is not screen count but how many external systems the app has to agree with.
Yes, in full, and it is not a negotiation at the end of the project. Code lives in a repository your company owns from the first commit, and the App Store, cloud, and third-party service accounts are created in your company name with you as the owner. If you decide to move to another development partner, you take everything and change nothing.
Often yes. We start with a paid review — usually one to two weeks — where we read the code, run it, and write you an honest assessment: what is salvageable, what is load-bearing but fragile, and what should be rebuilt. Sometimes the conclusion is that continuing is cheaper, sometimes it is that a rewrite of one layer buys back years. We would rather tell you that before you commit to a build.
Yes. We prepare the build, the privacy disclosures, the screenshots and metadata, and we handle the review correspondence including rejections. Apple rejects for reasons that have nothing to do with code quality — account deletion requirements, sign-in options, payment rules, unclear demo credentials — and we have been through those cycles enough times to design around them rather than discover them at submission.
It depends on who uses it. Customer-facing apps in most markets need both, and are often better built once as a cross-platform app. Internal apps for staff on company-issued iPhones or iPads are a genuine iOS-only case, and going native there gets you better performance and full access to the device. We will tell you which situation you are in on the first call rather than quoting for two apps by default.
Apple ships a major iOS release every year, and each one breaks something eventually — a deprecated API, a new privacy prompt, a changed store requirement. We offer an ongoing arrangement covering monitoring, OS-version compatibility, store resubmissions, and a defined response time for defects. Businesses that skip this usually come back eighteen months later with an app that no longer builds.
Yes, and for field work it should. We build a local store on the device that holds the data your staff need, queues everything they do while offline, and reconciles with the server when the connection returns — including the awkward cases where two people changed the same record. This is the same offline-first pattern behind the POS software we architected for more than 10,000 retail stores.
A 30-minute call with an engineer, in English or Japanese. You will get an honest read on scope, timeline, and whether native iOS is even the right answer for you.