A generated project is the app on the phone, and nothing that runs anywhere else.
What a generated React Native and Expo project does not include is everything that lives off the device. No server of your own, no account system, no shared database, no analytics, no crash reporting and no test runner wired up. The code for the app is complete and it runs. The services that app will need are a separate list, and that list is yours. This is not a gap somebody left in a generator. It is where the frameworks draw their own edges: Expo's SDK reference describes its packages as access to device and system functionality such as camera, contacts, location, sensors and haptics, and React Native's security guide says in as many words that React Native does not come bundled with any way of storing sensitive data.
What follows is the inventory. What the project already contains, which absences you can ignore, which one costs you a customer in the first week, and what each gap takes to close. Every claim here that something is absent was checked on the page where it would be, and those pages are named as they come up. All of them were read on 17 October 2026.
See what is in the boxThe short version
The app arrives finished. The accounts do not.
A mobile app is two halves. One half is a program installed on a handset, and that is what a React Native and Expo project is, all of it. The other half is whatever answers that program when it asks a question. Who is this person. What did they buy. Is there a newer version of this list. None of that is in a project, because none of it can be. A server is something that runs somewhere and costs money every month, and no folder of files is one.
So the useful question is not what is missing. It is which of the missing things your app actually promised. An app that keeps everything on one phone, a notes app or a calculator or a checklist, is finished and needs nothing from this page. An app with logins, sync, payments or notifications needs accounts with three or four other companies before it works for a second person. Working out which one you are takes five minutes and it changes every estimate you give after that.
What is in the box, and where does the box end?
The box is the phone. Expo's SDK reference, version 58 when it was read on 17 October 2026, describes the SDK as a collection of packages that provide access to device and system functionality such as camera, contacts, location, sensors and haptics. Its Expo SDK group lists 90 of them. Read the names and the pattern is plain: calendar, clipboard, contacts, camera, haptics, location, notifications, print, speech, splash screen, sqlite, secure store. Every one is a thing the handset itself can do.
A second group in the same reference lists 21 third-party entries, and that is where the edge of the box shows. Gesture handling, maps, the webview, async storage and Stripe's React Native library all sit in that group rather than the first one. Expo's own description of the group is careful: a curated list of third-party libraries that are community driven, provide APIs for common app functionality, and are tested with each Expo SDK release, with support for them built into Expo Go. Community driven is the operative phrase. Expo documents them and installs them with one command, and the people who answer when one of them breaks are not the people who wrote your framework.
What is in neither group is the point of this page. No analytics service. No hosted database. No account system. There is a package called expo-server, and it is worth knowing exactly what it is: a server-side runtime for Expo Router API routes, which you switch on by exporting the project in server mode and then deploy with one of its adapters. A project nobody set up that way contains none of it. The nearest thing to monitoring in the list is expo-observe, and that reports into a hosted Expo service you sign into.
One more thing about the box: its contents move. The same reference says new Expo SDK versions are released three times each year, and the list shifts with them. Community packages become first party, and a legacy version appears beside a new one, which is why the index carries both a calendar and a calendar legacy entry. Before you conclude that something is missing from your own project, check which SDK you are on and read the Expo SDK release notes, because the answer changes with the number.
Expo, SDK reference for version 58.0.0, read 17 October 2026
Check yours
What your app promises, and what it still needs
Tick what your app is supposed to do. The answer says what the project already contains and what has to be opened, wired up and paid for.
Nothing ticked. An app that keeps everything on one phone, with no accounts and no sync, is already finished and needs none of this.
Why is there no backend, no accounts and no database?
Because those are services rather than code, and both frameworks say so on their own pages. Expo's Database page, last modified 17 September 2026, opens by saying that most apps need to persist data beyond the lifetime of a single session, then offers three ways to do it: Convex, Supabase and Firebase. Three outside companies. Expo documents how to connect a database to your app. It has none to give you.
Authentication is the same story told at greater length. Expo's Authentication page, last modified 16 October 2026, says implementing authentication involves more than writing client-side code, and names what else: server requests, password flows, third-party providers like Google or Apple, email handling and OAuth standards. Its own summary of the subject is that auth is hard, and its Auth solutions section lists Better Auth, Clerk, Supabase, Cognito and Firebase Auth. What the SDK gives you is the client half. expo-auth-session for OAuth, expo-apple-authentication, and expo-local-authentication for Face ID and Touch ID. The same page is careful about that last one: a biometric prompt alone does not authenticate with your server. It is a lock on the door of a house that may not have been built.
Then the detail that catches people, and it is in React Native's own words. React Native does not come bundled with any way of storing sensitive data. So when an auth provider hands back a token, the project you were given has nowhere documented to put it. The security guide sends you to Keychain Services on iOS, and to Encrypted Shared Preferences or the Keystore on Android, through a library such as expo-secure-store or react-native-keychain. It also prints a two column table for async storage, and the entries in the do-not column are token storage, secrets, and global app-wide variables.
A database on the device does exist, and it is the easiest thing on this page to mistake for the real one. expo-sqlite is in the reference, async storage is one command away, and both work perfectly. They are also one device, unencrypted, and gone when somebody deletes the app. If two people have to see the same list, or one person has to see it on a tablet as well, a phone-local database is not a smaller version of the answer. It is a different answer, and swapping one for the other later is the migration nobody budgets for.
React Native, Security, page last updated 12 August 2026, read 17 October 2026
Who tells you the app is broken, if nobody is watching?
Nobody does, and of all the absences on this page this is the one that costs money, because the alternative to a crash report is a one star review that tells you less. A generated project ships with no analytics and no crash reporting. Expo's analytics guide, last modified 14 August 2026, is a list of other companies' products: Firebase Analytics, Segment, Amplitude, AWS Amplify, Aptabase, Astrolytics, PostHog and Dreambase. Eight providers, and no Expo analytics package among the 90 in the SDK group.
The same guide carries the practical warning, and it is the reason this job slips. Most analytics SDKs require configuring custom native code, which is not configurable when using Expo Go, so you need a development build. In plain terms, the quick way you have been opening the app on your own phone will not run the version with analytics in it. That is a one-off afternoon rather than a crisis, but it is an afternoon, and afternoons are what get postponed into month four.
Expo does sell two monitoring products of its own, and anyone saying Expo offers nothing here is wrong. Its Monitoring services page, last modified 17 September 2026, names EAS Insights and EAS Observe beside Sentry, BugSnag, LogRocket and PostHog. The expo-observe page inside the SDK reference is specific about price: EAS Observe includes 100,000 events per month on the free plan and 500,000 on paid plans, which it puts at roughly 10,000 and 50,000 monthly active users, with usage-based pricing above that. It is also not available in Expo Go. So the gap is cheap to close, it is not free, and closing it is still something a person has to sit down and do.
Tests belong in this section for the same reason. Expo's Unit testing guide, last modified 13 October 2026, begins after your project exists: install jest-expo, jest and the Jest type definitions as dev dependencies, add a test script, add jest-expo as the preset in package.json. Four steps somebody has to run. If nobody ran them on your project, there is no test runner in it, and a tidy looking repository will tell you nothing at all when you change a screen.
Expo, SDK reference, on the Observe package and the Expo SDK package list, read 17 October 2026
What does an open gap actually cost you?
Three prices, paid at different times. The first is a monthly bill, and it is the one people worry about and the least dangerous, since nearly every service named on this page starts free and invoices you only once the app is working. The second is the afternoon. A gap closed while the project is small is a package and a key. The same gap closed after launch is a migration, and anything touching accounts means asking real people to log in again.
The third price is the only one that bites, and it is the temptation to close a server-side gap inside the app. React Native's security guide is blunt. Never store sensitive API keys in your app code, because anything included in your code could be accessed in plain text by anyone inspecting the app bundle. Its suggested fix is an orchestration layer between the app and the resource, for example a serverless function that forwards the request with the key attached, because secrets in server side code cannot be read the way secrets in app code can. Read that twice if you are about to paste a key into a configuration file. A shipped app is a file on a stranger's computer. The same page says deep links are not secure and that you should never send sensitive information in them, for the same family of reasons.
The store side has its own gaps and no package covers them. The listing, the screenshots, the privacy answers and the account that legally owns the app are all yours, in two consoles, and they are usually met on the day you wanted to ship. The order of operations is written out in publishing to the App Store, and reading it before the build is a great deal cheaper than reading it after.
There is one cost with no technical fix. Every service above becomes something you run. Somebody holds the password, notices the invoice, and answers the email when it falls over on a Sunday. That is the part no project file can contain, and it is most of what an app costs to maintain. Count the services before you count the lines of code, because the services are the ones that send letters.
React Native, Security, on API keys in the app bundle and on deep links, read 17 October 2026
What is in the project, and what each gap takes
Twelve pieces of a working app. Two of them are already in the project you were handed, one is half there, and the other nine are accounts with other companies. The right week to find that out is this one.
| The piece | In the project | What it actually takes |
|---|---|---|
| Screens, navigation, icon and splash screen | Yes | Already there. Expo Router and the app config are part of the framework. |
| A database on this one phone | Yes | expo-sqlite and async storage. Unencrypted, one device, gone when the app is deleted. |
| Receiving a push notification | Half | expo-notifications receives and schedules. Push itself needs a development build, not Expo Go. |
| A server of your own | No | Expo Router API routes with expo-server, exported in server mode and deployed somewhere, or a service you rent. |
| User accounts and password resets | No | An auth provider. Expo lists Better Auth, Clerk, Supabase, Cognito and Firebase Auth. |
| A database everyone shares | No | A hosted one. Expo's Database page names Convex, Supabase and Firebase. |
| Somewhere safe for a login token | No | React Native bundles nothing for this. expo-secure-store or react-native-keychain. |
| Sending a push notification | No | Something you run. By Expo's own definition a push notification comes from a remote server. |
| Analytics | No | An SDK and an account. Most of them need custom native code added to the project. |
| Crash reports from real phones | No | Sentry, BugSnag, LogRocket, PostHog or EAS Observe, plus a development build. |
| A test runner | No | jest-expo, jest, the type definitions, a preset line in package.json, then tests somebody writes. |
| The store listing and the privacy answers | No | Yours, in both consoles. No framework package covers any of it. |
Where this lands if a builder generated your app
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so every file discussed above is one you can clone and read. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the provider of the app's content to submit. It is $25 a month and there is no free plan. If React Native and Expo are new words to you, read what React Native is first and come back.
Generation moves the line in one direction. The screens, the navigation, the icon, the splash screen and the local storage arrive done, and that is the tedious half of a project rather than the clever half. What no builder can do is open an account in your name. A payment processor wants your company details. A store account wants a legal entity and the paperwork that comes with one. An analytics provider wants somebody with authority to accept its terms. Those are signatures, not code, and an agent cannot sign.
So the honest shape of a generated project is a finished client and an empty address book. The launches that go wrong are the ones where somebody read the first half, assumed the second, promised a date, and discovered in week three that sign in means a vendor, a bill and a decision about where customer data is allowed to live. None of that is hard. It is just not in the folder, and it is better found now than in the week of the launch.
Questions people ask about what is not in a generated project
Everything that lives off the device. No server of your own, no account system, no shared database, no analytics, no crash reporting, no push sending and no test runner configured. The app itself is complete: screens, navigation, the icon, the splash screen and local storage all arrive working. Each absence was checked on the page where the thing would be, read on 17 October 2026: the Expo SDK reference for version 58, Expo's Database, Authentication, analytics, Monitoring services and Unit testing pages, and React Native's Security guide.
Write the list of services before you write the date
Go back up the page and tick what your app actually promises. Each tick is an account somebody opens, a password somebody keeps and a bill somebody pays. That list is short at the beginning, and it is the only part of the project nobody can generate for you.
Start building