App2Store ← מדריכים ← Lovable לאפ סטור

Lovable לאפ סטור: מה אפל בודקת בהגשה ואיך נערכים לזה (2026)

איך מוציאים אפליקציית Lovable לאפ סטור ב 2026: ייצוא הקוד אל GitHub, build סטטי, אריזה עם Capacitor, והסעיפים שאנחנו רואים חוזרים בדחיות: 4.2, 4.2.6, 4.8, 5.1.1(v) ו 3.1.3(e).

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

איך מוציאים אפליקציית Lovable לאפ סטור

המסלול הוא ייצוא הקוד של Lovable אל GitHub, מעבר ל build סטטי, אריזה עם Capacitor כשכל הנכסים יושבים בתוך הבינארי, והגשה מחשבון Apple Developer שרשום עליכם. אף אחד לא יכול להבטיח אישור של אפל, ומהדחיות שאנחנו רואים בשלב הזה חוזרים חמישה סעיפים: 4.2, 4.2.6, 4.8, 5.1.1(v) ו 3.1.3(e).

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

הסדר שעובד אצלנו: מוציאים את הקוד אל GitHub, מוודאים שהפרויקט נבנה כ build סטטי, אורזים עם Capacitor כך שכל קובץ HTML, JavaScript, CSS ותמונה נמצא בתוך האפליקציה, מוסיפים יכולות שדפדפן לא נותן, וסוגרים את חמשת הסעיפים שחוזרים בדחיות שאנחנו רואים על אפליקציות שנבנו בכלי AI: 4.2, 4.2.6, 4.8, 5.1.1(v) ו 3.1.3(e). בסוף מגישים עם חשבון דמו פעיל.

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

שלב ראשון: ייצוא הקוד אל GitHub

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

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

הראשון הוא משתני סביבה. כל מה שנארז אל תוך אפליקציית מובייל נחשב ציבורי, כי מי שמתעקש יכול לפתוח את חבילת האפליקציה ולקרוא את המחרוזות שבתוכה. מפתח anon של Supabase נועד לשבת בצד הלקוח ומוגן על ידי מדיניות RLS, אבל מפתח service role לא אמור להיות שם לעולם, וכך גם מפתחות API של ספקים חיצוניים שאתם משלמים עליהם לפי שימוש.

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

בעיית ה SSR: למה חייבים build סטטי

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

כאן יש חדשות טובות: ברירת המחדל של Lovable היא בדיוק מה שצריך. הפלט הרגיל הוא React עם TypeScript, Vite ו Tailwind, כלומר אפליקציית עמוד יחיד שכל הניתוב שלה קורה בצד הלקוח, עם קובץ index.html אחד כנקודת כניסה. לכן ברוב המקרים זו לא עבודה אלא אימות: מריצים build ומוודאים שהתיקייה שנוצרת נפתחת בכוחות עצמה.

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

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

אריזה עם Capacitor, כשכל הנכסים בפנים

Capacitor עוטף את ה build הסטטי בפרויקט Xcode אמיתי ומעתיק את כל הנכסים אל תוך הבינארי. זה ההבדל בין אפליקציה שנבדקת כאפליקציה לבין WebView שמצביע על אתר חי, שאפל מתארת בסעיף 4.2 כ repackaged website.

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

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

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

הבנייה והחתימה דורשות סביבת macOS עם Xcode ופרופילי חתימה, או שירות בנייה בענן שמריץ את זה בשבילכם. התיעוד של Expo מנסח את זה כך: "iOS builds run on macOS runners hosted in Expo's macOS cloud", ובעמוד ההתקנה מוסיף "If you are going to use EAS Build to create release builds for the Apple App Store, you need access to an account with a $99 USD Apple Developer Program membership". כלומר אפשר לוותר על מק מקומי, אבל לא על חברות בתוכנית המפתחים של אפל.

סעיף 4.2: למה אתר עטוף נדחה ומה באמת מבדיל אפליקציה

סעיף 4.2 דורש שהאפליקציה תכלול תכונות, תוכן וממשק שמרימים אותה מעבר לאתר ארוז מחדש, ובלשון אפל: "Your app should include features, content, and UI that 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: הכלל לא אוסר על אפליקציה להכיל תוכן שיווקי או קישורים, אלא על אפליקציה להיות בעיקרה כזו, ויש בו גם פטור מפורש לקטלוגים. אפליקציה שמבוססת על אתר אינה פסולה מעצם קיומה.

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

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

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

סעיף 4.2.6: מי בכלל רשאי להגיש אפליקציה שנוצרה בכלי AI

סעיף 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 and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences". לכן ההגשה חייבת לצאת מחשבון Apple Developer שרשום עליכם.

