Mobile App Development Tools That Actually Survive Launch
Building a mobile app means committing to decisions that are expensive to reverse: your runtime, your backend, your billing layer. Most of the tooling debate online is about editors and frameworks, which are the cheap decisions. The expensive ones are the store accounts, the subscription plumbing and the analytics you wish you had installed before launch rather than after the drop-off.
Don't pay full price to build this.All 49 App Development tools below come with a discount code, a startup programme or free credits.Claim these perks →
Runtime first, because everything else follows from it
React Native and Flutter both ship one codebase to two platforms, and both are genuinely production grade now. The difference shows up at the edges. Anything touching the camera, Bluetooth, background location, home screen widgets or platform payments will eventually need native code, and the real question is whether your team can write that code confidently on the day it becomes necessary.
Native Swift and Kotlin roughly double your build effort and buy you predictable access to every platform API on the day it ships. If your app is a thin client over an API, cross-platform wins easily. If the device hardware is the product, native wins, and the cross-platform detour only delays a rewrite you will pay for anyway.
This choice also fixes your hiring pool and your CI configuration for years. Swapping runtime later is not a refactor, it is a rebuild. Spend a week prototyping the single hardest screen in both candidates before committing, rather than choosing on a benchmark someone published about an app that looks nothing like yours.
The store gatekeepers you cannot route around
Apple and Google both charge for the right to publish, and neither fee is negotiable for a commercial company. Apple bills annually, Google bills once at registration. Budget for both on day one, because you need live accounts long before launch to test push notifications, in-app purchases, deep links and the TestFlight or internal testing tracks your beta depends on.
Review is the part that breaks schedules. Apple rejects builds for missing account deletion, unclear subscription terms, placeholder content, and privacy labels that do not match what the app actually collects. Every rejection costs a full round trip. Read the guidelines properly once, before submission, instead of discovering them one rejection at a time while your launch date slides.
Set both developer accounts up before you need them. Apple's organisation enrolment requires a legal entity and a verified D-U-N-S number, and that check regularly takes longer than the rest of your launch preparation combined. Founders who leave it until the build is finished lose weeks sitting on a verification email they cannot chase.
Backend: buy it, do not build it twice
Firebase and Supabase both hand you a database, authentication, file storage and serverless functions behind a mobile SDK. Firebase is the deeper mobile toolkit, with crash reporting, remote config and messaging sitting in the same console. Supabase is Postgres, which means real SQL, real relations, row level security and a credible exit if you ever want to self-host.
The trade-off is lock-in against leverage. Firebase's document model makes early screens fast to build and complex queries painful once the relationships between records start to matter. Postgres makes your first week slower and everything after that considerably easier. Choose on whether your data has relationships between users, teams and content, not on which console has the nicer dashboard.
Both run free tiers that carry a real product further than most founders expect, and both operate startup programmes that extend those tiers well past the point where a side project would have started paying. Applying takes about an hour, and the credit usually lands before you have finished designing the schema.
Subscriptions are plumbing, and the plumbing leaks
In-app purchase is not a payment integration, it is a receipt validation problem. StoreKit and Play Billing each return signed receipts that your server has to verify, store and then re-check on renewal, refund, upgrade, downgrade, grace period and billing retry. Getting every one of those states right is weeks of engineering that ships no visible features.
RevenueCat exists because almost every subscription app writes that layer badly at least once. It normalises both stores behind a single SDK, handles restore purchases across devices and reinstalls, and gives you cohort revenue reporting you would otherwise assemble by hand in SQL. It stays free until your tracked revenue is meaningful, so hand-rolling it first is a poor trade.
Whichever route you take, test refunds, cancellations and expiries in the sandbox before you launch. The most common production bug in paid apps is not a failed payment. It is a cancelled subscriber who keeps full access indefinitely because nobody wired the expiry webhook to actually revoke entitlement.
Instrument before launch, not after the drop-off
Retention is the only mobile metric that predicts anything, and you cannot compute it retroactively from data you never collected. Install product analytics before your first external tester, define the four or five events that genuinely mean a user reached value, and name them carefully. Renaming events after launch splits every historical cohort and quietly destroys your baseline.
Mixpanel and Amplitude both handle funnels, cohorts and retention curves well, and both run startup programmes that put you on a paid tier free for a year. Pick one and commit. Running two analytics SDKs doubles your event maintenance and guarantees the numbers disagree at exactly the moment an investor asks which figure is correct.
Pair analytics with crash reporting from your very first internal build. Mobile crashes are silent. The user does not file a ticket, they uninstall and never return. A crash-free session rate drifting downwards after a release is usually the earliest signal you get that something shipped broken.
The editor layer, and what the stack costs in year one
AI assisted editors have quietly become the highest leverage tool in mobile work, largely because they are strong at the boilerplate that dominates it: view models, serialisation, platform channel bridging, localisation files and test scaffolding. Cursor runs a founder route onto its paid tier, and GitHub Copilot comes free with the Student Developer Pack, which covers a surprising number of early teams.
Now add the whole thing up honestly. Two store accounts, a backend, a billing layer, product analytics, crash reporting and an editor subscription. At list price that is a real recurring line item before you have taken a single payment, and it arrives in the months when you have the least appetite for recurring line items.
Nearly every component above runs a startup or founder programme that removes most of that cost for the first year. The catch is that they sit behind a dozen separate application pages with different eligibility rules, and most expire on a fixed window from approval rather than from first use. The app development section of this directory collects the ones worth applying for with their current terms attached, so you can claim them in an afternoon and stagger the expiry dates deliberately.
The offers mentioned above
Pulled live from the directory, so what you see here is what the listing says.
Firebase
Developer Tools
No-cost usage tier plus $300 credit if eligible
CreditsDirect link
Supabase
Developer Tools
$500
CreditsCode on plan
RevenueCat
Developer Tools
Free under $2,500/mo revenue
Free planLink on plan
Mixpanel
Data & Analytics
1 year free (worth $145,000)
Free periodLink on plan
GitHub
Developer Tools
$10,000 in credits
CreditsLink on plan
Also mentioned on this page with nothing currently on offer: Apple Developer Program. We track them so you do not have to go looking.
App Development codes, all in one place
49 listings in App Development, with the redemption codes and programme links behind one subscription. Browsing is free.
Common questions
Do I need both an Apple and a Google developer account?
If you publish on both stores, yes, and there is no way around either fee for a commercial app. Apple charges annually and Google charges once at registration. Open both early, because Apple's organisation verification is slow and blocks TestFlight.
Is cross-platform good enough for a real product?
For anything that is essentially a client over an API, comfortably. React Native and Flutter both run large commercial apps. Native still wins where the hardware is the product: heavy camera work, audio processing, background location or tight watch and widget integration.
Do I need RevenueCat if I only sell one subscription?
Usually yes. The complexity is not in the number of products, it is in renewal, refund, grace period and cross-device restore handling, which is identical whether you sell one plan or ten. It is free below a meaningful revenue threshold.
Which analytics tool should I install first?
One, not two. Mixpanel or Amplitude both give you retention cohorts and funnels, and both offer a year free through their startup programmes. Choose on which query builder your team finds readable, then define your event names before you write them.