DEV Community: Charles Wade

How to Audit a Mobile App Development Company: An Engineering Manager's Playbook

Charles Wade — Mon, 10 Aug 2026 10:43:23 +0000

A few years back I sat in on a vendor pitch that had everything - polished slides, a confident VP walking through "agile delivery," a slide titled "quality-first culture" with a checkmark icon next to it. Six months later I was the one staring at the codebase they'd handed off, and it was not a pleasant afternoon. That gap between what a deck promises and what actually lands in your repo is the whole reason this article exists.

Somewhere in my fifteenth or so year of doing this work, I stopped putting much stock in the sales conversation and started asking to see the repo instead. If you're currently sizing up a mobile app development company for a real engagement, that's the shift worth making before you sign anything, not after the first sprint goes sideways.

What follows isn't a checklist you read once and file away. It's more or less the process I actually run - built up over three decades of shipping software, working with vendors who delivered exactly what they said they would, and a handful who very much didn't. The failures taught me more than the successes did, honestly.

Why the Sales Conversation Tells You Almost Nothing

Sales engineers are good at their jobs, and that's precisely the problem. They're trained to answer the question you ask, not the one you should have asked. Ask "do you do CI/CD?" and the answer is always yes - it costs them nothing to say it. Ask instead, "walk me through your last production rollback, what triggered it, and how long the fix took," and you'll get something real. Assuming there's an answer at all.

I've come to treat technical due diligence less like an interview and more like reviewing the company the way you'd review a pull request. Their engineering culture leaves traces everywhere - in commit history, in how their docs are organized (or aren't), in how they respond when you ask something slightly uncomfortable. You just have to know where to look, and be willing to sit through a bit of awkward silence when the answer isn't ready.

What to Look for in an Enterprise Mobile App Development Company

Four things, in my experience, predict long-term delivery quality better than anything on a slide. None of them show up in a sales deck. All of them are things a legitimate team can show you without much notice.

1. Automated Test Coverage - Look at the Shape, Not the Percentage

Everyone will hand you a coverage number. I'd mostly ignore it. A team sitting at 90% coverage on getters and setters while their payment logic sits at 12% is in worse shape than a team honestly at 60%, concentrated where the risk actually lives.

What I ask for instead is a coverage report broken down by module, plus a sample test suite for something that actually branches - authentication, checkout, offline sync. Here's roughly the kind of thing I want to see from a Kotlin team:

class CheckoutViewModelTest {

    @Test
    fun `applies discount only when promo code is valid and not expired`() = runTest {
        val expiredPromo = PromoCode("SAVE10", expiry = yesterday())
        val result = checkoutViewModel.applyPromo(expiredPromo)

        assertEquals(CheckoutState.PromoRejected, result)
        assertEquals(0.0, checkoutViewModel.discountAmount.value)
    }

    @Test
    fun `retries payment gateway call up to 3 times on transient failure`() = runTest {
        coEvery { paymentGateway.charge(any()) } throws IOException() andThen success

        val result = checkoutViewModel.processPayment(order)

        coVerify(exactly = 2) { paymentGateway.charge(any()) }
        assertTrue(result.isSuccess)
    }
}

If a team can pull up something like this without scrambling for twenty minutes first, their tests are lived-in - written because they got burned once, not written the week before a client demo. If they can't produce anything close to it, that tells you something too, even if nobody says it out loud.

Worth noting: the complexity of what you're building changes how much this matters. A team estimating something like the cost to build an app like Poshmark - with listings, in-app messaging, payments, and search all interacting - needs test coverage on the interactions between those systems, not just each one in isolation. That's usually where the real bugs live anyway.

2. Infrastructure-as-Code, or the Lack of It

I like to ask a blunt question here: "If your lead DevOps person quit tomorrow, could someone else stand up a staging environment from version control alone?"

A surprising number of agencies fail this outright. Their infrastructure lives in one engineer's head, loosely documented in a wiki page nobody's touched since sometime in 2023, running on servers that were configured by hand and that everyone's a little afraid to touch. I've inherited this exact situation twice. Both times, it cost the client months of quiet, invisible delay while we reverse-engineered something that should've already existed on paper - or rather, in code.

What you actually want sitting in their repo looks more like this - boring, version-controlled, unremarkable in the best possible sense:

# terraform/staging/main.tf
resource "aws_ecs_service" "mobile_api" {
  name            = "mobile-api-staging"
  cluster         = aws_ecs_cluster.staging.id
  task_definition = aws_ecs_task_definition.mobile_api.arn
  desired_count   = 2

  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.mobile_api.arn
    container_name    = "mobile-api"
    container_port    = 8080
  }
}

