Guideline 4.0, Design

A Guideline 4.0 rejection means the reviewer judged your app's interface as below the standard Apple expects, and unlike almost every other rejection, the message usually names nothing. No screen, no control, no sentence you can act on.

So the first job is not fixing anything. It is making Apple be specific.

How it is usually worded

The header arrives as Guideline 4.0 - Design, and the body tends to be one of:

• "We noticed that the quality of your app's user interface is not consistent with App Store standards."
• "Your app's user interface does not meet Apple's design expectations."
• "We found aspects of your app's user interface that are not sufficiently refined."

Often there is an attachment. The attachment is the actual rejection: a screenshot or screen recording of the offending screen, with the boilerplate above wrapped around it. If you cannot see one, check the Resolution Center thread rather than the email; images do not always survive the notification.

What it actually means

Section 4 of the guidelines is Design, and 4.0 is its opening. Reviewers use it as the bucket for "this does not feel finished" when nothing more specific fits.

That is not a bug report, and it is not a taste dispute either. In practice a 4.0 lands for one of three reasons: the layout breaks on the device the reviewer used, the app has visible dead ends, or the interface fights iOS conventions hard enough to look broken.

Why it triggers

Apple publishes no breakdown of 4.0 causes, so nobody can tell you percentages. Ordered by what turns up most often in our experience, which is not the same as data:

• Layout broken at the edges. Content under the Dynamic Island or the home indicator, controls clipped off-screen, text truncated to nonsense, a keyboard covering the field it is meant to fill.
• iPhone layout stretched onto iPad. If you declared iPad support, the reviewer will open it on an iPad, and a scaled-up phone screen reads as unfinished.
• Dead ends. Buttons that do nothing, tabs that open empty states with no explanation, "coming soon" screens, a debug or QA menu still reachable in the shipped build.
• Unreadable or unlabelled controls. Low-contrast text, tap targets too small to hit, icon-only controls with no label and no accepted meaning.
• Custom chrome that behaves wrongly. A hand-rolled navigation bar with no working back gesture, a modal you cannot dismiss, scroll views that trap the gesture.
• Asset quality. Upscaled bitmaps, placeholder art, an icon with baked-in rounded corners or transparency.
• Dynamic Type and dark mode. Set text to the largest accessibility size and switch to dark; whole screens collapse in apps that shipped without checking.

How to fix it, in order

1. Ask which screens. Reply in Resolution Center: "Could you confirm which screens and which device the design concern relates to, and attach a screenshot if possible?" You are allowed to ask. Guessing across a whole app costs more than a day of waiting.
2. Reproduce on the device they named. The rejection header carries the device type and OS version the reviewer used. Run that exact combination, not "an iPhone", that model, before you change a line.
3. Sweep the safe areas. Every screen, on a Dynamic Island device and on the largest iPad you support. Then rotate, if you declare landscape. Most 4.0 rejections we see are one of these two screens.
4. Close the dead ends. Anything that does not work yet comes out of the build or goes behind a flag. A hidden feature is a different rejection (2.3.1) but a visibly broken one is this rejection.
5. Drop iPad if you do not support it properly. Shipping iPhone-only is a legitimate choice. A stretched iPad build is not, and it is the easiest 4.0 to avoid.
6. Check Dynamic Type, dark mode and VoiceOver labels. Largest accessibility size, dark appearance, and every icon-only control given a label. This is a couple of hours and it removes a whole class of finding.
7. Re-cut the assets. 1024×1024 icon, no alpha, no pre-rounded corners; no upscaled images anywhere in the app or the screenshots.

What to send back

If you have the specifics, name them. A reply that lists the exact screens you changed reads as a fixed app; a reply that says "we improved the design" reads as a resubmission of the same build.

Thank you for the review. We have identified the screens in the attachment and rebuilt their layout: content now respects the safe area on Dynamic Island devices and above the home indicator, the truncated labels in the settings list wrap correctly at the largest Dynamic Type size, and the incomplete "Reports" tab has been removed from this build rather than shown empty. We tested on the device and OS version named in the rejection, plus iPad, in both light and dark appearance.

If Apple gave you nothing to work with and you have already asked once:

Thank you for the review. We would like to resolve this properly but the feedback does not identify a specific screen or behaviour. Could you confirm which screens the design concern applies to, and on which device? In the meantime we have addressed safe-area clipping on [screen] and removed the unfinished [screen] from the build.

When it is really a different guideline

• The app works but does very little → 4.2 Minimum Functionality.
• Something crashed or a feature did not respond → 2.1 App Completeness.
• The screenshots look nothing like the app → 2.3 Accurate Metadata.
• Your app resembles someone else's → 4.1 Copycats.

Getting the guideline right matters, because the fix is entirely different. A 4.0 you treat as a 4.2 costs you a rewrite you did not need.

If you disagree after the exchange, you can escalate to the App Review Board. Do it with side-by-side screenshots and a specific claim, not an argument about taste. And if the app is already live, a pure bug-fix update is not supposed to be held for a guideline dispute like this one. Apple said so publicly in 2020

AppSubmit keeps the rejection text, the attachment and the device and OS the reviewer named next to the build, so the next submission can be checked against the same list, but a text file beside your project does the same job.

Source: Apple, App Store Review Guidelines, 4.0 (https://developer.apple.com/app-store/review/guidelines/#design)

Related: apple-guideline-4-2-minimum-functionality, apple-guideline-2-1-app-completeness, apple-guideline-4-1-copycats