How to Choose a Mobile App Development Company: Vetting Questions

Vetting a general software vendor and vetting a mobile app vendor are not the same exercise. A custom software company can get away with vague answers about 'scalability' and 'best practices.' A mobile app vendor cannot, because mobile apps live inside two systems the vendor doesn't control: Apple's App Store and Google's Play Store, each with its own review process, policy changes, and rejection risk. If a vendor can't speak concretely about that world, their general software experience doesn't transfer the way you'd hope.

This article assumes you've already done the general vendor homework (IP ownership, pricing model, discovery process). If you haven't, our general vendor vetting framework covers that ground. What follows is narrower: the questions that only matter once 'custom software' becomes 'an app that two app stores can reject, delay, or deprecate without asking your permission.'

Ask to see shipped apps, not a portfolio deck

A portfolio PDF with screenshots proves a vendor can design a UI. It doesn't prove they can ship. Ask for the actual App Store and Play Store listings of apps they built, and check the publish date, the version history, and the review count. An app that's been updated regularly over a year or two tells you the vendor stuck around for the unglamorous part of the job: patching, updating, and responding to platform changes.

Then ask the harder question: has an app you built ever been rejected, and what happened? A vendor with real App Store history has a specific answer, something like a metadata issue, a privacy disclosure gap, or a crash caught late in review. Apple publishes its own App Store Review Guidelines, and most rejections trace back to a handful of recurring categories: incomplete functionality, privacy violations, or guideline misreads on things like in-app purchases and data collection. A vendor who has navigated that process can tell you what they changed and why. A vendor who hasn't will give you a generic 'we follow the guidelines' answer that tells you nothing.

How do they handle OS version support and yearly platform changes?

Apple and Google each release a major OS update annually, and both quietly deprecate APIs, tighten privacy rules, and change review requirements along the way. An app that worked fine in January can fail review in October if nobody updated it to match the new SDK or permission model. Ask the vendor directly: who is responsible for testing your app against new iOS and Android releases before they go live, and is that work included in a support agreement or billed separately each time?

The honest answer involves a plan, not a promise. A vendor worth hiring should be able to describe a cadence: testing against beta OS releases before public rollout, a defined window for addressing deprecated APIs, and a clear line on who pays when a platform change forces unplanned work. If the answer is some version of 'we'll handle it when it comes up,' that's a maintenance bill waiting to happen.

Offline sync and push notifications: ask for a specific example, not a yes

Almost every vendor will say yes when you ask if they can build offline sync or push notifications. That's not the useful question. The useful question is: describe a time offline sync caused a real problem, and how you solved it. Conflict resolution when two devices edit the same record offline, partial sync failures on poor connections, and notification delivery across backgrounded apps are all places where inexperienced teams discover the hard way that the feature is more than a checkbox.

The same applies to push notifications. Delivery isn't guaranteed, timing isn't guaranteed, and both Apple's and Google's notification services behave differently under battery optimization settings the user controls, not the developer. A vendor who has shipped this before will talk about fallback behavior and delivery tracking. A vendor who hasn't will talk about the API they'll use.

Device and OS fragmentation: how do they actually test?

Android alone spans a wide range of manufacturers, screen sizes, and OS versions still in active use, and iOS users don't all update to the latest release on day one. Ask how the vendor tests across that range: a physical device lab, a cloud device-testing service, or just the two phones someone on the team happens to own. The last answer isn't disqualifying for a small, simple app, but it's a different risk profile than you may be assuming, and you should know which one you're getting before you sign.

Also ask what their minimum supported OS version policy is, and why. A vendor who can explain the tradeoff (older OS versions mean a wider user base but more testing surface and fewer modern APIs available) is thinking about your users, not just their own build process.

Native vs. cross-platform: the team composition question

Ask what the vendor would recommend for your specific app, and why, before you tell them which architecture you had in mind. If every answer defaults to the same framework regardless of the project, that's usually a sign of team composition limits rather than genuine technical judgment. A vendor with native iOS and Android developers on staff will have a different default than a vendor built entirely around one cross-platform framework, and neither is wrong on its own. What matters is whether they can explain the tradeoff in terms of your app, not their comfort zone. We go into the actual decision criteria, performance, offline behavior, and long-term cost, in our native versus cross-platform breakdown.

What a real post-launch SLA looks like for mobile (and how it differs from web)

A web app's maintenance agreement can often get away with vague response-time language, because nothing forces a web app to change on a schedule you don't control. A mobile app can't. Apple and Google push OS updates on their own timeline, and an app that isn't tested and updated against them risks removal, rejection on the next submission, or a broken experience for users who update their phones. A real mobile SLA should name specific commitments: how quickly the vendor tests against new OS betas, what the turnaround is for a crash-causing bug reported through crash analytics, and whether resubmission after a store rejection is covered or billed as new work.

On cost, industry estimates commonly put annual mobile app maintenance at somewhere around 15-20% of the original build cost, with the first year sometimes running higher as early bugs and compatibility gaps surface. Treat any number a vendor gives you as a starting point to interrogate, not a quote to accept: ask what's included (OS compatibility testing, bug fixes, minor feature requests) and what triggers an additional invoice.

A short list of questions worth asking on the first call

• Can you show me an app you built that's still live and actively updated, with version history I can check?
• Has an app you built been rejected by Apple or Google, and what did you change to get it approved?
• What's your process for testing against new iOS and Android releases before they roll out publicly?
• Can you describe a specific offline sync or push notification problem you've solved, not just confirm you can build the feature?
• How do you test across device and OS fragmentation, and what's your minimum supported OS version policy?
• What's included in your post-launch maintenance pricing, and what counts as billable extra work?

When the honest answer is 'you may not need a custom app at all'

Part of real mobile experience is knowing when not to build. A vendor who only ever recommends building, regardless of the problem in front of them, hasn't earned the trust that comes with the recommendation. We've written about the pattern of situations where we advise against building custom software at all, and the same discipline applies to mobile specifically: sometimes a web app, a PWA, or an existing platform solves the problem without the ongoing App Store and Play Store overhead a native app carries. A vendor willing to say that in a sales conversation is telling you something useful about how they'll behave once you've signed.

If you're weighing a mobile project against these questions and want a second opinion on scope or approach before committing, our mobile app development team can walk through the specifics with you directly.