Guideline 4.0 Design: אפליקציה נדחתה בגלל הממשק

"Guideline 4.0 - Design" היא לא עוד כלל ממוספר כמו כל השאר: זו פסקת הפתיחה של פרק ה-Design בכללים של אפל, ומצטטים אותה כשהממשק שלך נראה מתחת לרמה הצפויה. הדחיות שפורסמו דומות זו לזו: מסכים צפופים ב-iPad, טקסט שקשה לקרוא, התחברות שנשלחת ל-Safari, Sign in with Apple שמשולב לא נכון. התיקון מתחיל כמעט תמיד במכשיר שמוזכר בהודעה, מסך אחרי מסך.

אני מפרסם אפליקציות iOS משלי עם Expo: Solys, TradaZen ו-Nolera מוגדרות ל-iPhone בלבד, ובכל זאת ה-reviewer בדק את Solys ואת Nolera על iPad. המדריך הזה מבוסס על הטקסט של אפל, על דחיות 4.0 שמפתחים אחרים פרסמו ועל רשימת הבדיקה הוויזואלית שאני מריץ לפני כל הגשה. לתמונה הכללית של סיבות הדחייה, קרא למה אפל דוחה אפליקציה.

מה מכסה guideline 4.0 Design?

פרק 4 של App Review Guidelines נפתח בפסקה בלי מספר: "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." היא מוסיפה שהעיצוב שייך לך, אבל ההמשך קובע "minimum standards for approval". היא גם מזהירה שאפליקציה שמתדרדרת אחרי האישור עלולה לרדת מהחנות.

בפשטות: אפל מצפה לאפליקציה פשוטה, מלוטשת וקלה לשימוש, ו-4.0 משמשת כשהבעיה לא נופלת תחת אף תת-כלל מדויק. הטקסט לא נותן קריטריונים מספריים. הרפרנס המעשי הוא ה-Human Interface Guidelines, כללי העיצוב של אפל.

דחיות 4.0 הנפוצות ביותר

אלה ארבעת המקרים שמצאתי בהודעות שפורסמו בפורומים של אפל, עם הניסוח שצוטט.

מקרה	הניסוח של אפל	תיקון
מסכים צפופים ב-iPad	"crowded"	פריסה גמישה
טקסט לא קריא	"hard to read type"	גדלים לפי HIG
התחברות ב-Safari	"taken to Safari"	התחברות בתוך האפליקציה
Sign in with Apple	מבקשים שוב את השם	השם כבר סופק

מסכים צפופים או חתוכים ב-iPad

ההודעה הטיפוסית, שפורסמה בספטמבר 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." בהמשך צוין שהאפליקציה משתמשת רק בחלק מהמסך (שרשור בפורום).

הסיבה נמצאת בכלל 2.4.1: "iPhone apps should run on iPad whenever possible." ב-Expo, האפשרות ios.supportsTablet היא false כברירת מחדל, לפי הגדרות האפליקציה של Expo. אז אפליקציית ה-iPhone שלך רצה ב-iPad במצב תאימות, בחלון בפורמט של iPhone. הגדרה ל-iPhone בלבד לא מגינה עליה מבדיקה ב-iPad. דווקא על iPad Air הדמו של Solys הפך לבלתי אפשרי לנצח, מקרה שמפורט במדריך של guideline 2.1.

יש שתי דרכים לצאת מזה. או שאתה באמת תומך ב-iPad, עם פריסה שמתאימה את עצמה למקום הפנוי. כללי העיצוב של אפל מבקשים לקבוע את הפריסה לפי size classes, לא לפי דגם המכשיר. או שאתה נשאר ב-iPhone, וכל מסך צריך להיכנס לחלון התאימות.

טקסט שקשה לקרוא

ההודעה, שפורסמה בינואר 2025: "Your app included hard to read type or typography." אפל מזכירה בה שמשתמשים מצפים לאפליקציות "simple, refined, and easy to use" (שרשור בפורום).

כללי הטיפוגרפיה של אפל נותנים נקודות ייחוס ל-iOS: 17 נקודות כברירת מחדל, 11 נקודות מינימום. כללי הנגישות דורשים ניגודיות של לפחות 4.5 ל-1 לטקסט עד 17 נקודות, ואזורי מגע של 44 על 44 נקודות כברירת מחדל.

