There are two versions of this question hiding in one. Does Apple read your repository? No. Can Apple, or anyone, see the JavaScript that ships inside your React Native app? Yes. The confusion matters because developers sometimes hardcode a key in JS believing it is hidden inside a compiled app, when the React Native bundle is recoverable from the binary. Here is what Apple actually receives, what it inspects, and why your JS bundle should be treated as visible.
Short answer
Apple does not review your source code in the sense of reading your Git repository. You upload a compiled binary, and Apple reviews that binary against the App Review Guidelines using a mix of automated static analysis and human testing. For a React Native app, though, your JavaScript is bundled inside that binary, and the bundle can be extracted and read by anyone with the file, so anything in it, including hardcoded keys, is effectively visible. So Apple does not get your repo, but it does receive and analyze the binary, and the JS that ships in it is not private. Treat the bundle as readable.
What you should know
- Apple gets a binary, not your repo: you upload a compiled app, not source files.
- Review combines automation and humans: static analysis plus a reviewer testing the app.
- Your JS ships inside the app: the React Native bundle is part of the binary.
- The bundle is recoverable: anyone with the app file can extract and read it.
- Hardcoded secrets are exposed: a key in your JS is not hidden by compilation.
Does Apple get your source code?
No. When you submit, you archive the app in Xcode and upload an IPA, which is a compiled, packaged binary, not your project's source tree. Apple never receives your Git history, your component files, or your build configuration as source. What App Review works with is that binary: automated checks scan it for things like private API usage and policy violations, and a human reviewer installs and exercises the app to evaluate behavior against the guidelines. So in the literal sense people usually mean, Apple does not read your source code. It evaluates the shipped artifact and how the app behaves on a device.
What is actually in the binary you upload?
A React Native binary contains your JavaScript alongside the native code, and the JS layer is the part people misjudge. The table breaks down what ships and how exposed it is.
| Component | What it is | How exposed |
|---|---|---|
| JavaScript bundle | Your RN app logic, bundled and minified | Extractable and readable from the app |
| Hermes bytecode | JS precompiled to bytecode by the Hermes engine | Recoverable; can be decompiled back toward JS |
| Native modules | Compiled Objective-C or Swift code | Compiled, but strings and symbols are inspectable |
| Assets and config files | Images, JSON, plist entries | Readable directly from the bundle |
Whether your JS ships as minified source or Hermes bytecode, it is part of the app bundle and can be pulled out of the binary, so the bundle is not a private container. Minification and bytecode raise the effort to read it, but they do not make it secret.
What does this mean for secrets in your JS?
That a hardcoded secret in your JavaScript is exposed, regardless of Apple's review. Because the bundle ships in the app and can be extracted, an API key, token, or password embedded in your RN code is readable by anyone who unpacks the binary, not just by Apple. The fix is the same as for any client: do not put real secrets in the app at all. Keep secrets on your backend, have the app authenticate and call your server, and let the server hold the privileged keys. Where the app must hold a value, scope it tightly, and rely on server-side rules rather than the value being hidden. Compilation and bundling change how much work it takes to read the JS, not whether it can be read.
What to watch out for
The first trap is assuming that because Apple only sees a compiled binary, your JavaScript is hidden inside it; the bundle is recoverable, so it is not. The second is trusting minification or Hermes bytecode as a security measure, when they raise effort but do not protect a secret. The third is hardcoding keys in JS for convenience and planning to remove them later, which often does not happen before submission. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the strings, keys, and endpoints in the bundle, showing you exactly what is recoverable from your React Native app before you submit. Moving secrets to your backend is the design change you make in response.
What to take away
- Apple does not review your source code or repository; it reviews the compiled binary you upload.
- Review combines automated static analysis of the binary with a human testing the app's behavior.
- Your React Native JavaScript ships inside the binary and is recoverable, so the bundle is not private and minification or Hermes bytecode is not a secret-keeper.
- Keep real secrets on your backend, and use a pre-submission scan such as PTKD.com to see what is actually recoverable from your bundle.