Notice the deployment_circuit_breaker block sitting in there. It's a small detail, but it usually means this is a team that's already had a bad rollout at 2am and built the safeguard in response, rather than a team still waiting for that lesson to arrive.

3. CI/CD Maturity - Ask to See It Run, Don't Just Take Their Word For It

There's a real gap between "we use CI/CD" and having a pipeline that actually gates merges on passing tests, runs static analysis, and ships builds without someone manually dragging a build through TestFlight at eleven at night. So I ask vendors to screen-share a recent pipeline run - not a sanitized case study, an actual one, mess included if there is any.

A pipeline that reflects genuine maturity tends to look something like this:

# .github/workflows/mobile-ci.yml
name: Mobile CI
on: [pull_request]

jobs:
  test-and-lint:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run unit tests
        run: bundle exec fastlane test
      - name: Static analysis
        run: swiftlint --strict
      - name: Check for hardcoded secrets
        run: trufflehog filesystem . --fail

  build-and-deploy:
    needs: test-and-lint
    if: github.ref == 'refs/heads/main'
    runs-on: macos-latest
    steps:
      - name: Build and upload to TestFlight
        run: bundle exec fastlane beta

That trufflehog step in the middle isn't decoration. It leads straight into the part of the audit I actually care about most.

4. Security Practices - Where I Stop Being Polite

I've opened codebases with API keys committed directly into source control, just sitting there in the git history for anyone with repo access to find. I've seen auth tokens stored in plaintext SharedPreferences on Android, which - if you haven't worked in mobile day to day - is roughly like leaving your house key taped under the doormat with a sign pointing at it.

So by this point in the audit, I ask directly, no softening:

Do they run dependency scanning - Snyk, Dependabot, whatever - on every build, or only "when someone remembers to kick it off"?
Is there a documented secrets management approach, or does "documented" turn out to mean a Slack message from eighteen months ago that half the team has forgotten about?
Have they had a third-party penetration test in the last year, and will they share the summary findings? Not the full report necessarily - just the summary.
How do they handle certificate pinning and secure on-device storage?

A team that's serious about this space will answer all four specifically. A team that isn't will get vague, pivot to talking about their "security-first culture," and somehow never land on an actual practice. I've learned to trust that pivot more than almost any other signal in the whole process - it's rarely wrong.

Putting the Audit Together

None of these four checks should take more than an hour each if the vendor is legitimate. A real engineering team can pull up coverage numbers, Terraform state, a live pipeline run, and a security summary without much prep, because that material already exists and gets touched daily. It's not a performance staged for your benefit - it's just Tuesday for them.

If it takes a week to "assemble evidence" of practices they claim are already standard, you've learned what you needed to know before opening a single pull request.

This is also the point where I'd look past infrastructure and into what the team can actually build. If personalization or recommendation logic is part of your roadmap, it's worth asking whether they've shipped anything comparable - an AI recommendation engine case study from a past project, for instance, tells you far more about their real technical range than a slide claiming "AI/ML expertise" ever will. Anyone can put that phrase on a deck. Far fewer teams can show you the architecture behind a working one.

And when I'm doing formal due diligence on a specialized mobile app development company, I treat automated test coverage and infrastructure-as-code as the two highest-signal indicators in the entire process. Almost everything else in the pitch tends to fall into place - or fall apart - depending on whether those two things are genuinely there.

A Short, Honest Checklist Before You Sign

Request a real, unedited coverage report broken down by module
Ask to see actual Terraform, CloudFormation, or equivalent IaC sitting in their repo
Watch a live CI/CD pipeline run, including a failure case if you can get one
Get specifics on dependency scanning, secrets management, and recent pen-test findings
Pay attention to how fast - and how honestly - they answer, not just what the answer is

