The tool stack we actually run across 30+ builds, the rule we apply before adding anything, and the three tools we pulled after they cost more than they gave.
Every list of mobile app development tools is the same list. Xcode, Android Studio, Figma, Firebase, Jira, and forty others nobody actually uses together. It is a catalogue, not a stack.
This is the stack we actually run at Codestreaks across 30+ production projects delivered since 2024, what each thing is for, and the three we removed after finding out they cost more than they gave. The removals are the useful part. Anyone can add a tool.
A tool earns its place if it removes a class of failure, not if it is pleasant.
That sounds obvious and almost nobody follows it, because tools get adopted the way they get demoed: someone sees a nice dashboard, adds it, and nobody ever measures whether it changed an outcome. Six months later you have eleven integrations, four of which are load-bearing, and none of the original enthusiasts still work there.
We ask two questions before a tool goes in. What breaks today that this prevents? And who debugs it when it fails at 2am? If the second answer is "the person who set it up", and that person is one contractor, it does not go in.
TypeScript on every project, no exceptions. The compiler catches an entire category of bug that would otherwise reach a physical device, and on mobile a bug that reaches a device is expensive in a way a web bug is not. You cannot hotfix a store build in four minutes.
React Native is our default for cross-platform work, for reasons we set out in our JavaScript mobile development guide. It is a default, not a religion. Two-screen utilities and hardware-heavy apps still go native.
And you still need Xcode and Android Studio installed and current, even on a pure React Native project. Teams try to avoid this and it always ends the same way: someone needs to read a native crash log, adjust an entitlement, or fix a Gradle conflict, and nobody has the tooling. Budget the disk space and the setup day.
The build tooling is solved. Distribution is where mobile teams lose days, and it is worth spending money to fix.
A managed CI that signs builds. Code signing is the single most reliably infuriating part of mobile development, and the value of a hosted CI is not that it compiles faster. It is that certificates and provisioning profiles live in one place rather than on one developer's laptop. The day that laptop dies is the day this pays for itself.
TestFlight and Play internal testing, from day one. Not from beta. From the first working build. Getting distribution working early means it is boring later, and a client who can install the app on their own phone in week two gives you completely different feedback than one watching a screen share.
A cheap old Android device on the desk. Not a tool with a subscription, but it belongs in this list. Everyone's daily phone is fast and new and on office wifi. A three-year-old mid-range Android on a weak connection shows you what your users actually experience, and it shows you in thirty seconds rather than in a support ticket two releases later.
Crash reporting and analytics, and a hard rule that these are the only tools permitted to send an alert.
Crash reporting is non-negotiable. Ship without it and your feedback loop is app store reviews, which is a feedback loop measured in weeks and filtered through people angry enough to write. Sentry or Crashlytics, either is fine, pick one and wire the source maps properly so a stack trace is readable rather than a wall of minified noise. An unreadable crash report is the same as no crash report.
Analytics gets one instruction from us: instrument the funnel you actually care about, and nothing else. Teams instrument everything, generate dashboards nobody opens, and still cannot answer "where do people drop off during signup". Five well-chosen events beat two hundred automatic ones.
One design tool, one issue tracker, one chat. We use Figma, and whatever the client already uses for the other two, because making a client adopt your project management tool for an 8 week engagement is a tax you are charging them for your own convenience.
The thing we insist on is that the issue tracker is the single source of truth for what is in the build. Not chat. Chat is where decisions get made and immediately lost. If it is not in a ticket, it is not happening, and we say that out loud in kickoff.
Three, and each taught us something.
A no-code automation layer between our backend and a client's CRM. It worked beautifully for four months and then became load-bearing. When it broke, the flow was a diagram in a web app that nobody could version, diff, or test, and the person who built it had rolled off. We rewrote it as forty lines of code in an afternoon. Those stacks are genuinely great until something depends on them, and then they are a liability with a nice interface.
A second analytics tool. Added because a stakeholder preferred its dashboards. Now two systems disagreed about the same number, and every metrics conversation started with reconciling them. Delete one. It does not matter much which.
An automated visual regression service. The idea is sound: catch UI drift across devices automatically. In practice it flagged dozens of one-pixel differences per run, the team learned to click "approve all", and it was worse than nothing because it looked like coverage. A test suite everyone ignores is a false sense of safety, which is more dangerous than a known gap.
A client asked us to audit why their release cycle had stretched to five weeks for what should have been fortnightly.
The cause was not a missing tool. They had eleven. It was that their signing certificates lived on a single machine belonging to a developer who had left, so every release required a manual dance involving a shared password and a specific laptop. Everything else, all eleven tools, was fine. That one gap set the pace of the entire team.
We moved signing into their CI in two days. The release cycle went back to fortnightly. Nobody bought anything.
That is the pattern more often than not. The bottleneck is rarely the tool you do not have. It is the one manual step everyone has normalised.
If the budget is small, spend it in this order.
First, managed CI with signing. It removes a class of failure and a single point of human dependency.
Second, crash reporting with a real retention window, because the free tiers drop data right when you need to look back at a pattern.
Third, real devices. Not a device farm subscription. Two or three actual mid-range handsets you can hold.
Everything after that is comfort. Useful comfort sometimes, but comfort. If you are still choosing a delivery model, our custom mobile development guide covers what changes when the whole build is bespoke.
At minimum: the native IDEs (Xcode and Android Studio), a version control host, a CI that can sign and distribute builds, crash reporting, and a design tool. Everything beyond that is optimisation. Teams routinely run twenty tools and are blocked by a missing one from that core five.
For most business apps, React Native, because one codebase with native rendering means a fix ships to both stores together rather than drifting. Go native when you need deep hardware access or sustained heavy computation on the device. Use a webview approach like Capacitor when a strong responsive web app already exists and you mainly need store distribution.
Partly. Cross-platform work adds a layer (React Native, Capacitor) but does not remove the native tooling underneath. You still need Xcode and Android Studio for builds, signing, and reading native crashes. Anyone promising you will never touch them has not maintained a cross-platform app across an OS release.
Most teams do not. A device farm is worth it when you support a wide range of low-end Android hardware and have automated tests worth running across it. Below that, two or three real mid-range devices catch more real problems for far less money and effort.
When nobody can name what each one prevents, you have too many. We audit ours by asking, for each tool, which specific failure it stops and who fixes it when it breaks. Anything that fails both questions comes out.
Written by the Codestreaks team. Abdullah, our co-founder, is a senior mobile app developer based in Austin, TX. This is our real stack across 30+ production projects delivered since 2024, including the three tools we removed and why. The five-week release cycle audit and the certificate-on-a-departed-developer's-laptop finding are from a real client engagement, retold without naming them. Drafting is AI-assisted with a human editing pass against our own delivery history. We have not listed tools we do not use.
If your releases are slower than they should be and you suspect it is process rather than tooling, that is usually a short conversation. Free 30-minute call, reply within two business days.
More on how we build on our mobile app development service page, or start a project.
A serial maker of SaaS products and AI agents, I’ve built and launched 10+ tools, grown products to thousands of users, and taken multiple ventures. I share the process what works, what breaks, and how builders can ship faster and smarter. Previously a data scientist at a Big Four consulting firm.
