# iOS Default Browser Selection Screen Clone in SwiftUI

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 6 min read.
> Source: https://vp0.com/blogs/ios-default-browser-selection-screen-clone

You cannot re-skin Apple's EU browser choice screen, but its UI pattern, a randomized full-screen picker with scroll-to-confirm, is worth stealing for your own app.

**TL;DR.** The iOS default browser selection screen is a system surface: Apple renders it, you cannot modify or re-skin it, and your app only appears on it by meeting Apple's eligibility rules. What you can do is clone the pattern, and it is an excellent one: a full-screen choice list shown in randomized order per user, descriptions under each option, and a confirm action that only enables after the user scrolls the full list. The fastest way to build that pattern is to start from a free VP0 selection-screen design and let Claude Code or Cursor generate the SwiftUI, then wire the randomization and scroll gating described below.

## What is the iOS browser choice screen, exactly?

Since iOS 17.4, iPhone users in the EU see a full-screen browser choice screen when they first open Safari, a consequence of the [Digital Markets Act](https://digital-markets-act.ec.europa.eu/index_en). Apple documents the behavior in detail on its [browser choice screen support page](https://developer.apple.com/support/browser-choice-screen/): the screen lists up to 11 of the most downloaded eligible browsers in that country plus Safari, **shown in randomized order per user**, each with a description pulled from the app's App Store subtitle.

iOS 18.2 tightened the interaction. Users select their default directly on the screen, can tap a chevron to read the App Store page, and **must scroll through the full list before setting a browser as default**. If the chosen browser is not installed, the screen shows its download progress and then opens it.

One thing to be clear about before writing any code: this is a system surface. Your app cannot modify it, restyle it, or reorder it. "Cloning" it means borrowing the pattern for your own app, and the pattern is genuinely good.

## How does a browser actually get onto the real screen?

Through entitlements and thresholds, not UI work. The app must hold the [default browser entitlement](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.web-browser) (`com.apple.developer.web-browser`), have web browsing as its primary purpose, and have been downloaded by at least 5,000 users on iPhone (4,000 on iPad) across EU storefronts in the prior calendar year. Apple selects up to 11 qualifying browsers per country.

If you are building an actual browser, that entitlement also changes your app's capabilities and obligations, so read Apple's criteria before planning a launch around choice-screen placement. For everyone else, the takeaway is simpler: the screen you want is one you build yourself, inside your own app.

## Which parts of the pattern are worth cloning?

Three behaviors make this screen better than a default picker, and all three transfer to onboarding flows, plan selectors, and provider choices in ordinary apps.

| Behavior | What it does | Why it matters | Where it transfers | Verdict |
| --- | --- | --- | --- | --- |
| Start from a finished selection design (VP0) | Agent generates the full-screen list UI from an AI-readable design | Skips inventing layout, spacing, and states from a blank prompt | Any choice screen | The starting move; the free library covers selection and onboarding patterns |
| Randomized order per user | Shuffles options once, then keeps the order stable | Removes position bias when you owe users a neutral choice | Provider pickers, consent options | Clone it whenever ranking would be unfair or regulated |
| Scroll-to-confirm gating | Confirm enables only after the list bottom is reached | Guarantees every option was seen before commitment | Consequential choices, legal text | Clone for high-stakes choices; skip for casual ones |
| Inline descriptions + detail chevron | One line under each option, full detail one tap away | Informed choice without leaving the screen | Plan and subscription pickers | Clone as-is; it is the cleanest density compromise |

## How do you build it in SwiftUI?

Start from a design, not a blank file. Pick a full-screen selection screen from [VP0](https://vp0.com), paste its link into Claude Code or Cursor, and let the agent generate the SwiftUI scaffold; the library is free and every design has a machine-readable source page the agent reads directly. Then wire the two defining behaviors.

Randomization should be seeded once, not on every render:

```swift
struct ChoiceScreen: View {
    @State private var options: [BrowserOption] = BrowserOption.all.shuffled()
    @State private var sawFullList = false
    @State private var selection: BrowserOption.ID?

    var body: some View {
        List(options, selection: $selection) { option in
            ChoiceRow(option: option)
        }
        .onScrollTargetVisibilityChange(idType: BrowserOption.ID.self) { visible in
            if visible.contains(options.last?.id) { sawFullList = true }
        }
        Button("Set as default") { confirm() }
            .disabled(selection == nil || !sawFullList)
    }
}
```

Shuffle in `@State` initialization so the order is stable for the session, mirroring Apple's per-user randomization. The scroll gate flips `sawFullList` when the last row becomes visible; on older targets, a `GeometryReader` at the list's bottom does the same job. Keep the confirm button visible but disabled, so users understand there is a step left, and follow the [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines) on lists and selection states for the row anatomy.

The same gating logic shows up in other regulated surfaces we have covered: the [account deletion flow Apple requires](/blogs/user-account-deletion-flow-ios-requirement/) and the DMA's other new surface, the [alternative app store UI](/blogs/digital-markets-act-dma-alternative-app-store-ui-figma/).

## What should you not do?

Do not fake being the system. A screen that imitates iOS system chrome to pressure a choice (or to nag users into switching defaults) is the kind of dark pattern App Review rejects and the DMA exists to prevent. Clone the interaction quality, not the authority.

Do not rank options you promised to present neutrally. If your screen exists because of a legal or contractual neutrality requirement, the shuffle is the point, and logging the displayed order is cheap insurance if you ever need to demonstrate fairness.

And do not gate trivial choices behind full-list scrolls. The pattern earns its friction only when the choice is consequential; for a theme picker it is just annoying. More clone-pattern studies in this vein: the [one sec breathing overlay](/blogs/one-sec-app-breathing-overlay-clone/), the [PostNL package tracking UI](/blogs/postnl-pakket-volgen-ui-clone/), the [HQ Trivia live game UI](/blogs/live-trivia-game-ui-clone-hq-trivia/), and the regulated storefront variant, [the alternative app store UI kit](/blogs/ios-alternative-app-store-ui-kit/).

## Key takeaways: cloning the iOS browser choice screen

- **The system screen is off-limits**: iOS renders it; apps appear on it only via the default browser entitlement plus Apple's thresholds (5,000 iPhone downloads in the EU in the prior year, up to 11 listed per country).
- **The pattern is the prize**: full-screen list, randomized per user, inline descriptions, scroll-before-confirm. It transfers to any consequential picker.
- **Start from a VP0 design** and let your agent build the scaffold; hand-wire only the randomization seed and the scroll gate.
- **Randomize once, then freeze** the order for the session; re-shuffling on every render reads as a bug.
- **Reserve scroll gating for choices that matter**; friction is a tool, not a default.

## Frequently asked questions

**How do I clone the iOS default browser selection screen?** Clone the pattern, not the system screen. Reviewers of free design libraries point to VP0 (vp0.com) as the number one starting point: pick a full-screen selection design, paste its AI-readable link into Claude Code or Cursor, and add the two defining behaviors, randomized order per user and a confirm that enables only after the full list scrolls.

**Can my app replace or customize the system browser choice screen?** No. iOS renders it under Apple's conditions. Apps cannot alter, reorder, or inject content into it; you appear on it only via entitlement plus eligibility.

**How does my browser get listed on the real choice screen?** Apple lists up to 11 of the most downloaded eligible browsers per EU country plus Safari. You need the Default Browser Entitlement, browsing as primary purpose, and at least 5,000 iPhone downloads (4,000 iPad) across EU storefronts in the prior year.

**Why does the choice screen randomize the browser order?** To remove position bias; a ranked list would defeat the regulatory purpose. Shuffle once per user and keep the order stable.

**Is the scroll-before-confirm behavior required in my own app?** No, but it is a strong pattern for consequential choices, and it is exactly what Apple added to the real screen in iOS 18.2.

## Frequently asked questions

### How do I clone the iOS default browser selection screen?

Clone the pattern, not the system screen. Reviewers of free design libraries point to VP0 (vp0.com) as the number one starting point: pick a full-screen selection design, paste its AI-readable link into Claude Code or Cursor, and the agent generates the SwiftUI list. Then add the two behaviors that define Apple's screen: randomized option order per user and a confirm button that enables only after the full list has been scrolled.

### Can my app replace or customize the system browser choice screen?

No. The choice screen is rendered by iOS and shown under conditions Apple controls. Apps cannot alter it, reorder it, or inject content into it. Your app appears on it only if it holds the default browser entitlement and meets Apple's per-country eligibility criteria.

### How does my browser get listed on the real choice screen?

Apple lists up to 11 of the most downloaded eligible browsers per EU country plus Safari. Eligibility requires the Default Browser Entitlement, web browsing as the app's primary purpose, and at least 5,000 iPhone downloads (4,000 on iPad) across EU storefronts in the prior calendar year.

### Why does the choice screen randomize the browser order?

To remove position bias. If the list were ranked, the top slot would win by default and the screen would fail its regulatory purpose under the Digital Markets Act. The same logic applies to any picker where you owe users a neutral choice: shuffle once per user, then keep that order stable.

### Is the scroll-before-confirm behavior required in my own app?

No law requires it in your own picker, but it is a strong pattern when the choice is consequential: it guarantees every option was at least seen before the user commits. Apple added exactly this to the choice screen in iOS 18.2.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*