What does guideline 4.2 actually say, word for word?

The section is called Minimum Functionality and it opens: Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or app-like, it doesn't belong on the App Store. If your App doesn't provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Then come the numbered clauses. 4.2.1 is about ARKit. 4.2.2 is the one about web clippings and collections of links. 4.2.3(i) says your app should work on its own without requiring installation of another app to function. 4.2.4 and 4.2.5 are marked Intentionally omitted, which is worth knowing because older copies quoted in forum threads number things differently. 4.2.6 is the app generation service clause. 4.2.7 covers remote desktop clients and ends with the line that thin clients for cloud-based apps are not appropriate for the App Store.

Can I use a web view for one screen in a React Native app?

Yes, and plenty of shipped apps do it for a help centre, a terms page or a third-party checkout. Two things to know. First, a web view is not a React Native Core Component. Checked on 17 October 2026, the Core Components and APIs list in the 0.87 documentation does not contain one, and React Native's own guide to installing community libraries uses react-native-webview as its worked example of a library that includes native code. Second, if people browse the open web inside it, guideline 2.5.6 says apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript, with an entitlement route for an alternative engine in the EU and Japan.

Does Apple care that an AI generated the code?

It cares who submits it. Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, that these services should not submit apps on behalf of their clients, and that they should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. So the builder uploads the build and you submit it. Nothing in 4.2 is softened or hardened by who typed the code. The app is judged on what it does.

Articles · GuidesUpdated October 2026

React Native versus a wrapped website: Apple's rule names the outcome, not the technology.

Q: Is a React Native app a webview app?

No, and React Native's own documentation is specific about why. Its Core Components and Native Components page says that in Android development you write views in Kotlin or Java and in iOS development you use Swift or Objective-C, and that with React Native you invoke those same views with JavaScript using React components. At runtime, React Native creates the corresponding Android and iOS views for those components. The View documentation says View maps directly to the native view equivalent on whatever platform React Native is running on, whether that is a UIView, a div, android.view, and so on. The web equivalents appear in React Native's own table under a column headed Web Analog, which is the framework saying that the web thing is the analogy and not the implementation.

Q: How do I tell whether I was handed a React Native app or a wrapped website?

Open package.json. React Native and Expo projects list react-native and expo as dependencies, and an Expo project has an app.json or app.config file next to it. A bundled web app in a native shell looks completely different: an index.html, a www or dist folder of built web assets, and a Cordova or Capacitor dependency. The second check is behavioural. Put the phone in airplane mode and open the app. A wrapped site shows you a blank screen or a browser error. A native project usually still renders its shell, its navigation and whatever it keeps on the device.

Q: If my app renders native views, does that mean it passes guideline 4.2?

No, and this is the mistake worth avoiding. 4.2 is a test on the app, not on the stack. An app built out of real UIView and ViewGroup instances that still does nothing but show the pages of your website has the same problem as the wrapper: there is nothing in it that elevates it beyond a repackaged website. The framework changes what the app is made of. You still have to give it a reason to be on a phone, which usually means something the website cannot do, such as offline data, a camera, notifications or a saved identity.

A wrapped website loads your site into the app and hands it to the system browser engine to draw. A React Native app creates real iOS and Android views at runtime, and React Native's own documentation says exactly that. Apple's App Store Review Guidelines, meanwhile, never mention a web view at all. Guideline 4.2 is written about a result, a repackaged website, and that is the sentence your app gets measured against. Both quotes are below, taken from the two sources that own them and read on 17 October 2026.

If a builder handed you a React Native and Expo project, you are on the far side of that line by construction. What follows is how to prove it in four seconds, which guideline clauses actually apply, and the one place where having real native views still will not save you.

Start here

The short version

Apple bans a result. React Native changes a mechanism.

These are two separate claims and most arguments about them collapse the two. The guideline is a judgement about your finished app. The framework is a fact about how pixels get on the screen. A project can satisfy the second and fail the first.

One detail settles a lot of noise. The words web view, webview, wrapper and hybrid do not appear once in the App Store Review Guidelines. The whole document was read on 17 October 2026, and it carries its own Last Updated line of 16 October 2026. The word repackaged appears exactly once, in 4.2. The phrase web clippings appears exactly once, in 4.2.2. So the thing people argue about on forums is not a phrase Apple has written down.