האם Lovable או Base44 נחשבים app generation service לצורך הסעיף הזה, זו הפרשנות שאנחנו עובדים לפיה ולא ניסוח של אפל. אפל כותבת commercialized template או app generation service, והיא לא מפרסמת רשימה של כלים. אנחנו מעדיפים להיערך לפי הפרשנות המחמירה, כי המחיר של טעות כאן הוא דחייה שקשה לתקן בדיעבד. מהשיחות שאנחנו מנהלים, זה סעיף שכמעט לא עולה בפני מי שבנה אפליקציה בכלי AI בישראל.

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

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

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

סעיף 4.3(b): קטגוריות רוויות, והכלל החדש מיוני 2026

אפל לא מקבלת הגשות חדשות בקטגוריות רוויות אלא אם הן מציעות חוויה שונה או משופרת באופן משמעותי. בלשונה: "Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience".

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

הפתיחה של הסעיף רחבה מהרשימה: "Don't submit apps that are indistinguishable from what's already widely available". הרשימה היא דוגמאות, לא גבול. אם בניתם בכלי וייב קודינג משהו שדומה מאוד לאפליקציות קיימות, כדאי להיערך לשאלה הזאת מראש ולא להיתקל בה אחרי ההגשה.

יש לסעיף גם שיניים: "Repeated submissions of this kind may lead to removal from the Apple Developer Program". כלומר הגשות חוזרות של אותו סוג אפליקציה מאותו חשבון הן סיכון ברמת החשבון ולא רק ברמת ההגשה. זה רלוונטי במיוחד למי שמתכנן להוציא כמה אפליקציות דומות מאותו חשבון מפתח.

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

סעיף 4.7.5 וקוד שנטען מרחוק

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

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

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

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

סעיף 4.8: האם חייבים Sign in with Apple

סעיף 4.8 לא כותב בשום מקום שחייבים Sign in with Apple. הוא מחייב שאפליקציה שמשתמשת בשירות התחברות של צד שלישי או רשת חברתית תציע גם אפשרות שקולה שעומדת בשלושה תנאים: איסוף מוגבל לשם ולכתובת מייל, אפשרות למשתמש לשמור את כתובת המייל שלו פרטית, ואיסור על איסוף אינטראקציות לצורכי פרסום בלי הסכמה.

הנוסח הרשמי של הדרישה הוא: "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: 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".

הרבה אפליקציות Lovable נתקעות כאן, כי הרבה פרויקטים מפעילים ב Supabase גם התחברות עם Google, ואז הסעיף חל עליכם. לגבי ברירות המחדל של Supabase כדאי לדייק: התיעוד שלה אומר "Email authentication is enabled by default", כלומר מייל וסיסמה עובדים מהרגע הראשון, וספק Google הוא משהו שמפעילים ומגדירים בנפרד.

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

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

סעיף 5.1.1(v): מחיקת חשבון מתוך האפליקציה

אם האפליקציה מאפשרת יצירת חשבון, סעיף 5.1.1(v) מחייב שתהיה בתוך האפליקציה עצמה גם דרך למחוק את החשבון. גוגל מחייבת גם מסלול בתוך האפליקציה וגם כתובת אינטרנט למחיקה שמוצהרת בטופס בטיחות הנתונים, וגם התחברות יחידה מספק חיצוני נכנסת שם להגדרה, כי גוגל מונה מנגנוני זיהוי "such as password, phone number OTP (one-time password), 2FA (two-factor authentication), biometric, SSO (single sign-on), and so on".

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

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

בצד של גוגל צריך בנוסף דף אינטרנט שמסביר איך למחוק חשבון ונתונים, והכתובת שלו נכנסת לשדה ייעודי במקטע Data safety בעמוד App content ב Play Console. גוגל מנסחת את הדרישה כך: "The user must be able to request deletion of their account through the pathway", ומוסיפה שהמסלול צריך לעבוד "without sending the user back to the app and requiring them to re-download it to submit their request". גוגל גם דורשת שהקישור יהיה פעיל, שמסלול הבקשה יהיה בולט וקל לאיתור בעמוד, ושהעמוד יזכיר את שם האפליקציה או שם המפתח כפי שהם מופיעים בעמוד החנות שלכם. לא מצאנו בתיעוד הרשמי דרישה מפורשת שהעמוד יהיה נגיש בלי התחברות, ולכן אנחנו לא מציגים את זה כציטוט, רק ממליצים עליו. הדף הזה סוגר מראש סיבה נפוצה לסבב נוסף מול הצוות של גוגל.

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

אפל דורשת בסעיף 5.1.1(i) קישור למדיניות הפרטיות בשני מקומות: בשדה הייעודי ב App Store Connect וגם בתוך האפליקציה עצמה, באופן נגיש. גוגל דורשת קישור למדיניות פרטיות בעמוד החנות, והיא בודקת שהמדיניות עקבית עם מה שהצהרתם בטופס בטיחות הנתונים.

הנוסח של אפל: "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner". שימו לב ל within the app. הרבה אפליקציות שנבנו בכלי AI מגיעות עם מדיניות פרטיות באתר בלבד, וזה חצי מהדרישה.

