App2Store ← מדריכים ← וייב קודינג לחנות

בניתי אפליקציה עם וייב קודינג. איך מוציאים אותה לחנות?

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

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

מה באמת עומד בין אפליקציה שעובדת לבין החנות

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

הכלי שבנה את האפליקציה, בין אם זה בייס 44, לאבבל, v0, Meta AI או Firebase Studio, מייצר מוצר שעובד בדפדפן. החנויות לא מקבלות דפדפן. הן מקבלות קובץ בילד חתום, עם שם חבילה, מספר גרסה, הרשאות מוצהרות ומדיניות פרטיות שמישהו קורא בפועל. זה הרגע שבו אנשים מגיעים אלינו.

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

חלק מהכלים כבר סוגרים את החלק הטכני של הפער בעצמם, וכדאי לדעת את זה לפני שקונים שירות. בייס 44 מייצרת היום קבצי IPA לאייפון וקבצי AAB לאנדרואיד, בתוכנית Builder ומעלה, וכותבת בתיעוד שלה במפורש מה נשאר עליכם: "You are responsible for setting up and paying for your Apple and Google developer accounts, as well as managing your app listings and submissions." ובאותו עמוד: "Base44 support does not check on the status of your submission, contact Apple or Google on your behalf, or manage store review feedback for you."

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

וחשוב להגיד את זה בפתיחה ולא בסוף: אף אחד לא שולט באישור. לא אנחנו, לא אף חברה אחרת, וגם לא הכלי שבנה לכם את האפליקציה. בייס 44 כותבת את זה על עצמה במילים האלה: "Base44 cannot guarantee that an app is approved, even with a high readiness score." מה שכן אפשר לשלוט בו זה להגיע להגשה בלי הטעויות הצפויות מראש, וזה מה שהמדריך הזה מפרט.

ההחלטה הראשונה: חשבון מפתח פרטי או חשבון של חברה

לרוב מי שמגיע עם אפליקציה אחת, חשבון פרטי הוא הבחירה הנכונה, אבל הוא זה שמחייב בדיקה סגורה, וחשבון של חברה פוטר ממנה. זו ההחלטה שקובעת את לוח הזמנים. חשבון מפתח פרטי שנפתח אחרי 13 בנובמבר 2023 חייב להריץ בדיקה סגורה לפני שהאפליקציה כשירה להפצה, ובלשון גוגל: "Google Play requires personal developer accounts created after November 13, 2023, to test their apps before those apps are eligible for distribution on Google Play." חשבונות ארגוניים לא מוזכרים בדרישה הזאת.

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

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

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

ושאלה שחוזרת אצל מי שכבר פרסם פעם אחת: עמוד העזרה של גוגל מנסח את הדרישה ברמת האפליקציה, "must run a closed test for their app with a minimum of 12 testers", אבל הוא לא אומר במפורש מה קורה עם אפליקציה שנייה באותו חשבון פרטי אחרי שכבר התקבלה גישה לייצור. אין לנו תשובה מנוסח רשמי, ולכן אנחנו בונים לוח זמנים בהנחה שהמסלול חוזר, ובודקים את המצב בפועל בקונסולה שלכם לפני שמתחייבים לתאריך.

בדיקה סגורה בגוגל: 12 בודקים, 14 יום, ואיך התנאי מנוסח בדיוק

12 הבודקים צריכים להיות רשומים לבדיקה הסגורה ברגע שאתם מגישים את הבקשה לגישה לייצור, ורצופים לאורך 14 הימים שקדמו להגשה. הנוסח של גוגל: "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."

המילה הקובעת בנוסח הזה היא preceding. לא מספיק שהיו לכם 12 בודקים במשך שבועיים מתישהו. הם צריכים להיות רשומים ברגע ההגשה, ורצופים לאורך השבועיים שלפניה. גוגל גם סוגרת את הפרצה הברורה במשפט נפרד: "Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement."

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

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

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

בטופס הבקשה גוגל שואלת על גיוס הבודקים, והשאלה מנוסחת כך: "Select an option indicating how easy it was to recruit testers for your app". כלומר גוגל שואלת כמה קל היה לגייס, לא איך גייסתם. באותו עמוד עזרה גוגל גם כותבת מה הדרך שהיא מציינת: "The most common way to recruit testers is to use personal and professional networks." יש בטופס גם שדות פתוחים, למשל "Summarize the feedback received from testers and describe how feedback was collected", ושם אתם מתארים את הבדיקות ואת המשוב.

את גיוס הבודקים מפעיל אצלנו השירות השני שלנו, 12testersisrael.com, ושם נמצא ההסבר המלא על המסלול הזה.

אפל: למה אתר עטוף נופל בסעיף 4.2.2, ומה עומד בדרישות

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

סעיף 4.2 עצמו מנוסח בלשון should include ולא כחובה. הוא מצפה שהאפליקציה תביא פיצ׳רים, תוכן וממשק שעושים אותה למשהו מעבר לאתר שנארז מחדש. והמונח web clippings שמופיע בסעיף 4.2.2 הוא לא מונח משפטי, הוא תיאור של אפליקציה שהיא בעצם קיצור דרך לאתר.

