Guideline 4.0 Design: How to Fix Layout, Usability and Sign-In Rejections

What Guideline 4.0 Design actually means

"Guideline 4.0" is how App Review cites the introduction to section 4 of the App Store Review Guidelines (last updated June 8, 2026, as of October 2026). The introduction itself has no sub-points; the numbered rules start at 4.1. It says Apple customers value products that are "simple, refined, innovative, and easy to use," that what follows are "minimum standards for approval," and that apps that "stop working or offer a degraded experience may be removed from the App Store at any time."

In practice, 4.0 is the clause reviewers use when something is clearly wrong with the user experience and no more specific rule fits. Copycats go to 4.1, thin web wrappers to 4.2, duplicates to 4.3. A 4.0 rejection usually means your app does enough, but the reviewer hit a concrete defect: a cut-off button, an unreadable screen, a detour to Safari or a redundant form.

The message typically opens with "We noticed an issue in your app that contributes to a lower-quality user experience," followed by bullets that often name the device and OS version. Those bullets are your actual rejection reason.

Common reasons apps get rejected under 4.0

iPad layout problems are also cited as Guideline 2.4.1, and third-party login rules are covered under Guideline 4.8 Login Services.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 4.0 rejection step by step

1. Isolate the bullet. Note the finding, device, OS version and screenshot. Fix that first, then check the whole app for the same class of problem – the next reviewer may test a different screen.
2. Reproduce on the same hardware profile. Add a Simulator matching the named device and OS (for example iPad Air (5th generation) on iPadOS 26), plus the smallest and largest iPhone you support. iPhone-only apps still run on iPad in compatibility mode, so test that too.
3. Make the layout adaptive. In UIKit, pin content to view.safeAreaLayoutGuide, replace hard-coded frames and screen-height math with Auto Layout, and put long forms in a scroll view. In SwiftUI, audit every .ignoresSafeArea() and fixed .frame(height:). Check keyboard avoidance on every input screen.
4. Fix iPad properly. Design for iPad (size classes, NavigationSplitView, readableContentGuide for text width) or make sure the iPhone layout scales cleanly. Removing iPad from Supported Destinations doesn't stop an iPhone app from running on iPad.
5. Handle window resizing. iPadOS 26 lets users resize app windows freely. Remove any reliance on UIRequiresFullScreen and test narrow and half-screen windows (see Apple's TN3192).
6. Bring core flows back into the app. Replace UIApplication.shared.open(url) in sign-in or registration with native forms or ASWebAuthenticationSession for OAuth, and show other web content in SFSafariViewController. Never open Safari on launch.
7. Clean up Sign in with Apple. Request the .fullName and .email scopes, then read fullName and email from ASAuthorizationAppleIDCredential and store them right away: in practice Apple only shares them on the first authorization, which is why many backends end up with an empty name. Make extra profile fields optional, and don't ask for a personal email when the user chose a private relay address – Apple's Sign in with Apple HIG says to respect that choice.
8. Remove unnecessary login walls. If your core features don't depend on an account, let people browse first and ask for sign-in only when they save, buy or sync. Apple's HIG on managing accounts says to delay sign-in for as long as possible.
9. Run a Dark Mode and Dynamic Type pass. Use Xcode's Environment Overrides to switch appearance and text size live. Replace hard-coded colors with semantic colors or Color Set assets, use text styles (UIFont.preferredFont(forTextStyle:) with adjustsFontForContentSizeCategory, or SwiftUI's .body) and test at the largest accessibility size.
10. Ship a new build with evidence. Increment the build number, test via TestFlight on a real device and capture screenshots of the fixed screens on the named device.

How to reply, resubmit or appeal

Reply in App Store Connect

Open Apps, select your app, click the unresolved issues link, choose Resolve next to the submission and click Reply to App Review. As of October 2026 replies are limited to 4,000 characters and can include attachments (App Store Connect Help). For 4.0, before-and-after screenshots on the exact device from the rejection beat any paragraph of explanation.

Resubmit with a new build

4.0 findings concern the binary, so the normal path is a new build plus a short reply listing each finding and what changed. Repeat that summary in App Review Information > Notes on the new version.

When an appeal makes sense

Design is partly subjective, and reviewers sometimes flag deliberate choices or behavior Apple's own APIs produce – in 2024, for example, Mac developers reported "default web browser" sign-in rejections (cited under 5.1.1 in at least one case) even though ASWebAuthenticationSession opened the browser by design. If the reviewer misunderstood your app, appeal to the App Review Board via Apple's App Review page: give specific reasons, answer open information requests first, and file one appeal per rejected submission. "Other apps look the same" is weak; a clear explanation of the user flow is strong.

Unsure what the reviewer wants? Apple's App Review page offers 30-minute App Review video appointments through Meet with Apple. If your app is already on the App Store and a 4.0 finding blocks a bug-fix update, ask for the bug fix submission process in App Store Connect: as long as there are no legal or safety concerns, Apple lets you address the finding in your next submission.

A practical design QA matrix for 4.0

Run this on every release that touches UI:

Apple's Human Interface Guidelines on layout recommend testing the largest and smallest layouts first. That's where 4.0 bugs live.