בפועל זה אומר קישור אחד בעמוד ההגדרות או בעמוד החשבון שפותח את המדיניות, ואותה כתובת בדיוק בשדה של App Store Connect. אם המדיניות שלכם נוצרה בכלי אוטומטי, קראו אותה לפני ההגשה ובדקו שהיא מתארת את מה שהאפליקציה באמת אוספת, כולל שירותי צד שלישי כמו Supabase, ספק אנליטיקה או ספק מודל שפה אם אתם שולחים אליו טקסט של משתמשים. על הנקודה האחרונה אפל מפורשת בסעיף 5.1.2(i): "You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so". כלומר לא מספיק לגלות, צריך גם לבקש רשות.

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

סעיף 3.1.3(e): מתי חייבים רכישה מתוך האפליקציה ומתי אסור

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

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

תור למספרה, שולחן במסעדה, משלוח אוכל, מוצר פיזי או שיעור פרונטלי הם שירותים שנצרכים מחוץ לאפליקציה, ולכן הם נגבים בתשלום רגיל דרך ספק סליקה, בלי לתת לאפל אחוזים. מנוי, פתיחת פיצ׳ר, הסרת פרסומות, קרדיטים או תוכן דיגיטלי הם רכישה בתוך האפליקציה. הנוסח של אפל בסעיף 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".

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

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

סעיף 4.1(c): אייקון ושם שאינם שלכם

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

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

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

חשבון הדמו: הכשל שהופך דחייה רגילה למשהו הרבה יותר גרוע

אם יש באפליקציה מסך התחברות, סעיף 2.1(a) דורש למסור לבודק פרטי חשבון דמו בשדה המיועד. אפל מנסחת את זה כך: "include demo account info (and turn on your back-end service!)". אם אתם לא יכולים לספק חשבון דמו מטעמים משפטיים או אבטחתיים, אפל מאפשרת חלופה: "you may include a built-in demo mode in lieu of a demo account with prior approval by Apple".

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

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

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

הצהרת סטטוס סוחר לפי ה DSA, גם למי שמפיץ רק בישראל

אפל מבקשת מכם להצהיר על סטטוס סוחר גם אם אתם לא מפיצים באיחוד האירופי. בלשון התיעוד של App Store Connect: "Even if you don't distribute apps in the EU, you'll still need to declare a trader status". אפל גם כותבת במפורש "Apple can't determine whether you're a trader", כלומר ההחלטה עליכם.

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

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

לגבי Google Play, לא מצאנו עמוד עזרה רשמי של גוגל שמחייב הצהרת סוחר לפי ה DSA מכל מפתחי Play, ולכן אנחנו לא טוענים את זה. עמוד ה EEA הרשמי של גוגל עוסק ב Digital Markets Act, שזה רגולציה אחרת. אם אתם רואים מישהו שמציג את זה כדרישה גורפת בשתי החנויות, בקשו ממנו קישור.

מה כל זה אומר על העלות ועל לוח הזמנים

חשבון Apple Developer עולה 99 דולר לשנה וחשבון Google Play עולה 25 דולר בתשלום חד פעמי, שניהם משולמים ישירות לחנויות ונרשמים עליכם. החבילות שלנו מתחילות ב 2,490 שקלים לחנות אחת ו 3,990 שקלים לשתי החנויות. אפל מפרסמת ש "On average, 90% of submissions are reviewed in less than 24 hours", אבל זה ממוצע ולא התחייבות, ומה שקובע בפועל את התאריך הוא מספר סבבי הדחייה ולא הבדיקה הראשונה.

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

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

אם אתם רוצים גם את גוגל פליי, אותו פרויקט Capacitor מייצר גם את הצד של אנדרואיד, אבל שם נכנס משחק אחר. גוגל כותבת: "Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers", ומוסיפה "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days". בודק שנרשם, בדק פחות מ 14 יום ואז יצא לא נספר. הדרישה מנוסחת על חשבונות אישיים, וחשבונות ארגוניים לא מוזכרים בה. עמוד העזרה לא אומר במפורש אם אפליקציה שנייה מאותו חשבון חייבת לעבור את המסלול שוב אחרי שכבר התקבלה גישה לייצור, ולכן אנחנו לא טוענים לכיוון זה או אחר, ומתכננים לפי מה שכתוב. את הצד של גוגל פירטנו במדריך על Base44 וגוגל פליי.

עוד תאריך שכדאי להכיר אם אתם גם בגוגל: גוגל מבקשת לרשום את שמות החבילה של האפליקציות בעמוד הבית של Play Console, ובלשונה "By September 30, 2026, register any remaining apps you want to continue distributing to avoid global removal from Google Play". גוגל גם כותבת שהיא כבר רשמה אוטומטית 99 אחוז מהאפליקציות, כך שברוב המקרים מדובר בבדיקה קצרה בקונסולה ולא בעבודה.

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

שאלות נפוצות

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