An earlier version of this article stated flatly that machine-learning optimizations run inside Rork. Reading it again, I can see I filled the gaps in the official documentation with impressions and guesses: the name of a dedicated optimizer component, a table of features by plan, and a tidy set of benchmark figures. If you went looking for that API, I apologize for the lost time.
So I have rewritten it. This version separates what can be verified from what is only a hunch, and then walks you through measuring the lightness of your own app.
What I most want you to know: what can actually be said
Rork generates Expo and React Native projects. Most of the "lightness" people notice is explained by standard Expo and React Native behavior rather than anything unique to Rork.
| What you notice | A factor you can verify | Specific to Rork? |
|---|---|---|
| Fast startup | Hermes precompiles JavaScript to bytecode | It is an Expo default |
| Small bundle | Metro dead-code removal, and few dependencies | Depends on which packages the generation picked |
| Smooth images | expo-image caching and placeholders | A library feature |
| Stable lists | A virtualized list such as FlatList is used | A matter of how the code was written |
What the model does internally during generation is not visible from the outside. If an app feels light to me, I cannot tell whether machine learning deserves the credit or whether the app simply has few dependencies and a plain structure. I think the honest thing is to say that I do not know.
Lightness usually means "nothing extra got in"
When I rebuilt one of the wallpaper apps I run on my own, every feature I added made startup heavier, and my stomach tightened each time. Tracing it back, a large package I no longer used was still being loaded at launch.
The same dynamic may explain why a generated app feels light. With minimal dependencies, screens that each own one job, and simple state handling, an app tends to stay light by itself.
So the question worth asking is less "what did Rork do?" and more "what is in my project right now?"
Step 1: Export the bundle and look inside
Export the project and check the size of the output.
npx expo export --platform ios
ls -lh dist/_expo/static/js/ios/The size of the generated bytecode gives you a rough sense of how heavy the JavaScript is. The number shifts with the device and the SDK version, so write it down as the baseline for your project. Run the same command after each feature and you will see how much each one added.
If you want a per-dependency breakdown, pair this with a bundle visualizer. For ways to bring the size down, see When Your Rork App Binary Tops 150MB: 5 Causes to Isolate and a Step-by-Step Slim-Down Plan.
Step 2: Measure cold start on a real device
Measure on a physical device, not the simulator. Repeating the same action about five times and recording the median is realistic.
- Fully quit the app, then launch it (a cold start)
- Time from launch until the first screen accepts input
- Measure at least once on a low-end or older device
Screen-recording and stepping through frames is enough to see the trend. What matters is being able to compare before and after a change, not precision. The concrete ways to shorten startup are covered in Practical Techniques to Cut the Startup Time of Rork-Generated Apps.
Step 3: Stress the lists and the images
Heavy screens tend to cluster around lists and images.
For lists, push a few hundred rows in and scroll to see whether frames drop. If they do, it is time to revisit how the list renders. The migration steps are in When Your FlatList Starts Stuttering: Migrating Rork Apps to FlashList v2.
For images, the disk cache growing over time matters more than display speed. The longer an app lives on a device, the more its "Documents & Data" quietly swells. See Your Rork App's 'Documents & Data' Keeps Growing — Taming expo-image's Disk Cache for the fix.
Guardrails for keeping performance after you add your own code
Adding hand-written code to a generated app can make it suddenly heavy. These are the lines I try to hold.
- Before adding a dependency, pause and ask whether you truly need it
- Render long lists with a virtualized list component, always
- Load images close to their display size through
expo-image - Push heavy work until after the first screen has appeared
None of this is special technique. It is a modest brake that helps you keep the plain structure the generation gave you.
Telling Rork what you care about
When you ask Rork to generate something, a line about performance can help the result land closer to your intent. For example: "Prioritize running on older devices," or "The list screen shows many images."
I have no evidence, though, that this "triggers" a particular optimization. Treat it as a rule of thumb: stating the conditions tends to bring back a structure nearer to what you meant. Verify the outcome with Steps 1 to 3 every time.
Wrapping up
Speak about a generated app's lightness with your own measurements, not with rumors. That is the line I was reminded of while rewriting this.
As a next step, export the bundle of a Rork-built app you have at hand and record a single baseline number. One number is enough to make your next "should I add this?" decision far calmer.