In January, Maya, the founder of a wellness startup in Santa Monica, signed a $95,000 contract with a mobile app development company she found on a directory site. The pitch deck showed five App Store screenshots and a reel of glossy onboarding flows. The team quoted twelve weeks to launch on iOS and Android.
Nine months later, Maya had two half-working builds, a TestFlight that crashed on iOS 17, and an Android APK that the Play Store rejected three times for permissions issues. The agency kept promising the submission was “one sprint away.” It never was.
She pulled the plug, salvaged the backend API, and started over with a different team. The second build shipped to both stores in eleven weeks. The first $95,000 was gone.
Maya’s story is the one every founder in Los Angeles hears some version of before they pick a vendor. It’s also mostly avoidable once you know what separates mobile app development companies that ship from the ones that cash checks.
Mobile is different from web. The build-to-release cycle isn’t “deploy to production”, it’s two separate store reviews, two operating systems that update every year, push notification certificates that expire, and UX conventions that are specific to iOS and Android. A team that’s great at web apps can get any of these wrong in ways that delay a launch by months.
This guide is for founders and product leads evaluating mobile app development vendors. It covers the questions that actually predict success on a mobile project, the native vs cross-platform trade-off in plain terms, realistic cost ranges, and the red flags that should end the conversation. If you’re still deciding between a mobile app specialist and a general software development company, the second half of this guide will help you draw that line.
Here’s what we’ll cover:
| Section | What You’ll Learn |
|---|---|
| What mobile actually involves | Why mobile is not just “web but smaller” |
| Native vs cross-platform | When each one is the right call |
| Questions for mobile vendors | The 10 that predict whether they’ll ship |
| Cost ranges | Real numbers for iOS, Android, and cross-platform |
| When a generalist is enough | When a mobile specialist is worth the premium |
| Red flags | Signals to walk away |
What a Mobile App Project Actually Involves
Before you talk to vendors, it helps to know what you’re buying. A mobile app project is rarely just “an app.” It’s a small system with several moving parts that have to work together, and each one is where inexperienced teams lose weeks.
The client app (or apps). Either one cross-platform codebase or two native codebases for iOS and Android. This is what most people picture when they think “the app.”
A backend API. Unless your app is a standalone utility with no login and no sync, it needs a server. That server handles auth, data storage, business logic, and anything that has to stay consistent across devices. Mobile apps and their backends should be scoped together. Retrofitting an API to an app that’s already half-built is where projects blow up. Our API integration team scopes backend and mobile as one engagement for this reason.
Push notifications. iOS uses APNs. Android uses FCM. Certificates and keys have to be generated, uploaded, and renewed. Push is also a UX design problem, not just a technical one. An app that sends too many push notifications gets uninstalled.
App Store and Play Store submission. This is its own skill. Apple’s review team rejects apps for reasons that aren’t in any public document, privacy manifest entries, tracking disclosures, in-app purchase rules, UI that looks too much like iOS system UI. Google’s reviews are faster but stricter on permissions, data safety forms, and background behavior. A good vendor knows the current rules. A bad one learns them in real time, at your expense. Apple’s App Store Connect documentation is the authoritative source but it’s dense, and the rules change quietly.
Post-launch updates. iOS and Android both ship a new major OS version every year. Each release breaks something, a deprecated API, a new permission model, a changed default. If your app isn’t actively maintained, it degrades. Build a maintenance plan into the contract before signing.
Offline-first behavior. If the app has to work without a connection (field service, travel, spotty coverage), offline is a core architectural decision made at the start. Bolting it on later is rarely a weekend’s work.
If a mobile app development company doesn’t mention these pieces in their scoping conversation, they’re quoting you the visible part of the iceberg.
Want a straight read on what your project actually involves? Schedule a free mobile strategy call and bring whatever you’ve sketched out. We’ll tell you what’s missing.
Native vs Cross-Platform: The Trade-off in Plain Terms
Every mobile app project starts with the same decision: two separate codebases (one for iOS in Swift, one for Android in Kotlin), or one cross-platform codebase (typically React Native or Flutter) that ships to both stores.
Neither is the right answer by default. Here’s how the trade-off actually plays out.
| Factor | Native (Swift + Kotlin) | Cross-Platform (React Native / Flutter) |
|---|---|---|
| Development cost | Roughly 1.6–1.8x of a single platform | Roughly 1.2–1.3x of a single platform |
| Performance | Best possible on each platform | Good for most apps, gaps on graphics-heavy workloads |
| Access to new OS features | Immediate (day-one APIs) | Lags 3–12 months depending on framework |
| UX consistency with platform | Perfect, uses platform conventions by default | Good, but requires discipline to not look “neither iOS nor Android” |
| Team size needed | Two separate skillsets (or two teams) | One team |
| Long-term maintenance | Two codebases, double the OS-update work | One codebase, but framework upgrades can be painful |
| Right for | Games, AR, complex camera/video, audio processing, deeply platform-integrated apps | Most business apps, content apps, utilities, social, ecommerce, MVPs |
When native is the right call:
- The app relies on platform-specific APIs that cross-platform frameworks don’t expose well (ARKit, ARCore, advanced CoreML/ML Kit, low-latency audio)
- The app is a game or has game-like animations
- You need day-one support for new iOS or Android features
- You already have native developers on the team
When cross-platform is the right call:
- The app is a business app: content, commerce, social, dashboards, bookings, messaging
- You’re validating an idea and need to ship to both stores fast
- The team writing the app is a web team (React Native uses JavaScript/TypeScript, familiar tooling)
- Budget matters and the app doesn’t need bleeding-edge native capability
When Carlos, the COO of a logistics company in Long Beach, asked us whether his driver-facing app should be native or React Native, the honest answer was React Native. The app needed GPS, a barcode scanner, offline route data, and a clean form experience. All of that is well supported cross-platform. Native would’ve cost 40% more and shipped two months later without giving drivers anything they’d notice.
The opposite happened for a music production tool a Culver City founder was scoping. Low-latency audio, MIDI, and real-time effects are genuinely painful cross-platform. We recommended two native builds even though the budget stretched. Two years later the app has a 4.8 rating on iOS and the Android version matches it, something a React Native build wouldn’t have hit without rewriting the audio engine in native modules anyway.
The takeaway: the tech choice should fall out of the product. If a vendor pitches you React Native before hearing what the app does, that’s a process problem. For a closer look at how the best mobile app developers in Los Angeles handle this decision, we break down the LA market separately.
10 Questions to Ask a Mobile App Development Company
These are the questions that surface information most vendors don’t volunteer. They’re aimed specifically at mobile projects, the generic how to choose a software development company questions still apply, but these are the mobile-specific additions.
1. “Who handles App Store and Play Store submission, and how many apps have they shipped in the last 12 months?” This is the question that separates real mobile app development companies from web shops that do mobile on the side. Someone on the team should have shipped at least a dozen apps in the past year. Ask for the store listings. They’re public.
2. “Walk me through a recent rejection you handled.” Every active vendor has had apps rejected by Apple or Google recently, it’s part of the job. If they claim they’ve never had a rejection, they haven’t shipped much. If they can’t articulate why the rejection happened and how they fixed it, they don’t own that process.
3. “How do you handle iOS and Android OS upgrades?” Every September, Apple ships a new iOS version. Every August, Google ships a new Android version. Both can break apps. Ask what their process is, how they test beta OSes, how they patch issues before the public release, how they handle deprecated APIs.
4. “Native, React Native, or Flutter, and why?” Good answer: “It depends on what the app needs to do.” Then they ask questions about the product before recommending anything. Bad answer: a firm preference stated before they know the product.
5. “Can we see your post-launch engagement model?” Mobile apps aren’t “done” at launch. They need bug fixes, OS compatibility updates, push certificate renewals, analytics reviews, and App Store optimization. Ask what the engagement looks like in month three and month twelve. If the answer is “we’ll quote it when we get there,” you’re renting, not partnering.
6. “What does your mobile UX process look like?” Mobile UX has its own patterns, tab bars, modals, pull-to-refresh, swipe gestures, dark mode, dynamic type. A web designer retrofitting web patterns to mobile produces apps that feel off to users even when they can’t articulate why. A mobile UX team should be involved from wireframes, not brought in at the end.
7. “How do you handle offline and poor-connectivity scenarios?” If the app has any field use case, this matters. Ask what their default architecture is for offline writes, conflict resolution on reconnect, and state sync. If the answer is “it’ll sync when online,” press harder. That’s not an answer.
8. “How do push notifications get designed, not just implemented?” Push is a UX problem disguised as a technical one. Apps that push too often or at bad times get muted or uninstalled. Ask how they design push triggers, segmentation, and frequency. If it’s purely a backend checklist, they’re treating it as plumbing.
9. “What analytics and crash reporting do you set up by default?” Good defaults: Firebase Crashlytics or Sentry for crashes, something like Mixpanel, Amplitude, or PostHog for product analytics, App Store Connect Analytics and Play Console vitals for store metrics. If the answer is “whatever you want” with no recommendation, they haven’t thought about it.
10. “Who owns the App Store and Play Store accounts?” You do. Full stop. Both stores are set up under your business’s developer accounts, under your Apple ID and Google account. A vendor who owns the developer accounts is a vendor who can hold your app hostage. Get this in writing before any code is written.
Real Cost Ranges for Mobile App Development
Cost is the question everyone wants a straight answer on. Here are realistic ranges for a well-scoped first version, based on what LA-area studios and reputable US-based mobile app development companies are actually quoting in 2026.
| Scope | Typical Range | Timeline |
|---|---|---|
| iOS only, focused MVP (1 platform, 6–10 screens, auth, core flow) | $45,000 – $85,000 | 8–12 weeks |
| Android only, focused MVP (same scope as iOS) | $45,000 – $85,000 | 8–12 weeks |
| Both iOS and Android native (same scope, two codebases) | $90,000 – $160,000 | 12–18 weeks |
| Cross-platform React Native or Flutter (ships to both stores) | $60,000 – $120,000 | 10–14 weeks |
| Full product: cross-platform app + backend API + admin panel | $110,000 – $220,000 | 14–22 weeks |
| Complex native app (games, AR, advanced media) | $180,000+ | 20+ weeks |
A few notes on these ranges:
They assume US-based senior engineering. Offshore rates are lower on paper. In practice, projects at offshore rates often take 2–3x the hours and produce code that needs to be rebuilt, as Maya’s story at the top of this piece illustrates.
They exclude App Store and Play Store fees. Apple charges $99/year for a developer account. Google charges a one-time $25 for a Play Console account. These are your fees, not the vendor’s.
They exclude push notification and analytics services. Firebase, OneSignal, Mixpanel, and similar tools have free tiers that cover most early-stage apps. Plan for $100–$500/month as usage grows.
MVP cost is not total product cost. A shipped MVP is version one. Months two through twelve typically add another 40–80% of the original build cost in ongoing development. Budget for it up front.
For a deeper breakdown of mobile-inclusive MVP budgets, see our MVP development cost guide.
When a General Software Development Company Is Enough
Most of this guide has been about vetting specialized mobile app development companies. That’s the right path for most mobile-first products. But it’s not the only path.
A general software development company is enough when:
- The mobile app is a companion to a web product, not the core product. An app that wraps an existing web flow, sends push notifications, and syncs with a web dashboard doesn’t need a mobile-only specialist. A competent full-stack team that has shipped mobile before can handle it.
- The app is internal, not consumer-facing. Internal tools don’t go through App Store review the same way (they can ship via TestFlight, enterprise distribution, or MDM). The store-review expertise matters less.
- The budget rules out dedicated mobile specialists. A full-stack team that does mobile as part of its mix is typically 15–25% cheaper than a mobile-only shop. If your budget is tight and the app is a business tool (not a high-polish consumer product), the trade-off can be worth it.
A mobile specialist is worth the premium when:
- The app is the product, and App Store rating is a growth lever. Consumer apps live or die by polish. A 4.6+ rating drives organic install volume. A 3.8 rating kills it. Polish takes specialists.
- The project involves advanced platform capabilities. AR, real-time audio, advanced camera, HealthKit, SiriKit, Widgets, App Clips, Live Activities, Dynamic Island, these aren’t casually learned.
- Submission has failed before. If your app has been rejected multiple times already, you need someone who’s been through it. Don’t pay a generalist to learn App Store review rules on your budget.
Freelancers. A senior mobile freelancer can ship a simple app well, usually at 20–40% less cost than an agency. The risk is continuity, if the freelancer is unavailable for two weeks during submission, your launch slips. Freelancers work when the scope is small, the deadline is flexible, and you trust the individual specifically.
In-house. Hiring a mobile engineer in LA typically runs $160k–$220k fully loaded for a mid-level, $220k–$300k for senior. That’s roughly the cost of a full cross-platform MVP every year. In-house makes sense once the app is your core product and you have 12+ months of continuous mobile work to do. For anything less, a vendor or freelancer is usually the better call.
Red Flags When Vetting a Mobile App Development Company
These are the signals that should end a conversation.
- They claim “everything in React Native” or “always native.” No context. Tech choice should fall out of the product. A preferred stack is fine. A religious one isn’t.
- They don’t have published apps you can install. Every real mobile shop has App Store and Play Store links. Ask for them. Install one. Five minutes of using a vendor’s shipped app tells you more than an hour on a call.
- They want to own the App Store or Play Store account. Non-negotiable red flag. Your accounts, your keys, your app.
- They can’t articulate the current App Store review rules. App Store rules change. If their answer is boilerplate from 2021, they haven’t submitted recently.
- They treat push notifications as a checkbox. “Yes, we’ll add push” without any conversation about segmentation, frequency, or opt-in flows means push will get implemented and then ignored.
- They skip the backend conversation. If an app needs a backend and the vendor says “we’ll figure that out later,” they won’t. They’ll cobble one together mid-project and it’ll bottleneck everything.
- Their portfolio is mostly web. Mobile experience is specific. A team that does mostly websites with a token app in the portfolio is going to learn mobile on your timeline.
- They commit to App Store approval timelines. No one can. Apple’s review is 24–48 hours usually but can stretch to weeks. A vendor who guarantees a submission date is either inexperienced or lying.
One stat worth knowing: Statista reports that global app store downloads continue to grow, but so does rejection volume on both stores as review teams get stricter. Shipping on mobile in 2026 is harder than it was in 2020. The bar moved up. Pick vendors who’ve moved with it.
How to Actually Make the Decision
After three to five vendor conversations (don’t do more, you’ll hit decision fatigue), here’s a scoring framework that maps to what matters for mobile specifically.
| Criteria | Weight | What You’re Evaluating |
|---|---|---|
| Shipped mobile track record | 25% | How many apps in the last 12 months? Can you install them? |
| Tech choice reasoning | 20% | Did they ask about the product before recommending a stack? |
| Submission and post-launch process | 20% | Do they own App Store and Play Store work end-to-end? |
| Mobile UX and design capability | 15% | Do they have designers who think in iOS and Android patterns? |
| Contract and ownership terms | 10% | Do you own the code, the accounts, the IP? |
| Communication quality | 10% | Were they responsive, specific, and willing to say no? |
The vendor who scores highest on shipped track record and tech choice reasoning is almost always the right pick. Those two categories filter out the teams that learn on your project.
The Short Version
Finding a mobile app development company that actually ships isn’t about finding the flashiest portfolio or the lowest quote. It’s about finding a team that has shipped recently, thinks about the product before the stack, owns submission and post-launch as part of the scope, and will tell you honestly when your idea needs a different approach.
Mobile projects fail in the places generalists don’t look: submission rules, OS updates, push notification UX, offline behavior, store account ownership. A good vendor has a real answer for each of these before you ask.
If you’re scoping a mobile app and want a straight read on whether cross-platform, native, or a different path fits your product, book a 30-minute mobile strategy call. Bring whatever you’ve written down, a sketch, a competitor screenshot, or just a paragraph of what the app should do. We’ll tell you what it would actually take to ship, whether we’re the right team for it, and what to ask the next vendor if we’re not.
If you’d rather read more about how we scope mobile engagements, learn about our team and how we handle mobile projects from discovery through App Store submission.