מלכודת אם אתה מקטין פונטים במסכים קטנים, כמו שאני עושה כדי לשמור על אותן שבירות שורה בכל מקום: ודא שהטקסט הכי קטן שלך, אחרי ההקטנה ב-iPhone SE, נשאר לפחות 11 נקודות.

התחברות שנשלחת ל-Safari

ההודעה, שפורסמה בפורום של אפל: "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." אפל מבקשת לאפשר הרשמה והתחברות בתוך האפליקציה, וממליצה על תצוגת Safari מוטמעת.

ב-Expo, expo-web-browser מכסה את שני הצרכים בלי לצאת מהאפליקציה: openAuthSessionAsync פותח סשן אימות בחלון מודאלי, ו-openBrowserAsync מציג עמוד בתצוגת Safari מוטמעת. לעומת זאת, פתיחת ההתחברות עם Linking.openURL שולחת לאפליקציית Safari. הבחירה אילו אמצעי התחברות להציע שייכת לכלל אחר, 4.8.

Sign in with Apple שמשולב לא נכון

ההודעה, שפורסמה במאי 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." (שרשור בפורום).

התיעוד של expo-apple-authentication מסביר את המלכודת: השם והמייל מסופקים רק בהתחברות הראשונה. שמור אותם מיד, אחרת תתפתה לבקש אותם שוב. השתמש גם בכפתור שהספרייה מספקת: הצבע שלו נבחר עם buttonStyle והפינות עם cornerRadius, אף פעם לא דרך style.

4.0, 4.2, 4.3: שלוש דחיות עיצוב שלא כדאי לבלבל ביניהן

כלל	מה נבדק	תיקון
4.0	הממשק	לתקן את המסכים
4.2	התועלת של האפליקציה	להוסיף תוכן נייטיב
4.3	הדמיון לאחרות	להחליף קונספט

4.2, Minimum Functionality, דורש פיצ'רים, תוכן וממשק שמרימים את האפליקציה "beyond a repackaged website". הגבול מול 4.0 דק: אתר שעטוף באפליקציה יכול לחטוף את שתיהן. אם לאפליקציה שלך חסר תוכן, ליטוש המסכים לא יספיק.

4.3 מכוון להעתקות ולקטגוריות רוויות: פירטתי את שני הסעיפים שלו במדריך של guideline 4.3 Design Spam. ממשק מלוטש לא יציל אפליקציה שנראית כמו אלף אחרות.

רשימת הבדיקה הוויזואלית לפני הגשה

זה הדבר שאני מוסיף לכל הגשה. באפליקציות שלי, כל מסך מעוצב ל-iPhone הכי גדול, ואז מוקטן בקנה מידה אחד במכשירים הקטנים יותר: אותם יחסים, אותן שבירות שורה. אחר כך אני משווה את התוצאות זו לצד זו: iPhone SE, iPhone רגיל, ה-iPhone הכי גדול, ו-iPad בשביל מצב התאימות.

בדיקה	מכשיר	מה צריך להחזיק
הפעלה ראשונה	iPhone SE	שום דבר לא חתוך
אונבורדינג מלא	iPad	כל כפתור נגיש
מקלדת פתוחה	iPhone SE	השדה והכפתור גלויים
טקסט מוגדל	iPhone רגיל	אף טקסט לא נקטע
מצב כהה	כולם	טקסט קריא בכל מקום
אזורים בטוחים	הכי גדול	שום דבר מתחת ל-Dynamic Island
Paywall	iPhone SE	מחירים וקישורים גלויים
התחברות	iPad	נשארת בתוך האפליקציה

שלוש הבהרות:

• טקסט מוגדל. כללי הטיפוגרפיה של אפל מציעים בדיקה פשוטה: להפעיל את גדלי הטקסט הכי גדולים ב-Settings, Accessibility, Display & Text Size, ואז לוודא שהכול נשאר קריא.
• מצב כהה. הכללים של אפל למצב כהה דורשים שהאפליקציה תישאר קריאה בשני המראות. Expo מחיל light כברירת מחדל אם לא הגדרת userInterfaceStyle. Solys עוקבת אחרי הגדרת הטלפון, TradaZen נשארת כהה, Nolera בהירה: בשלושת המקרים אני בודק את המראה שמוצג.
• אזורים בטוחים. התוכן לא עובר מתחת ל-Dynamic Island ולא מתחת למחוון הבית. Expo מפרט את השיטה במדריך שלו על אזורים בטוחים.

