App2Store ← מדריכים ← דחייה מאפל

אפל דחתה את האפליקציה שלי. מה אומר מספר ההנחיה במכתב הדחייה

קיבלתם דחייה מאפל ולא ברור מה אומר המספר במכתב. הסבר בעברית לסעיפים 4.2, 4.2.6, 4.8, 5.1.1, 3.1.3 ו 2.1, מה צריך לתקן ואיך מגישים מחדש.

עודכן ב 16 באוגוסט 2026. כל ציטוט באנגלית בעמוד הזה הוא הנוסח הרשמי של Google או של Apple כלשונו.

דחייה מאפל היא הודעה עם מספר, לא סוף הדרך

המספר במכתב מזהה את הסעיף שנכשל, אבל מכתב אחד יכול לכסות רק חלק מהבעיות, ולכן כדאי לעבור על כל הסעיפים הרלוונטיים לפני שמגישים שוב. ההודעה מגיעה בתוך Resolution Center שבמערכת App Store Connect, והיא מפנה לסעיף מתוך מסמך ההנחיות של אפל, App Review Guidelines.

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

הדבר הראשון שצריך לעשות הוא למצוא במכתב את המספר. הסעיפים שאנחנו רואים חוזרים אצל אפליקציות שנבנו בכלי וייב קודינג הם 4.2, 4.2.6, 4.8, 5.1.1, 3.1.3 וגם 2.1. כל אחד מהם הוא עולם בפני עצמו, וחלקם מצריכים שינוי במוצר ולא רק תיקון בטופס ההגשה.

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

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

סעיף 4.2: האפליקציה נראית כמו אתר שנארז מחדש

סעיף 4.2 מבקש שהאפליקציה תכלול פיצ׳רים, תוכן וממשק שהופכים אותה למשהו יותר מאתר שנארז מחדש, ובלשון אפל "elevate it beyond a repackaged website". סעיף 4.2.2 מנוסח כך: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." זו הדחייה שאנחנו רואים הכי הרבה אצל אפליקציות שנבנו בכלי וייב קודינג.

שימו לב לשתי מילים בנוסח הרשמי, כי הן משנות את כל התמונה. המילה "primarily" אומרת שהאיסור הוא על אפליקציה שהיא בעיקרה חומר שיווקי או אוסף קישורים, ולא על כל אפליקציה שמכילה תוכן כזה. הפתיחה "Other than catalogs" היא פטור מפורש לקטלוגים. כלומר אסור לכתוב שאפל דוחה כל אפליקציה שמבוססת על אתר, זה פשוט לא מה שכתוב.

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

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

עוד סעיף שתופס אפליקציות שמושכות תוכן בהפעלה הראשונה הוא 4.2.3(iii), ובלשון אפל "If your app needs to download additional resources in order to function on initial launch, disclose the size of the download and prompt users before doing so." לצידו עומד 4.2.3(ii), שמנוסח כך: "Make sure you include sufficient content in the binary for the app to function at launch." שני הסעיפים האלה הם הנימוק האמיתי לארוז את הנכסים בתוך הבילד.

סעיף 4.7.5: למה כנראה הוא לא הסעיף שלכם

אם האפליקציה שלכם מציגה את האתר שלכם עצמכם, סעיף 4.7.5 כנראה לא חל עליה, והחשיפה האמיתית שלכם היא סעיף 4.2. סעיף 4.7 נפתח ברשימה סגורה: "Apps may offer certain software that is not embedded in the binary, specifically HTML5 and JavaScript mini apps and mini games, streaming games, chatbots, and plug-ins." הפועל הוא offer, כלומר הסעיף מדבר על אפליקציה שמארחת תוכנה של אחרים, לא על אפליקציה שמציגה את עצמה.

שווה לעצור על הסעיף הזה דווקא בגלל שהוא מצוטט הרבה לא במקום. המילה שקובעת בנוסח היא "specifically", והיא הופכת את הרשימה לסגורה: מיני אפליקציות ומיני משחקים ב HTML5 וב JavaScript, משחקי סטרימינג, צ׳אטבוטים ותוספים. זה העולם של סופר אפליקציות ופלטפורמות שמארחות תוכן של צד שלישי.

