App2Store ← מדריכים ← Base44 לגוגל פליי

איך מעלים אפליקציית Base44 לגוגל פליי: כל הדרך, שלב אחרי שלב

בניתם אפליקציה ב Base44 ורוצים אותה בגוגל פליי. Base44 מייצרת AAB, אבל נשארים חשבון המפתח, 12 בודקים ו 14 יום לכל בודק, Data Safety, מחיקת חשבון וגישה לפרודקשן.

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

מה Base44 כבר עושה בשבילכם, ואיפה זה נעצר

Base44 מייצרת בעצמה את קבצי החנות: IPA ל iOS ו AAB לאנדרואיד, בתוכנית Builder ומעלה. מה שהיא כותבת בתיעוד שלה במפורש שהיא לא עושה זה לפתוח את חשבונות המפתח, להגיש את האפליקציה ולטפל בביקורת של החנות. שם יושבת כל העבודה שנשארה.

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

על התוכנית הנדרשת: "You must be on the Builder plan or higher to download your app files." על חלוקת האחריות: "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."

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

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

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

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

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

מה שגוגל פליי מקבלת בפועל זה חבילת אנדרואיד אחת בפורמט AAB. זה לא עניין של סגנון אלא כלל מפורש: "From August 2021, new apps are required to publish with the Android App Bundle on Google Play." שלוש הדרכים נבדלות רק בשאלה מי מייצר את הקובץ הזה ומה יש בתוכו.

הדרך הראשונה היא הקובץ של Base44. זו הדרך הקצרה ביותר למי שכבר על תוכנית Builder ומעלה, והיא מניחה שיש לאפליקציה כתובת יציבה ופעילה.

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

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

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

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

חשבון מפתח, 25 דולר ואימות הזהות

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

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

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

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

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

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

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

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

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

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

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

גישה לפרודקשן היא בקשה, לא שלב אוטומטי

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

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

הטופס כולל שדות פתוחים, ואחד מהם מנוסח כך: "Summarize the feedback received from testers and describe how feedback was collected". מכאן מסקנה פרקטית. בקשה שממולאת כמו טופס ריק נראית כמו ניסיון לעבור מכשול, ובקשה שמתארת מה נבדק, אילו באגים תוקנו ומה שונה בעקבות המשוב נראית כמו מפתח שעשה את העבודה.

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

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

הבקשה לגישה לפרודקשן נדחתה: מה עושים

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

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

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

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

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

יעד API 36 מ 31 באוגוסט 2026

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

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

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

רישום שמות החבילה עד 30 בספטמבר 2026, ומה זה בעצם אימות המפתחים

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

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

הראשון הוא רישום שמות חבילה. זה החלק עם התאריך הגלובלי, וגוגל מרגיעה במידה: "While 99% of apps on Play have been registered automatically using information you have already provided, you should check your Play Console Home page." למי שפותח אפליקציה חדשה עכשיו זה עוד יותר פשוט: "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." הפעולה שלכם היא בדיקה, לא פרויקט.

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

השלישי הוא האכיפה ברמת ההתקנה במכשיר, וזה החלק שנכתב בכותרות בעברית כאילו הוא גלובלי. בציר הזמן הרשמי כתוב "September 30, 2026: Regional deadline in Brazil, Indonesia, Singapore, and Thailand for participating app stores" ואחריו "2027 and beyond: Global rollout for all certified Android devices."

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

עמוד החנות, Data Safety ומחיקת חשבון

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

דרישת מחיקת החשבון היא הסעיף שמפיל הכי הרבה אפליקציות מהסוג הזה מבין אלה שאנחנו מלווים, פשוט כי כשמתחברים בלחיצה אחת דרך גוגל אף אחד לא בונה מסך מחיקה. חשוב להבין שהתחברות פדרטיבית נחשבת יצירת חשבון לכל דבר. גוגל מנסחת את הדרישה ישירות: "The user must be able to request deletion of their account through the pathway." הדרישה כוללת גם מחיקה של הנתונים שנצברו, לא רק של רשומת המשתמש.

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

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

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

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

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

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

הטעויות שבאמת עולות זמן

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

נתחיל דווקא במה שהרבה מדריכים בעברית מפחידים בו שלא לצורך: מפתח החתימה. אם אתם מעלים App Bundle, ההעלאה רושמת את האפליקציה אוטומטית ל Play App Signing, וגוגל אומרת מה קורה כשמאבדים את מפתח ההעלאה: "If you lose your upload key or suspect that it was compromised, you are not locked out of your app." מאפסים את מפתח ההעלאה וממשיכים לשחרר לאותה רשומה, עם אותן התקנות ואותם דירוגים.

המצב שממנו באמת אין חזרה הוא אחר, וגם אותו גוגל מנסחת: "This key cannot be reset if you manage it yourself (without Play App Signing) and lose it." כלומר מי שבוחר לנהל את מפתח החתימה בעצמו ומאבד אותו, מאבד את היכולת לעדכן את האפליקציה. המסקנה המעשית: אל תברחו מ Play App Signing, וגבו בכל זאת את קובץ החתימה ואת הסיסמאות שלו בשני מקומות, כי איפוס עולה לכם ימים.

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

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

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

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

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

שאלות נפוצות

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