Thirty years into this, that last point is the one that hasn't changed. Trust what the artifacts show you over what the deck promises you. The vendors worth signing with tend to welcome this level of scrutiny, sometimes even seem relieved by it. The ones who deflect are telling you something too. Just make sure you're actually listening when they do.

Have you run technical due diligence on an outsourced dev team before? I'd genuinely like to hear what red flags you've caught in the process - drop them in the comments.

Native vs Cross-Platform App Development in 2026: Which Is Better for Your Business?

Charles Wade — Tue, 04 Aug 2026 12:20:07 +0000

Okay, so. I've been writing about mobile engineering long enough that I remember when "cross-platform" was basically a punchline in planning meetings. You'd bring it up and some senior dev would just sigh, close their laptop a little, and mutter something about Cordova. Fair reaction back then. Not fair anymore. But old scars stick around, and a lot of 2026 decisions are still quietly shaped by how PhoneGap felt in, what, 2013?

Let's actually dig into where things stand right now. Not the pitch-deck version. The version where memory leaks, hot-reload weirdness, and bridge bottlenecks are the difference between an app that feels premium and one that feels like a chore to open.

Why does this argument never actually end?

Every single year, somebody declares native "dead" or cross-platform "finally grown up," and every single year the truth just sits stubbornly in the middle, refusing to pick a side. Here's the thing though - the real question was never "which framework wins." It's which framework fits the thing you're building, with the team sitting in front of you, on a timeline your finance department will actually sign off on.

I've sat through more architecture reviews than I can count at this point, and there's a pattern that keeps repeating. Engineering teams at leading app development companies tend to pick apart memory leaks, hot-reloading overhead, and bridge bottlenecks long before anyone commits to a framework - and honestly, that process almost never spits out a clean, universal answer. What it produces is a messy decision matrix, usually argued over coffee that went cold twice. If all you've seen is the final slide in someone's pitch deck, you missed the interesting part.

Swift and Kotlin - old reliable, and still reliable

Native hasn't slowed down one bit. If anything, it's gotten sharper. Swift's concurrency model turned into something people genuinely enjoy working in (which, if you used Swift five years ago, sounds almost fake to say). And Kotlin Multiplatform quietly became this thing nobody brings up on conference stages but half the backend-adjacent teams I know are using it to share business logic without ever touching the UI layer.

Where native wins, it wins big, no argument:

Animations that stay smooth even when memory pressure is climbing
Same-day access to whatever new platform API Apple or Google just dropped - no waiting on a plugin maintainer to catch up
Performance ceilings you can actually predict, because there's no translation layer eating cycles between your code and the OS

Where it falls short is just as obvious. Two codebases. Often two separate teams. Two release schedules that almost never line up neatly. For a fintech app handling biometric logins and money movement, paying that cost makes total sense. For a coupon-wallet loyalty app? Probably overkill.

Flutter grew up, and I say that as someone who doubted it

I'll be honest - I was skeptical of Flutter for years. Dart felt like a language nobody had asked for, and early on, the rendering engine had this jank you could literally feel through your fingertips while scrolling a list. That version of Flutter doesn't really exist anymore. The Impeller rendering engine cleaned up most of the stutter that used to embarrass client demos, and Flutter App Development is now genuinely in the same conversation as native, minus a handful of edge cases involving heavy 3D or raw camera pipelines.

What actually surprised me, working alongside teams shipping Flutter at real scale, is how little users care about the "it's not technically native" argument anymore. Nobody's end user knows what's rendering the buttons on their screen. They know whether it feels laggy when their thumb moves fast. And Flutter, these days, mostly clears that bar without much drama.

The catch hasn't fully gone away, though. Flutter is at its best when you don't need immediate, day-one access to something exotic Apple just announced at WWDC. If your business genuinely depends on using a brand-new OS feature within a week of launch, you're either waiting on a plugin author or writing platform channel code yourself - which kind of defeats the purpose of going cross-platform in the first place.

React Native matured, but it's still dragging some old baggage

