Guideline 4.0 Design: App Rejected for Its Interface

"Guideline 4.0 - Design" isn't a numbered rule like the others. It's the introduction to the Design section of Apple's guidelines, and Apple cites it when your interface looks below the expected standard. The published rejections all look alike: crowded screens on iPad, text that's hard to read, sign-in that sends users to Safari, Sign in with Apple implemented badly. The fix almost always starts on the device named in the message, one screen at a time.

I publish my own iOS apps with Expo. Solys, TradaZen and Nolera are set to iPhone only, and the reviewer still tested Solys and Nolera on iPad. This guide is based on Apple's text, on 4.0 rejections published by other developers, and on the visual checklist I run before every submission. For the big picture on rejection reasons, read why Apple rejects an app.

What does guideline 4.0 Design cover?

Section 4 of the App Review Guidelines opens with an unnumbered paragraph: "Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store." It adds that the design is up to you, but that what follows sets "minimum standards for approval". It also warns that an app that degrades after approval can be removed.

In plain terms: Apple expects a simple, polished, easy-to-use app, and 4.0 is used when the problem doesn't fall under any specific sub-rule. The text gives no numeric criteria. The practical reference is the Human Interface Guidelines, Apple's design rules.

The most common 4.0 rejections

Here are the four cases I found in messages published on Apple's forums, with the wording Apple used.

Case	Apple's wording	Fix
Crowded screens on iPad	"crowded"	Fluid layout
Unreadable text	"hard to read type"	HIG sizes
Sign-in in Safari	"taken to Safari"	Sign-in inside the app
Sign in with Apple	Name asked again	Name already provided

Crowded or cut-off screens on iPad

The typical message, published in September 2025: "Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0." It went on to say the app only used part of the screen (forum thread).

The cause is rule 2.4.1: "iPhone apps should run on iPad whenever possible." With Expo, the ios.supportsTablet option defaults to false, according to Expo's app config. Your iPhone app then runs on iPad in compatibility mode, in an iPhone-sized window. Setting your app to iPhone only doesn't protect it from being tested on iPad. It was on an iPad Air that the Solys demo became impossible to win, a case I break down in the guideline 2.1 guide.

Two ways out. Either you really support iPad, with a layout that adapts to the available space. Apple's design rules say to decide the layout based on size classes, not on the device model. Or you stay iPhone only, and every screen has to fit in the compatibility window.

Hard-to-read text

The message, published in January 2025: "Your app included hard to read type or typography." Apple reminds you that users expect apps to be "simple, refined, and easy to use" (forum thread).

Apple's typography rules give benchmarks for iOS: 17 points by default, 11 points minimum. The accessibility rules call for a contrast ratio of at least 4.5 to 1 for text up to 17 points, and tap targets of 44 by 44 points by default.

One trap if you scale fonts down on small screens, like I do to keep the same line breaks everywhere: check that your smallest text, scaled down on iPhone SE, stays at 11 points or more.

Sign-in sent to Safari

The message, published on Apple's forum: "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." Apple asks you to allow sign-up and sign-in inside the app, and recommends an embedded Safari view.

With Expo, expo-web-browser covers both needs without leaving the app: openAuthSessionAsync opens an authentication session in a modal window, and openBrowserAsync shows a page in an embedded Safari view. Opening sign-in with Linking.openURL, on the other hand, sends users to the Safari app. Which sign-in options you have to offer is covered by a different rule, 4.8.

Sign in with Apple implemented badly

The message, published in May 2024: "Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework." (forum thread).

The expo-apple-authentication docs explain the trap: the name and email are only provided on the first sign-in. Save them right away, or you'll be tempted to ask for them again. Also use the button provided by the library: its color is set with buttonStyle and its corners with cornerRadius, never through style.

4.0, 4.2, 4.3: three design rejections not to mix up

Rule	What's judged	Fix
4.0	The interface	Fix the screens
4.2	The app's usefulness	Add native substance
4.3	The resemblance	Change the concept

