Most vendor pages answer the easy question. They list frameworks, show team photos and promise delivery. They rarely answer the question that decides whether the engagement works: will the thing they hand you actually pass review and stay in the stores?

This article covers what to settle before signing with a mobile development partner in Vietnam. The store rules below are the current published requirements, and at least one of them has a deadline that falls this week.

Decide the build type before you compare vendors

Three options are on the table for most products, and the choice changes the cost of everything afterwards.

Native means Swift for iOS and Kotlin for Android, written separately. You get full access to platform features on the day they ship, and you pay for two codebases.

Cross-platform means Flutter or React Native: one codebase, two apps, with native modules where you need something the framework does not cover. For most business applications, booking flows, dashboards and content products, this is the default worth arguing against rather than the exception.

A web wrapper means packaging an existing site in a shell. It is the cheapest and the riskiest, because Apple publishes a rule against it. Guideline 4.2 of the App Store Review Guidelines says an app should include features, content and UI that take it beyond a repackaged website, and that if an app is not useful, unique or "app-like" it does not belong on the App Store. Guideline 4.2.2 adds that apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links.

If a vendor proposes a wrapper for a product that is mostly a website, ask them directly how it clears 4.2. A good answer describes offline behaviour, native features and workflows the browser cannot do. A bad answer is that they have shipped wrappers before.

Store readiness is part of the deliverable

This is where handovers go wrong. The app builds, the demo works, and then it cannot be published.

Google Play sets a minimum target API level and moves it every year. The current target API level requirements state that new apps and app updates must target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running a newer version of Android. Existing mobile and Android Auto apps were required to reach Android 15 by 31 August 2026, and developers who plan to update can request an extension that keeps the app distributed to all Google Play users until 1 November 2026.

Read that against a handover. If a partner delivers an Android app targeting API level 34, it is not merely dated. New users on current devices cannot install it, and the update you need to fix that must itself target API 36. The work is not large when it is planned and awkward when it is discovered after sign-off.

So put the target API level in the acceptance criteria, in writing, with the version number. Do the same for the iOS deployment target. Ask what the partner's policy is when Google moves the requirement next year, and whether maintenance covers it.

What Apple actually checks

Three guidelines account for most first-time rejections, and all three are avoidable.

Completeness. Guideline 2.1 requires submissions to be final versions with all necessary metadata and functional URLs. Apple states that placeholder text, empty websites and other temporary content should be scrubbed before submission. A staging URL left in the support field is enough to come back.

Minimum functionality, covered above.

Privacy. Guideline 5.1.1 requires a privacy policy link in the App Store Connect metadata field and inside the app itself, somewhere easily accessible. The policy has to identify what data the app collects, how it collects it and every use of that data. It has to confirm that any third party you share user data with, including analytics tools, advertising networks and third-party SDKs, provides equal protection. It also has to explain data retention and deletion, and describe how a user revokes consent or requests deletion.

That last requirement has a build consequence that gets missed. "How a user requests deletion" means an account deletion path has to exist in the product. If the partner's estimate has no line for it, the estimate is incomplete.

Agree who holds the developer accounts before the project starts. The App Store Connect and Google Play accounts should be yours, with the partner added as a user. When the accounts belong to the vendor, your app lives inside someone else's business relationship with Apple and Google.

Which mobile skills you can realistically staff

Mobile talent pools are smaller than web pools everywhere, and that is worth knowing before you plan a timeline. The Stack Overflow Developer Survey 2025 gives a usable proxy for how common each language is among working developers. Across all respondents, JavaScript sits at 66% and TypeScript at 43.6%, while Kotlin is used by 10.8%, Dart by 5.9% and Swift by 5.4%.

Two things follow. First, a React Native team draws on the largest pool of the three mobile routes, because the people writing it already write JavaScript and TypeScript. Second, Flutter and native iOS draw on pools of a similar, smaller size, so staffing either takes longer than staffing a web squad. A partner who offers instant availability of senior Flutter and Swift engineers is describing a sales position rather than a market.

MOHA builds mobile in Flutter, Swift and Kotlin, with Laravel, Vue, React, Node and Java behind them and AWS underneath. Our published work includes a pet healthcare app, a Korean language study platform, an AI eyebrow mapping application for salons, and an OCR reading aid built for visually impaired users. The rest is in our portfolio.

The back end decides more than the app does

A mobile app is a client. Most of the behaviour users complain about, slow lists, stale data, failed payments, duplicated bookings, comes from the API and the data model rather than the screen.

Ask how the partner will handle the parts that are hard to retrofit. Versioning, so an old app on someone's phone keeps working after you ship a new API. Offline and poor connectivity, because mobile users are on trains. Push notifications, including the server side and the consent flow. Payments, where the platform rules on digital goods are strict and the penalty for getting them wrong is removal.

If your product involves scheduling or inventory, the concurrency design matters more than the UI. We went through that problem in scalable ticket booking system architecture, and the same reasoning applies to any app where two users can want the same slot.

The handover to insist on

Write the handover into the contract rather than discussing it at the end. At minimum you should receive the signing keys and keystore with their passwords, ownership of both store accounts, the full repository including the release branch history, the CI or release pipeline in a form you can run, the crash reporting and analytics projects under your own organisation, and the environment configuration documented well enough that a new engineer can build the app on a clean machine.

The test for all of it is simple. A developer who has never seen the project should be able to clone the repository, build a release candidate and submit it. If that is not true, the handover is not finished, whatever the invoice says.

Taking over an app someone else built

A large share of the searches that end on a page like this are not new builds. The original team is gone, the app still earns money, and nobody can ship a change to it.

Treat the first few weeks as an audit with a written output rather than as development. Four checks tell you most of what you need to know.

Can a new engineer build a release candidate on a clean machine from the repository alone? If the build depends on one laptop, a file nobody has, or a certificate that expired, that is the first piece of work and it is not a feature.

Do you control the signing identity? An Android app signed with a lost keystore cannot be updated under the same listing unless Play App Signing was enabled. Recovering from that is possible but it is a project, and you want to find out in week one rather than during a release.

What is the dependency position? Old SDKs are the usual reason an app cannot move to a new target API level. Ask for a list of dependencies with their versions and the ones that are no longer maintained, because that list is the real upgrade estimate.

What do the crash and review signals say? Crash-free rate by version and recent one-star reviews usually point straight at the two or three defects that matter, which is a better first backlog than a feature list.

A partner who starts a takeover by quoting a redesign has skipped all four. Ask for the audit first and decide on the rebuild afterwards.

Questions to ask MOHA

Which build type you would recommend for this product, and why that one rather than the other two.

What target API level and iOS deployment target the delivered app will have, and what happens when the platforms move them.

How the account deletion path and privacy disclosures will be built, not just documented.

Who holds the store accounts and signing keys during and after the project.

What the maintenance arrangement covers when a platform requirement changes.

Where to go next

The store rules are public, dated and testable, which makes them a good way to judge a partner before you have any code to judge. A vendor who can tell you which API level your app will target and how it clears Apple's minimum functionality rule has thought about shipping. One who answers with a framework list has not.

If you want to talk about an app, contact us with what it needs to do and where it is now. You can also read how we run build and team engagements on our custom software development and offshore development center pages.