ב-Mac, אפשר לשלוט בסימולטור משורת הפקודה, וזה הופך את הרצת הרשימה מחדש למהירה:

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

על טלפון אמיתי, אני עושה את אותו סיבוב עם build של TestFlight. מתודולוגיה: הרשימה הזו שלי, בנויה על הדחיות שהאפליקציות שלי ספגו, לא רשימה שאפל סיפקה. היא מצמצמת הפתעות בלי להבטיח אישור.

איך עונים לדחיית 4.0?

1. אתר את המכשיר והגרסה שמוזכרים בהודעה, ואז פתח את אותו דגם בסימולטור.
2. תקן את כל המופעים. ההודעה הטיפוסית מבקשת "address all instances" של הבעיה, לא רק את המסך שבצילום.
3. שלח build חדש: ה-reviewer בודק את הקוד שארוז באפליקציה.
4. ענה עם צילומי מסך מאותו מכשיר, דרך מענה להודעה של App Review.
5. הגש ערעור רק אם אתה בטוח: אפל מאפשרת לפנות ל-App Review Board, עם ערעור אחד בלבד לכל הגשה שנדחתה.

התבנית שהייתי משתמש בה, להתאמה:

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,

להכין הגשה בלי דחיית עיצוב

ה-Review Kit מרכז את הצ'קליסט שלי לפני הגשה, שמכסה בין השאר את כלל 2.4.1 על ה-iPad, ו-skills של Claude Code שעוברים על הפרויקט שלך. למבט אנושי, קבע איתי שעה: נפתח את המסכים שלך בכמה גדלים, בשיחת וידאו. התהליך המלא אחרי דחייה נמצא בעמוד אפליקציה שנדחתה על ידי אפל.

מכין את ההשקה הראשונה שלך? עשה את האבחון החינמי: הוא מסדר את השלבים לפי הסדר ושולח לך את הצ'קליסט שלי נגד דחיות של אפל.

שאלות נפוצות

מה המשמעות של "Guideline 4.0 - Design" בהודעת דחייה?

אפל חושבת שהממשק שלך מתחת לרמה הצפויה, בלי לכוון לתת-כלל מסוים: מסכים צפופים, טקסט שקשה לקרוא, תהליך התחברות שנחשב גרוע. ההודעה בדרך כלל מציינת את המכשיר שבו בדקו, ולעיתים קרובות מצרפת צילום מסך.

האפליקציה שלי מוגדרת ל-iPhone בלבד: למה אפל בודקת אותה ב-iPad?

כי כלל 2.4.1 קובע שאפליקציות iPhone ירוצו ב-iPad כשזה אפשרי. האפליקציה שלך נפתחת שם במצב תאימות, בחלון בפורמט של iPhone, וכל מסך צריך להישאר שמיש.

צריך build חדש אחרי דחיית 4.0?

כן, ברוב המקרים. ה-reviewer בודק את הקוד שארוז באפליקציה בהפעלה הראשונה, ותיקון שנשלח מרחוק עלול לא להגיע אליו. זה מה שאני מסביר במדריך של guideline 2.1.

מצב כהה הוא חובה כדי להתקבל?

הטקסט של כללי הבדיקה לא מחייב את זה. כללי העיצוב מזכירים שמשתמשים מצפים שהאפליקציות יעקבו אחרי ההגדרה שלהם. אם אתה כופה מראה בהיר או כהה, כמו ש-Expo מאפשר, בדוק את המראה הזה. אם אתה עוקב אחרי הגדרת הטלפון, בדוק את שניהם.

אפשר לערער על דחיית 4.0?

כן, מול ה-App Review Board, אם אתה חושב שהאפליקציה שלך עומדת בכללים. אפל מבקשת נימוקים מדויקים, ערעור אחד בלבד לכל הגשה שנדחתה, ולענות קודם לבקשות מידע.