iOS 26 and iOS 27 SDK changes that cause new 4.0 issues

As of October 2026, uploads must be built with Xcode 26 and the iOS 26 SDK or later (required since April 28, 2026, per Apple's upcoming requirements). That rebuild alone changes your UI:

• Liquid Glass. Apps linked against the iOS 26 SDK adopt the new system design for standard bars and controls. Custom bottom bars and floating buttons that assumed an opaque tab bar can now overlap system chrome.
• Temporary opt-out. The UIDesignRequiresCompatibility Info.plist key keeps the previous look, but Apple documents that it is ignored once you build for iOS 27 or later.
• Full-screen opt-out ending. UIRequiresFullScreen is deprecated since iPadOS 26. Per TN3192, once you build with the iOS 27 SDK the key no longer prevents resizing: the system resizes the scene discretely, which exposes fixed, frame-based layouts.
• Launch screen required. When you upload a build made with the iOS 27 SDK, App Store Connect checks Info.plist for UILaunchScreen, UILaunchStoryboardName or their plural variants and rejects the upload with ITMS-90870 if none is present (TN3208).

As of October 2026, Apple has not announced when the iOS 27 SDK becomes mandatory, so keep an eye on the requirements page. If your app depends on either opt-out key, start the adaptive layout work now. If you still need full-screen behavior on older iOS versions after that work, TN3192 describes the UIRequiresFullScreenIgnoredStartingWithVersion key.

Flutter, React Native and WebView apps

Cross-platform apps fail 4.0 for the same reasons; the fixes just live elsewhere:

• Flutter: wrap screens in SafeArea or read MediaQuery.paddingOf(context), avoid fixed heights from one design device, respect MediaQuery.textScalerOf(context) instead of clamping text scale to 1.0, and provide a dark ThemeData or deliberately lock to light.
• React Native and Expo: use react-native-safe-area-context for insets, keep allowFontScaling on (cap extremes with maxFontSizeMultiplier), follow useColorScheme(), and make sure supportsTablet matches what you tested.
• Capacitor, Cordova and WebView screens: add viewport-fit=cover to the viewport meta tag, pad fixed headers and footers with env(safe-area-inset-top) and env(safe-area-inset-bottom), support prefers-color-scheme, and route OAuth through an in-app browser plugin backed by ASWebAuthenticationSession.

If most of your app is a WebView, read our Guideline 4.2 guide too: fixing safe areas won't help if the real concern is a repackaged website.

How to avoid 4.0 next time

4.0 findings are regressions you can catch automatically. Add these checks to CI:

• Snapshot tests across a device matrix: key screens on a small iPhone, a large iPhone and an iPad, in light and dark appearance and at an accessibility text size.
• Accessibility audits: XCUITest's performAccessibilityAudit() (Xcode 15 or later, tests on iOS 17 or later) flags clipped text, Dynamic Type issues, low contrast and small hit regions.
• Info.plist and code guards: warn when UIRequiresFullScreen or UIDesignRequiresCompatibility is set, no launch screen key exists, or authentication code calls UIApplication.shared.open.
• Fresh-install pass: before each submission, someone who didn't build the feature walks through onboarding and sign-in on a clean device, like a reviewer would.

AI-assisted screenshot review can flag likely overlaps, truncation and contrast problems across many device combinations, but it doesn't replace a human who knows how App Review reads an app. Want both? Book a free consultation call with appsubmitter.io: we can review your 4.0 rejection and set up these CI checks, even if your code isn't 100% ready. Code changes aren't included; we discuss and quote them upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 4.0 - Design.

We reproduced the issue on [device and OS from the rejection] and fixed it in build [new build number]:

1. [Finding, e.g. Login buttons were cropped on iPad] – [What changed, e.g. the layout now respects the safe area and adapts to all window sizes].
2. [Finding, e.g. Registration opened in Safari] – [What changed, e.g. sign-up now happens in the app].
3. [Finding, e.g. Name requested after Sign in with Apple] – [What changed, e.g. we use the name Sign in with Apple provides; the field is optional].

We also tested on [smallest iPhone], [largest iPhone] and iPad, in light and Dark Mode and at the largest Dynamic Type size. Before-and-after screenshots on [device] are attached.

Demo account (if needed): [username] / [password]

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• The screen from the rejection screenshot displays correctly on the named device in the Simulator and, ideally, on real hardware.
• Nothing is clipped or hidden behind the Dynamic Island, home indicator or keyboard on the smallest supported iPhone.
• The app is fully usable on iPad, including iPhone-only builds in compatibility mode and resized windows.
• Sign-in and registration happen inside the app; nothing opens Safari on launch or for core features.
• After Sign in with Apple, the app does not ask again for a name or email address.
• Users can explore the app without logging in unless its core features are account-based.
• All text stays legible in Dark Mode, including with Increase Contrast and Reduce Transparency.
• Text wraps instead of truncating or overlapping at the largest accessibility Dynamic Type size.
• Every screen has a clear way back, labeled controls and designed empty and error states.
• A new build was tested via TestFlight and the review notes summarize each fix.

Frequently asked questions

Official source: App Store Review Guidelines – 4. Design. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.