React Native is just as plain in the other direction. Its documentation describes itself as a framework for building Android and iOS applications using React and the app platform's native capabilities, and says that at runtime it creates the corresponding Android and iOS views for your components. No HTML document, no page load, no browser engine drawing your interface.

What does guideline 4.2 say about an app that is mostly a web view?

Section 4.2 is called Minimum Functionality and it opens with the sentence everyone half remembers. “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn't belong on the App Store.” It continues: an app that does not provide some sort of lasting entertainment value or adequate utility may not be accepted. Notice what is missing. There is no technology named, no framework approved, no rendering method forbidden. The test is the app.

The clause that gets closest to a wrapped site is 4.2.2. “Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” The operative word is primarily. A catalogue is explicitly carved out. A single screen of terms and conditions pulled from your site is not what this describes. An app whose every screen is a page of your site is.

Three more clauses matter to anyone shipping an app that leans on the network. 4.2.3(i): your app should work on its own without requiring installation of another app to function. 4.2.3(ii): if your app needs to download additional resources in order to function on initial launch, disclose the size of the download and prompt users before doing so. And at the end of the remote desktop rules, 4.2.7 closes with a line that is quietly the strictest sentence in the section: thin clients for cloud-based apps are not appropriate for the App Store. Between them they describe an app that is an empty frame until the server fills it.

Web content is not contraband, and two other sections prove it. Guideline 2.5.6 assumes some apps browse the web and tells them how: apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript, with an entitlement available for an alternative browser engine in the EU and Japan. Guideline 4.7 goes further and permits software that is not embedded in your binary, naming HTML5 and JavaScript mini apps and mini games, streaming games, chatbots and plug-ins, while making you responsible for all of it. It also sets a limit worth reading twice if you were planning to bolt web screens onto native features: 4.7.2 says your app may not extend or expose native platform APIs or technologies to the software without prior permission from Apple.

One housekeeping note that saves an argument. 4.2.4 and 4.2.5 both read “Intentionally omitted.” Older copies of the guidelines quoted in forum threads number these clauses differently, so a rule someone insists is 4.2.4 may not exist in the current document at all. Read the live page before you believe a number.

Apple, App Store Review Guidelines, Last Updated 16 October 2026, read 17 October 2026

What does React Native's documentation say it produces instead?

It defines itself in one sentence: an open source framework for building Android and iOS applications using React and the app platform's native capabilities. The mechanism comes two paragraphs later and is worth having in full. “In Android development, you write views in Kotlin or Java; in iOS development, you use Swift or Objective-C. With React Native, you can invoke these views with JavaScript using React components. At runtime, React Native creates the corresponding Android and iOS views for those components. Because React Native components are backed by the same views as Android and iOS, React Native apps look, feel, and perform like any other apps.” The docs call them Native Components, and that name is the whole argument in two words.

The documentation for the most basic component says the same thing at the level of a single box on screen: View maps directly to the native view equivalent on whatever platform React Native is running on, whether that is a UIView, a div, android.view, and so on. So when you write a container in a generated project, the thing that exists on an iPhone is a UIView. Not a div inside a browser that happens to look like one.

The clearest evidence is a table React Native publishes itself, reproduced below. Look at the last column. The framework lists the web equivalents under a heading that reads Web Analog, which is the documentation telling you the web version is the analogy and not the implementation. A wrapped website only ever reaches that column. A React Native app lands in the two before it.

What you write	What exists on iOS	What exists on Android	Web analog, per the docs
View	UIView	ViewGroup	A non-scrolling div
Text	UITextView	TextView	p
Image	UIImageView	ImageView	img
ScrollView	UIScrollView	ScrollView	div
TextInput	UITextField	EditText	input type text

Your JavaScript still has to run somewhere, and that somewhere is not a browser. React Native's documentation describes Hermes as an open-source JavaScript engine optimized for React Native, and says it is used by default with no additional configuration required to enable it. A JavaScript engine executes your code. A browser engine parses documents, lays out HTML and paints it. That difference is why the output of the one is native views and the output of the other is a web page. If you want the layer below this, the details of Hermes and the new architecture are where the current rendering path is described.