4.2, Minimum Functionality, requires features, content and UI that lift the app "beyond a repackaged website". The line with 4.0 is thin: a website wrapped in an app can get hit with both. If your app lacks substance, polishing the screens won't be enough.

4.3 targets copies and saturated categories: I covered its two paragraphs in the guideline 4.3 Design Spam guide. A polished interface won't save an app that looks like a thousand others.

The visual checklist before submission

This is what I add to every submission. In my apps, every screen is designed for the largest iPhone, then scaled down by a single factor on smaller ones: same proportions, same line breaks. Then I compare the renders side by side: iPhone SE, standard iPhone, largest iPhone, and an iPad for compatibility mode.

Check	Device	What must hold up
First launch	iPhone SE	Nothing cut off
Full onboarding	iPad	Every button reachable
Keyboard open	iPhone SE	Field and button visible
Larger text	Standard iPhone	No truncated text
Dark Mode	All	Text readable everywhere
Safe areas	Largest	Nothing under the Dynamic Island
Paywall	iPhone SE	Prices and links visible
Sign-in	iPad	It stays inside the app

Three notes:

• Larger text. Apple's typography rules suggest a simple test: turn on the largest text sizes in Settings, Accessibility, Display & Text Size, then check that everything stays readable.
• Dark Mode. Apple's Dark Mode rules ask that the app stay readable in both appearances. Expo applies light by default if you don't set userInterfaceStyle. Solys follows the phone's setting, TradaZen stays dark, Nolera stays light: in all three cases, I test the appearance that's displayed.
• Safe areas. Content must not go under the Dynamic Island or the home indicator. Expo explains how in its safe areas guide.

On a Mac, you can configure the simulator from the command line, which makes the checklist quick to rerun:

xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png

On a real phone, I do the same pass with a TestFlight build. Methodology: this checklist is mine, built from the rejections my apps got, not a list provided by Apple. It cuts down on surprises without guaranteeing approval.

How do you respond to a 4.0 rejection?

1. Find the device and version named in the message, then open the same model in the simulator.
2. Fix every occurrence. The typical message asks you to "address all instances" of the issue, not just the screen in the screenshot.
3. Submit a new build: the reviewer tests the code bundled in the app.
4. Reply with screenshots taken on the same device, by replying to the App Review message.
5. Only appeal if you're sure: Apple lets you contact the App Review Board, with one appeal per rejected submission.

The template I'd use, to adapt:

Hello,

Thank you for your feedback regarding Guideline 4.0.

We reproduced the issue on [device] running [OS version].

Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].

We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.

Attached: screenshots of the updated screens on [device].

Best regards,

Prepare your submission without design rejections

The Review Kit bundles my pre-submission checklist, which covers rule 2.4.1 on iPad among other things, plus Claude Code skills that review your project. For a human eye, book an hour with me: we open your screens on several sizes, over video call. The full process after a rejection is on the app rejected by Apple page.

Getting ready for your first release? Take your free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist.

Frequently asked questions

What does "Guideline 4.0 - Design" mean in a rejection message?

Apple thinks your interface is below the expected standard, without targeting a specific sub-rule: crowded screens, hard-to-read text, a sign-in flow it considers poor. The message usually names the device used and often includes a screenshot.

My app is set to iPhone only: why does Apple test it on iPad?

Because rule 2.4.1 says iPhone apps should run on iPad whenever possible. Your app opens there in compatibility mode, in an iPhone-sized window, and every screen has to stay usable.

Do I need a new build after a 4.0 rejection?

Yes, in most cases. The reviewer tests the code bundled at first launch, and a fix delivered remotely might not reach them. I explain this in the guideline 2.1 guide.

Is Dark Mode required to get approved?

The review guidelines don't require it. The design rules point out that users expect apps to follow their setting. If you force light or dark, as Expo allows, test that appearance. If you follow the phone's setting, test both.

Can I appeal a 4.0 rejection?

Yes, to the App Review Board, if you believe your app follows the rules. Apple asks for specific reasons, allows one appeal per rejected submission, and wants you to answer any information requests first.