Guideline 4.0 Design: the rejection for apps that work but feel broken

Section 4 of the guidelines has numbered rules — 4.1 Copycats, 4.2 Minimum Functionality, 4.3 Spam, 4.8 Login Services and more — and an introduction with no number. When a reviewer finds a design problem that isn't one of the numbered rules, the rejection cites “Guideline 4.0 - Design”, and the introduction is the rule you've broken:

That's why 4.0 rejections read differently from the rest. Instead of quoting a rule, they usually open with “We noticed an issue in your app that contributes to a lower-quality user experience than App Store users expect” and then name one specific thing. Fix that thing and the rejection goes away.

Design matters at scale. Apple's 2025 Transparency Report counts 415,532 rejections under its Design guidelines — out of 2,093,244 rejected submissions, though one submission can break several rules. It also lists “Guideline 4.0 - Design” as the reason for 72,271 app removals, which it calls “the result of ongoing cleanup for outdated apps.”

If tapping “Log in” or “Sign up” throws the user out to Safari, expect this rejection. Apple's message continues: “please revise your app to enable users to sign in or register for an account in the app. You may also choose to implement the Safari View Controller API to display web content within your app.”

For OAuth or a hosted login page, the better tool is ASWebAuthenticationSession, which Apple describes as “a session that an app uses to authenticate a user through a web service” — in iOS, “the browser is a secure, embedded web view.” The user stays in your app and the callback URL comes straight back to your code. In SwiftUI on iOS 17.4 and later:

import AuthenticationServices
import SwiftUI

struct HostedSignInButton: View {
    @Environment(\.webAuthenticationSession) private var webAuthenticationSession
    let onSignedIn: (URL) -> Void

    var body: some View {
        Button("Continue with your account") {
            Task {
                let authorizeURL = URL(string: "https://auth.example.com/authorize?client_id=YOUR_ID&redirect_uri=myapp://auth")!
                do {
                    let callbackURL = try await webAuthenticationSession.authenticate(
                        using: authorizeURL,
                        callback: .customScheme("myapp"),
                        additionalHeaderFields: [:]
                    )
                    onSignedIn(callbackURL) // exchange the code in the URL for a session
                } catch {
                    // Cancelled or failed — stay on the sign-in screen.
                }
            }
        }
    }
}

Older deployment targets can use ASWebAuthenticationSession(url:callbackURLScheme:completionHandler:) from UIKit. Either way, nothing about the account flow should require leaving the app — including password reset, if you can help it.

Reviewers test on iPad because Guideline 2.4.1 asks for it: “iPhone apps should run on iPad whenever possible.” If your app says it supports iPad, it has to use the whole screen properly. If it's iPhone-only, it still runs on iPad in compatibility mode, and anything that breaks there — clipped buttons, a keyboard covering the only field, a sheet you can't dismiss — can come back as a 4.0 or 2.1 App Completeness rejection.

“Your app included hard to read type or typography” sounds like a font complaint. In the January 2025 case on Apple's forums, the cause was Dark Mode: the app didn't handle the system appearance properly, the reviewer's device was in Dark Mode, and text disappeared into the background. Fixing the Dark Mode handling got it approved.

• Use semantic colours (Color.primary, .secondary, UIColor.label) or asset-catalog colours with dark variants, not hard-coded black and white.
• If you force one appearance, force it everywhere — a light-only screen inside a dark app is where text vanishes.
• Test with larger text sizes. Dynamic Type at a bigger size shows truncated labels and overlapping layouts before a reviewer does.

If you show a “complete your profile” screen asking for a name or email right after Sign in with Apple, you'll get: “Your app requires users to provide their name and/or email address after using Sign in with Apple. This information is already provided by the Authentication Services framework.” The trap is that Apple only sends the name once. Its documentation says the API shares the user's information “the first time the user logs in using Sign in with Apple” — after that, the name isn't included. Save it immediately:

func authorizationController(controller: ASAuthorizationController,
                             didCompleteWithAuthorization authorization: ASAuthorization) {
    guard let credential = authorization.credential as? ASAuthorizationAppleIDCredential else { return }

    // Only present on the first authorization — save it now, don't ask for it later.
    if let name = credential.fullName, name.givenName != nil || name.familyName != nil {
        let formatted = PersonNameComponentsFormatter().string(from: name)
        AccountStore.shared.saveDisplayName(formatted)
    }
    if let email = credential.email {
        AccountStore.shared.saveEmail(email) // may be a private relay address — accept it
    }
}

Our Guideline 4.8 page covers the rest of Sign in with Apple: when you're required to offer it, private relay emails and button design.

1. 01

   Find the one thing they named

   4.0 messages end with “Specifically:” and a single issue. Fix exactly that first; don't redesign the app.

2. 02

   Reproduce it on their device

   The message often names the device and OS, like “iPad Air (5th generation) running iPadOS 26.0”. Use that simulator, in the appearance and orientation they likely used.

3. 03

   Check the neighbours

   If sign-in opened Safari, password reset probably does too. If one screen is crowded on iPad, check them all. Reviewers often stop at the first problem.

4. 04

   Upload a new build

   Layout, sign-in and text styling live in the binary, so this isn't a metadata-only fix.

5. 05

   Reply with what changed and where

   Name the build, the screens and how to reach them. A short screen recording helps for iPad and sign-in fixes.

Hello App Review team,

Thank you for the feedback on Guideline 4.0 - Design.

In build [number] we have:
- [Moved sign-in and registration into the app using
  ASWebAuthenticationSession; users no longer leave the app.]
- [Rebuilt the [screen] layout for iPad; it now uses the full screen
  in both orientations. Tested on iPad Air (5th generation), iPadOS 26.]
- [Fixed text colours in Dark Mode on [screens].]

To verify: [steps to reach the changed screens].
A screen recording is attached in App Review Information.

Thank you,
[Name]

Keep shipping updates after approval too. The same introduction says “Apps that stop working or offer a degraded experience may be removed from the App Store at any time” — the clause behind those 72,271 removals.