One night I was rebuilding the settings screen of a wallpaper app, and when the generation finished I opened the preview on my phone. Black. No red error screen, nothing to read, nothing to point at.
What I'd like to say up front is that a black screen is not one symptom. The cause can sit in at least three places, and each one is fixed by a different person or tool. Early on I skipped that step and sent the same "it's black, please fix it" request again and again. It didn't go well.
A black screen stops in one of three places
| Layer | What is happening | Where to look |
|---|---|---|
| 1. Device and app | Expo Go can't open the project | Logins, reload, cache |
| 2. Rendering | The app runs, but nothing visible is drawn | Conditions and colors in the generated code |
| 3. Native | The app crashes right after launch | Device logs |
Work from the top. Each layer you rule out makes your next request to the AI more specific.
1. Rule out the device and app first
If scanning the QR code shows nothing at all, suspect the step before your generated code. Since September 2026, running a project in Expo Go requires a login, and the terminal side and the app side both need to be in a matching state. I wrote up the order of checks separately:
- Two logins to check first when Expo Go stops opening your preview
- Fixing a Rork Companion preview that won't run
The question to ask here is simple: does fully closing the app and reopening it change anything? If it does, the problem was device state, not code.
2. Then suspect rendering
Expo's debugging guide suggests reading the stack trace and, when that gives you nothing, going back to a working version and re-applying changes one at a time. With a silent black screen, the second approach is the one that pays off.
As an indie developer I've tripped over the same three things in my own apps:
- A black background with black text, because a dark-theme setting only took effect on one of the two
- A component that returns
nulluntil data arrives, and the data never does - A parent View with no height, so its children collapse to zero
The fastest way to tell them apart is a temporary diagnostic component placed at the top of the screen:
import { View, Text } from "react-native";
// Diagnostic only: checks whether content is hiding against a black background.
// Remove it once you've seen the result.
export default function DebugBanner({ label }: { label: string }) {
return (
<View style={{ backgroundColor: "#ffd54f", padding: 12 }}>
<Text style={{ color: "#000", fontWeight: "700" }}>{label}</Text>
</View>
);
}If the yellow banner shows, the app is alive and whatever sits below it is rendering nothing. If it doesn't, the stall happens earlier — device or native.
3. Check whether the app crashes natively
No banner and no change after a reload usually means the app is dying right after launch. Expo's documentation treats native crashes as a log-reading job:
- Android: stream device logs with
adb logcat - iOS: open the Console app on a Mac, pick your device, and start streaming
If you're on Windows only, you don't have to chase this one. Knowing that it crashed is already enough to word your next request.
Change what you tell the AI
Rork's FAQ says AI errors don't cost credits, offers Restore to return to an earlier working version, and suggests asking Rork to search the web or switching models when you're stuck. So trying again isn't something to fear.
What changes is the wording:
- Banner visible: "The screen runs, but the list area draws nothing. Check whether it returns null before the data loads."
- No banner: Restore the last working version first, then re-request changes one at a time.
"It's black" leaves the AI guessing. One sentence about which layer stalls narrows the fix a lot.
Three lines to attach to your request
Whatever you found can go straight to the top of your prompt. This is the shape I use:
Stalled at: layer 2 (rendering)
Checked: yellow banner is visible; closing and reopening the app changes nothing
Suspect: the list screen may return nothing before data has loadedWith those three lines, the fix that comes back is less likely to drift toward "rebuild everything." Without them, repeated requests can rewrite parts that were working. When that happens, restoring the last working version and starting over usually ends up faster.
Before asking again, be able to say in one sentence where it stops. I keep to that rule hardest on tired nights.
Next time you meet a black screen, drop in the yellow banner before you send anything. Whether you see it decides which screen to open next.