אפליקציה שנבנתה בבייס 44 או בלאבבל ומציגה את האתר של בעליה איננה מציעה תוכנה לאף אחד, היא עצמה האפליקציה. לכן הדיון עליה נשאר בסעיף 4.2, ובסעיפי המשנה של 4.2.3.

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

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

סעיף 4.2.6: אפליקציות שנוצרו בשירות ליצירת אפליקציות

אפליקציה שנוצרה בשירות ליצירת אפליקציות תידחה אלא אם היא מוגשת ישירות מהחשבון של בעל התוכן. בלשון אפל: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients."

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

מה זה אומר בפועל: ההגשה צריכה לצאת מחשבון המפתח שלכם, כשאתם בעל התוכן. אצלנו זה ממילא המודל, החשבונות נפתחים ונשארים על שמכם ואנחנו עובדים בתוכם.

הצד השני של אותו סעיף הוא שהאפליקציה צריכה להיראות כמוצר עצמאי ולא כמו תבנית שמולאה בשמות אחרים. הנוסח מדבר על "customized, innovative apps that provide unique customer experiences", ולכן תוכן ייחודי, מיתוג משלכם ופיצ׳ר שבאמת שייך למוצר עושים כאן את ההבדל.

סעיף 4.8: התחברות עם אפל, המיתוס והניסוח האמיתי

סעיף 4.8 לא כתוב כחובה להטמיע Sign in with Apple. הוא דורש שאפליקציה שמשתמשת בשירות התחברות של צד שלישי תציע גם חלופה שוות ערך, ובלשון אפל: "the login service limits data collection to the user's name and email address; the login service allows users to keep their email address private as part of setting up their account; and the login service does not collect interactions with your app for advertising purposes without consent."

הנוסח המלא של הסעיף מתחיל כך: "Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service with the following features", ואחריו שלושת המאפיינים שלמעלה. שימו לב שאפל כותבת "another login service" ולא נוקבת בשם המוצר שלה. בפועל, Sign in with Apple עומד בשלושת המאפיינים, כולל הקריטריון של שמירת המייל בפרטיות, ולכן הוא מסלול הטמעה פשוט, אבל הוא לא הדרך היחידה שהסעיף מאפשר. לכן אסור לומר שאפל מחייבת Sign in with Apple.

יש פטור מפורש והוא רלוונטי מאוד לקהל הזה. בלשון אפל, חלופה אינה נדרשת אם "Your app exclusively uses your company's own account setup and sign-in systems". כלומר אפליקציה שמציעה רק מייל וסיסמה משלכם, בלי שום ספק התחברות חיצוני, לא נדרשת לחלופה בכלל. הפטורים הנוספים ברשימה נוגעים לחנויות אפליקציות חלופיות, לאפליקציות חינוך וארגונים, לזיהוי אזרחי ממשלתי, וללקוח של שירות צד שלישי מסוים.

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

סעיף 5.1.1: מחיקת חשבון מתוך האפליקציה, ומדיניות הפרטיות

אם האפליקציה מאפשרת יצירת חשבון, סעיף 5.1.1(v) דורש שהיא תאפשר גם מחיקת חשבון מתוך האפליקציה, ואפל מבהירה בעמוד התמיכה שלה ש"only offering to temporarily deactivate or disable an account is insufficient". במקביל, סעיף 5.1.1(i) דורש קישור למדיניות פרטיות גם במטא דאטה בתוך App Store Connect וגם בתוך האפליקציה עצמה.

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

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

לגבי כתובת המחיקה בווב חשוב לדייק, כי מסתובבת בעברית גרסה שגויה של הדרישה. גוגל לא כותבת שהעמוד חייב להיות נגיש בלי התחברות. מה שהיא כן דורשת הוא ש"The user must be able to request deletion of their account through the pathway", שהקישור יהיה תקין ורלוונטי, ובלשונה "The weblink must be functional (for example, loads without error), relevant in scope", ושהמסלול יעבוד "without sending the user back to the app and requiring them to re-download it to submit their request". בנוסף העמוד צריך להזכיר את שם האפליקציה או המפתח, כדי שיהיה ברור לאיזה שירות הוא שייך. גוגל לא אוסרת בנוסח שלה לבקש מהמשתמש להיכנס לחשבון שלו כדי לאמת זהות.

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