אפליקציה שכל תפקידה הוא לטעון כתובת מרוחקת בתוך WebView היא המקרה שהתיאור הזה מכוון אליו. בגוגל הכלל קיים גם הוא, אבל הוא מנוסח אחרת, וההבדל בין החנויות הוא בניסוח ולא בקיום של הדרישה. מדיניות Minimum Functionality של גוגל אומרת: "Apps should provide a stable, responsive, and engaging user experience. Apps that crash, do not have the basic degree of adequate utility as mobile apps, lack engaging content, or exhibit other behavior that is not consistent with a functional and engaging user experience are not allowed on Google Play." יש לגוגל גם סעיף ייעודי ל WebView, במדיניות Webviews and Affiliate Spam: "We don't allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator." שימו לב למה שהסעיף הזה תולה בו את האיסור, והוא הרשאה של בעל האתר. מי שעוטף את האתר של עצמו הוא לא מי שהסעיף מכוון אליו. זו אמירה על הכלל, לא תחזית לגבי החלטה של אף אחת מהחנויות.

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

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

שישה סעיפים שצריך להוסיף לאפליקציה שנבנתה בוייב קודינג

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

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

מחיקת חשבון. אפל דורשת בסעיף 5.1.1(v) שאפליקציה שמאפשרת יצירת חשבון תאפשר גם מחיקה שלו מתוך האפליקציה. גוגל דורשת שני מסלולים, אחד בתוך האפליקציה ואחד בכתובת ווב שמוצהרת בטופס Data Safety, וגם מחיקה של הנתונים המשויכים. לגבי כתובת הווב גוגל כותבת: "The weblink must be functional (for example, loads without error), relevant in scope", והמסלול צריך להסתיים בלי להחזיר את המשתמש לאפליקציה ולדרוש ממנו להוריד אותה שוב כדי להגיש את הבקשה. ושימו לב לנקודה שקל לפספס: התחברות דרך גוגל היא יצירת חשבון לכל דבר. מהפרויקטים שאנחנו רואים, כפתור ההתחברות דרך גוגל מגיע מהכלים האלה כברירת מחדל, ומסלול המחיקה לא מגיע איתו.

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

תוכן משתמשים. אפליקציה עם צ׳אט או עם תוכן שמשתמשים מעלים צריכה מנגנון דיווח וחסימה שזמין מתוך האפליקציה, וזו דרישה של שתי החנויות: במדיניות User Generated Content של גוגל, ובסעיף 1.2 של אפל שדורש "A mechanism to report offensive content and timely responses to concerns" וגם "The ability to block abusive users from the service".

תשלומים. אם אתם מוכרים שירות שנצרך מחוץ לאפליקציה, למשל תור למספרה או משלוח, סעיף 3.1.3(e) מנוסח כך: "If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments" ואוסר לגבות עליו דרך רכישה מתוך האפליקציה. אם לעומת זאת אתם פותחים פיצ׳ר דיגיטלי בתוך האפליקציה, אתם חייבים רכישה מתוך האפליקציה, ובאנדרואיד את Play Billing. אפשר לטעות כאן בשני הכיוונים, והם שני סעיפים נפרדים. נקודה נוספת שכדאי להכיר: בחנות של ארצות הברית אפל לא דורשת entitlement כדי לכלול כפתור או קישור חיצוני לרכישה, ומחוץ לחנות הזאת עדיין צריך entitlement. זה פטור לפי חנות, לא לפי מיקום המפתח.

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

שני מועדים בשנת 2026, ומה באמת קורה עם אימות מפתחי אנדרואיד

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

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

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

הראשון, רישום שמות חבילה בעמוד הבית של Play Console. זה מה שנוגע לכם ישירות, גם בישראל, וזה המועד של 30 בספטמבר 2026. גוגל כותבת: "While 99% of apps on Play have been registered automatically using information you have already provided, you should check your Play Console Home page." המספר הוא 99 אחוז ולא כולם, וההוראה היא ללכת ולבדוק. לאפליקציה חדשה שנוצרת בקונסולה גוגל כותבת שהרישום נעשה אוטומטית: "For new apps, when you create an app in the Google Play Console, Google Play automatically registers the package name and links it to your account."

השני, אימות זהות המפתח. אם כבר עברתם את אימות הזהות של Play Console, גוגל אומרת שאין פעולה חדשה לבצע: "For most Play developers, no new action is required for identity verification."

השלישי, החסימה בפועל של התקנות במכשירים. זו האזורית, וזה מה שכן מוגבל לארבע מדינות: "These new developer verification protections will take effect on September 30, 2026, starting with users in Brazil, Indonesia, Singapore, and Thailand." ההרחבה הגלובלית של המנגנון הזה מתוכננת בשנת 2027.

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

כמה זמן זה לוקח, ומה אנחנו עושים בפועל

הרצפה בגוגל היא 14 יום. זה המינימום של הבדיקה הסגורה לפני שאפשר בכלל להגיש בקשה לגישה לייצור, ואחריו נוספים זמן הבדיקה של הבקשה אצל גוגל וזמן ביקורת ההגשה עצמה. אפל מפרסמת ש "On average, 90% of submissions are reviewed in less than 24 hours", אבל זה ממוצע ולא התחייבות, ואנחנו לא נותנים תאריך אישור, כי אף אחד לא שולט בו.

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

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

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

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

שאלות נפוצות

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