Mobile App Developer

Cross-platform for most business applications, native when the app depends on the device. React Native and Flutter let one codebase serve iOS and Android. That halves the build and maintenance work, and it is the right answer for most internal tools, client portals and field applications. Native means Swift for iOS and Kotlin for Android. It earns its cost when performance is critical. Also when the app leans heavily on camera, sensors, background processing or offline behavior, or when it has to feel exactly like the platform. There is a third answer worth considering before either of them. A mobile web application avoids the app stores entirely. For a tool used by your own staff that is often enough, and it removes an entire category of ongoing work, cost and risk.

More than most firms budget for. Publishing means a developer account for each platform, store listings and screenshots, a privacy policy, data disclosure declarations, and passing review. Apple publishes its App Store Review Guidelines, and Google Play its own policies. Both reject submissions for reasons that have nothing to do with code quality. After launch comes the part that never ends. Operating system releases twice a year that can break things. Device compatibility, crash monitoring, dependency updates, and store policy changes that require action on a deadline. An app is an ongoing commitment rather than a one-off project. Budgeting for the build and not for the year afterwards is the most common mistake in this category. It is also the one that turns a finished app into an abandoned one.

Your business, and this one is worth getting right before a single line is written. Both developer accounts are registered in your company's name, paid by you, with the developer added as a team member. The app is published under your organization, not somebody else's. Signing certificates and keys belong to you, stored where your company controls them. Losing access to an Android signing key means you cannot update your own app. The listing, the reviews, the ratings and the install base are all attached to that account. Firms that let an agency publish on their behalf discover the problem at the worst possible moment. Access is granted by you and removed by you, as with every other system in this arrangement. Set the accounts up first, before any code exists.

As an ongoing engagement, because the platforms will not leave you alone. Apple and Google each ship a major operating system release every year, and both periodically raise the minimum requirements a submission has to meet. Dependencies need updating for security. New devices and new screen sizes keep arriving as well. Crash reports need somebody actually watching them each week. The practical arrangement is a maintenance allocation rather than an occasional emergency call. A defined number of hours a month covering monitoring, updates and small fixes, with larger work scoped separately. Firms that end an engagement at launch usually return within a year to a codebase that no longer builds. Paying somebody to relearn a codebase from scratch costs more than maintaining it would have, every single time we have seen it.

A decision about what the app is for, and evidence that people will use it. Specifically: who uses it, and the three things they need to do. Then whether those genuinely need an app rather than a web page on a phone. Then the practical inputs. Designs or at least wireframes, the backend or data source the app talks to, a decision on authentication, and the developer accounts. If the app handles personal data, the privacy policy and the store data disclosures are required rather than optional. Starting a build before those are settled produces expensive rework, because a mobile decision made wrong is harder to reverse than a web one. Bring us the problem and the users, and we will tell you honestly whether an app is the answer.