3.1.3(e) ו 3.1.1: מתי אסור IAP ומתי הוא חובה

על מוצרים ושירותים פיזיים שנצרכים מחוץ לאפליקציה גובים בתשלום רגיל, בכרטיס אשראי או Apple Pay, ולא דרך רכישה מתוך האפליקציה. אפל מנסחת את זה כ"physical goods or services that will be consumed outside of the app". מנגד, על תוכן ופיצ׳רים דיגיטליים שנפתחים בתוך האפליקציה חלה חובת רכישה מתוך האפליקציה.

הנוסח של סעיף 3.1.1 הוא: "If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase." זה הכלל, וזה הצד שאנחנו רואים עסקים ישראלים מגלים מאוחר מדי.

זה כיוון שאנחנו רואים אנשים מבינים הפוך, ובשני הכיוונים. חנות שמוכרת מוצר שנשלח לבית, אפליקציית תורים למספרה, הזמנת שולחן במסעדה או שירות שמבוצע פיזית, כל אלה לא אמורים לעבור דרך מנגנון הרכישות של אפל. מנגד, מנוי שפותח פיצ׳ר בתוך האפליקציה, הסרת פרסומות או תוכן פרימיום דיגיטלי מחייבים IAP באפל ו Play Billing בגוגל. השאלה הנכונה היא לא איך נמנעים מהעמלה אלא איזה כלל חל עליכם, כי טעות בכל אחד משני הכיוונים היא דחייה.

יש כאן חריג שכדאי להכיר, והוא לפי חנות ולא לפי מיקום המפתח. בסעיף 3.1.1(a) אפל כותבת: "These entitlements are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps." כלומר בחנות האמריקאית יש כיום חריגים לקישור החוצה לרכישה, ואפליקציה ישראלית שמופצת בכל העולם יושבת גם על החנות הזו. ברירת המחדל, ובכלל זה החנות הישראלית, נשארת רכישה מתוך האפליקציה.

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

סעיף 2.1: חשבון הדמו, וסעיף 2.3.1 שמסלים את הסיפור

אם באפליקציה יש התחברות, סעיף 2.1 דורש שתספקו בהערות הבדיקה פרטי חשבון דמו פעילים ושהשרת יהיה חי בזמן הבדיקה, ואפל אפילו מוסיפה שם את המשפט "turn on your back-end service!". בלי זה הבודק לא יכול להיכנס, ובלי כניסה אין בדיקה.

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

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

לגבי מצב דמו מובנה בתוך האפליקציה, זו לא חלופה חופשית לחשבון דמו. אפל מתירה אותו רק כשלא ניתן לספק חשבון, ובלשונה "If you are unable to provide a demo account due to legal or security obligations", רק באישור מראש שלה, "with prior approval by Apple", ובתנאי ש"Ensure the demo mode exhibits your app's full features and functionality."

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

מה עושים בפועל אחרי שקיבלתם דחייה

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

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

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

אם אתם רוצים שמישהו יעבור על מכתב הדחייה איתכם, אפשר לשלוח אותו בוואטסאפ 055 267 2300. בדיקת ההתאמה הראשונית היא בחינם, וגם אם התשובה היא שצריך לשנות את המוצר עצמו ולא רק את ההגשה, עדיף לדעת את זה עכשיו. השירות המלא מתחיל ב 1,190 שקל לגוגל פליי בלבד וב 2,490 שקל לשתי החנויות, כשחשבונות המפתח נפתחים ונשארים על שמכם. פירוט מלא של האגרות ושל העלויות הנלוות נמצא בעמוד כמה עולה להעלות אפליקציה לחנות.

שאלות נפוצות

מדריכים נוספים: Base44 לגוגל פליי · Lovable לאפ סטור · כמה זה עולה · וייב קודינג לחנות