One honest caveat, because the page carries it itself. Partway down, React Native warns that the documentation references a legacy set of API and needs to be updated to reflect the New Architecture. That warning sits above the section on writing your own components, not above the component mapping, and the mapping is the part quoted here. Still worth knowing that the framework flags its own stale corners, which is more than most sources do.

React Native, Core Components and Native Components, version 0.87, last updated 12 August 2026, read 17 October 2026

How do you tell which one you were handed?

Open package.json. This is the fastest honest answer and it does not require trusting anybody's marketing. A React Native and Expo project lists react-native and expo in its dependencies, and sits next to an app.json or an app config file. A bundled web app in a native shell looks nothing like that: an index.html at the root, a www or dist folder of built web assets, and a Cordova or Capacitor dependency. If you find the second shape, stop reading the parts of this page about native views, because none of them apply to what you own.

Finding react-native-webview in the list is not a bad sign and does not make the project a wrapper. It is a community library you install on purpose, usually for a help centre, a legal page or a third-party checkout. Two facts place it. Checked on 17 October 2026, React Native's own Core Components and APIs list contains no web view of any kind, and its guide to installing community libraries happens to use react-native-webview as its worked example of a library that ships native code. So a web view in a React Native app is a deliberate addition to a native project, which is a different situation from a project that is nothing else.

Then two checks you can do on a phone in under a minute. Put the device in airplane mode and open the app: a wrapped site gives you a blank screen or a browser error, while a native project usually still draws its shell, its tab bar and whatever it keeps on the device. Then scroll a long list quickly and watch the keyboard open on a text field. Neither of those is proof, but both are the behaviours a browser engine gets wrong first. While you are in package.json, note the Expo SDK version you are on, because the answer to what the toolchain can do for you changes between releases, and the Expo SDK release notes are the only place that is stated by the people who ship it.

Check yours

What did you actually get handed?

Tick what you can see in the repository and on the phone. Every verdict points at the guideline the thing lands under, not at an opinion.

Nothing ticked. Open package.json first. The dependency list settles the framework question in about four seconds, and everything else on this page follows from it.

Does any of this change because an AI wrote the code?

One clause changes, and it is about who submits rather than what was written. Guideline 4.2.6: apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. Apple adds that these services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. The practical effect is a division of labour: the builder can get a signed build to the right place, and you press submit, because you are the provider of the content.

That is why Newly stops where it does. It generates a real React Native and Expo project you own, uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK and keeps two-way GitHub sync, and it does not submit to the App Store on your behalf. It is 25 US dollars a month, with no free tier. The project it hands over is the shape described further up this page, which is the reason building React Native apps without coding lands you with native views rather than a site in a frame. Who holds the rights to that code is a separate question, answered in who owns AI generated code.

The last point is the one worth carrying away, and it cuts against the comfortable reading of everything above. Having real native views does not satisfy 4.2. The guideline tests the app, not the stack. An app made of genuine UIView and ViewGroup instances that does nothing but show the pages of your website fails 4.2 for the same reason a wrapper does: there is nothing in it that elevates it beyond a repackaged website. The framework decides what your app is made of. You still have to give it a reason to live on a phone, and in practice that means one thing a browser tab cannot do. Data that survives offline. A camera. A notification. An identity that is already signed in.

Questions people ask about web views and React Native

Not as a technology. The words web view, webview, wrapper and hybrid do not appear anywhere in the App Store Review Guidelines, which were read in full on 17 October 2026 and carry their own Last Updated date of 16 October 2026. What Apple bans is an outcome. Guideline 4.2 says your app should include features, content, and UI that elevate it beyond a repackaged website, and that an app that is not particularly useful, unique, or app-like does not belong on the App Store. 4.2.2 adds that apps should not primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. An app can contain web content and pass. An app whose whole reason for existing is web content is what the rule is aimed at.

Start from native views, then earn the rest

Describe the app and you get a React Native and Expo project, which settles the mechanism question before you write a line. The guideline question is yours: name the one thing your app does that your website cannot, and build that first.

Start building