What is a native iPhone app? Native vs web vs cross-platform (2026)

By Sigsten Gustavii· 20 October 2026· Updated 27 October 2026· 9 min read

When people say an app is native, they mean it was made for one platform with that platform's own tools. On iPhone, that means Apple's language, Apple's interface framework and Apple's build tool. Everything else is some kind of translation: a website in a browser, a website in a box, or a shared codebase with a layer in between.

The difference is not just a technical detail. It decides how the app looks, which iPhone features it can use, how it gets onto people's phones, and whether Apple accepts it into the App Store. Here are the four kinds side by side.

What native means on iPhone

A native iPhone app is written in Swift, the language Apple describes as "a powerful and intuitive programming language for all Apple platforms". Its screens are usually built with SwiftUI, Apple's framework for interfaces, or with UIKit, the older framework it works alongside. Xcode, Apple's build tool, compiles the Swift into machine code for the iPhone's chip, and signs it so the phone will run it.

Because nothing sits in between, a native app talks to the iPhone directly through Apple's own frameworks:

• MapKit for Apple Maps, pins and directions.
• LocalAuthentication for a Face ID lock.
• VisionKit for scanning text and codes with the camera.
• Core Motion for steps and movement.
• EventKit for adding events to the Calendar.
• StoreKit for Apple's in-app purchase and subscriptions.

You also get a lot without asking for it. A SwiftUI list scrolls, swipes and bounces the way every other list on the phone does. Dark mode, larger text sizes and VoiceOver work because the controls are Apple's own. When Apple refreshes the look of iOS, an app built from its controls picks up much of the new look when it is rebuilt.

What a web app is

A web app is a website built to behave like an app. On an iPhone, people open it in Safari and can add it to the Home Screen, where it gets an icon and opens without the browser bars. When it is built to be installed this way, it is called a progressive web app, or PWA.

Its strength is reach: one website works on every phone and computer, with no store and no review. Its limits on iPhone come from the browser. It can only use the features Safari exposes to websites, it isn't listed in the App Store, and its stored data follows the browser's rules. Our post on PWA vs native iPhone apps goes through what iOS allows a web app in 2026.

What a wrapper app is

A wrapper, or web-view app, is a native shell with a website inside it. The shell is a real iPhone app with an icon and an App Store page, but almost everything on screen is a web page loaded into a web view. Tools such as Capacitor and Cordova make this easy, and many website-to-app services work this way.

Wrappers are quick to make, and they can add a few native plugins. The trouble is that from the inside they are still a website, and Apple reviews apps with that in mind. Its App Review page says that "websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

What a cross-platform app is

A cross-platform app is written once and built for both iPhone and Android. The two big frameworks take different routes:

• [React Native](/glossary/react-native) uses JavaScript and React. Its components become native views on each platform, and many teams use it through Expo, a toolkit of ready-made modules.
• [Flutter](/glossary/flutter) uses Google's Dart language and draws its own interface with its own rendering engine, so the app looks the same on both platforms unless you style it per platform.

Both produce real apps that can go in the App Store, and both are a sensible choice when Android matters from day one. The cost is a layer between your code and the phone. Each iPhone feature usually comes from a separate package that has to keep up with iOS, the framework and the other packages. The look is close to iOS, but it is a copy rather than Apple's own controls. Our SwiftUI vs React Native guide compares the two in detail.

Native vs web vs cross-platform: which fits which need

Why Apple's guideline 4.2 matters for wrappers

Every app in the App Store passes App Review, and the rule that catches most wrappers is guideline 4.2, minimum functionality. Apple's words: "Your app should include features, content, and UI that elevate it beyond a repackaged website." It goes on to say that an app that isn't "particularly useful, unique, or app-like" doesn't belong on the App Store.

Guideline 4.2.2 adds that, other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links. A wrapper around a company's website often reads as exactly that, and reviewers send it back.

Two neighbouring rules matter if you use a builder. Guideline 4.2.6 says apps made from a commercial template or app generation service are rejected unless the provider of the app's content submits them. And guideline 4.3 turns away near-copies of the same app. The answer to all three is the same: an app of your own, with real features, published under your own developer account.

Does native still matter when AI writes the code?

More than before. When an AI writes and keeps changing your app, Swift's compiler checks every change before anyone sees it, and iPhone features come from Apple's frameworks rather than packages that can drift out of step. The result looks like iOS because it is iOS. We go deeper in native iOS vs React Native for AI-built apps.

When native is not the right choice

• Android matters on day one. A cross-platform framework gives you both stores from one codebase.
• Your product already lives on the web, and the phone is one of many places people use it.
• The content changes hourly and you don't want each change to pass review.
• It's a simple information site. A good mobile website may be all you need.

For an idea that lives on the phone, used daily, with the camera, Face ID, maps or reminders, native is the stronger default.

How Borel builds native iPhone apps

Borel turns a description into a native iPhone app. Every new app is written in Swift with SwiftUI, and Xcode builds it on Borel's own Mac, so you don't need a Mac or any code. It is not a wrapper: there is no website inside, just Apple's own controls. The same app runs on iPad too.

A Borel app can use Apple's frameworks directly: Apple Maps, the camera and scanner, Face ID, reminders, the Calendar, haptics and Apple's in-app purchase. Accounts, a cloud database and Borel AI come built in, with no keys to paste.

1. Describe the app in plain words at borel.one. The free plan gives you 5 credits a day.
2. Watch it build. Borel writes the Swift, and Xcode compiles it on Borel's Mac.
3. Try it in the [iOS Simulator in your browser](/iphone-simulator-in-browser), free for everyone, and change anything by asking.
4. Put it on your iPhone with Borel Companion, which comes with Pro from $20 a month.
5. Publish to the App Store under your own Apple Developer account, $99 a year paid to Apple. The SwiftUI source is yours to download.

Make a native iPhone app for logging my runs: date, distance, time and how it felt. Show my pace on a chart for the last month, keep everything on the phone so it works with no signal, and lock the app with Face ID.

The bottom line

A native iPhone app is made with Apple's own tools and runs straight on the phone, with every Apple framework and the real iOS look. Web apps and wrappers trade that for reach and speed of change; cross-platform frameworks trade it for Android. If your app is for the iPhone, native is the way to make it feel at home there, and with Borel you get a native SwiftUI app without learning Swift.

I built Borel around native apps because I want the things people make to feel like they belong on the iPhone. If you have an idea, describe it and see for yourself how it feels.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.