React Native's New Architecture - Fabric plus Turbo Modules - fixed a lot of what used to keep engineers up at night. That old JavaScript bridge, the one that made scrolling through anything remotely complex feel like wading through syrup, is basically retired for teams that've actually migrated over.

That word, migrated, is carrying a lot of weight in that sentence. A surprising number of production React Native apps are still running the old architecture, because migrating is genuinely disruptive and most teams don't have spare bandwidth to justify it against a roadmap that refuses to pause for anybody. So if you inherit a five-year-old React Native codebase, you're not getting 2026-level React Native performance. You're getting 2021 performance wearing a 2026 sticker.

For teams starting fresh today, though, React Native still makes sense - especially when the team already knows React inside and out, and the app doesn't lean too hard on animation-heavy or graphics-intensive screens.

Hybrid App Development - the practical middle ground nobody talks about enough

There's a version of this whole debate that gets skipped over constantly, and it's proper Hybrid App Development. Not the old WebView-stuffed-inside-a-native-shell approach that gave "hybrid" a bad name a decade ago - the modern version, where teams selectively drop in native modules for the two or three screens that actually need raw performance, while keeping the rest of the UI cross-platform.

I've watched teams shave nearly a third off their timelines using exactly this blend, and the end user never noticed which screens were "really" native and which weren't. If your budget can't stretch to two full native teams, but you've still got one or two performance-sensitive flows that matter a lot, hybrid deserves a serious look before you jump to either extreme.

So, what should you actually pick in 2026?

Here's roughly the framework I'd walk a client through, after thirty-odd years of watching frameworks rise, peak, and quietly get replaced:

Heavy animation, AR/VR, camera-intensive work → Native (Swift/Kotlin). Nothing's really replaced it yet.
Fast-moving startups still validating a market → Flutter, because iteration speed and near-native feel finally coexist.
Teams with deep React expertise, moderate UI complexity → React Native, but only on the New Architecture, not the old bridge.
Budget-tight products with a couple of performance-critical screens → Hybrid App Development, blending in native where it actually counts.

If you're still weighing where each of these actually fits before locking anything in, this complete guide to cross-platform app development goes deeper into the trade-offs than any framework list can on its own.

None of this has to be permanent either. I've watched teams start in Flutter, hit a wall on one specific screen, then bridge in native code just for that piece. The framework war mostly ended a while back. What replaced it is something more useful - a toolbox instead of a religion.

Frequently Asked Questions

1. Is Flutter actually as fast as native apps in 2026?
For most business apps, yes - close enough that users genuinely can't tell. The Impeller engine closed most of the rendering gap that used to separate Flutter App Development from native builds. The gap that's left mostly shows up in graphics-heavy or hardware-intensive cases, like real-time AR filters.

2. Should a startup go with React Native or Flutter for its first app?
Honestly, it comes down to your team more than the framework itself. Already deep in React? React Native shortens onboarding. Starting from zero, or want faster UI iteration with fewer platform-specific headaches? Flutter usually wins that comparison in practice.

3. What does Hybrid App Development even mean now, and is it still relevant?
These days it means a cross-platform base with select native modules dropped into the screens that need real performance - not the old WebView wrapper trick. It's still very relevant for teams trying to control cost without wrecking the experience on the handful of screens that actually matter to users.

4. Do top app development companies still push native for enterprise work?
Often, yes - particularly for finance, healthcare, or anything touching biometric or heavily regulated data, where predictable performance beats the hassle of maintaining two codebases. That said, it's usually a case-by-case risk call rather than some blanket rule everyone follows.

5. Does migrating off the old React Native architecture actually move the needle?
Teams that move from the legacy bridge to Fabric and Turbo Modules generally see fewer frame drops on complex scroll views and list-heavy screens. The migration itself isn't painless, but for apps where users are complaining about sluggish UI, it's usually worth doing.

6. Should I hire one team for everything, or split the work across specialists?
ull-service teams that handle architecture calls, native modules, and cross-platform tooling under one roof tend to cut down on the coordination headaches you'd otherwise deal with across separate vendors. That's a big part of why larger companies increasingly lean toward one consolidated partner instead of stitching together freelancers per platform.