چطور یک اپ را در Google Play منتشر کنیم: مراحل واقعی Play Console

برای انتشار یک اپ در Google Play، یک حساب توسعه‌دهنده Google Play بسازید (هزینه ثبت یک‌باره ۲۵ دلاری از نوامبر ۲۰۲۶)، اپ را در Play Console بسازید، لیست فروشگاه و فرم‌های محتوای اپ را کامل کنید، یک Android App Bundle (.aab) را در یک مسیر آزمایشی بارگذاری کنید، و وقتی گوگل آن را بررسی کرد، برای عموم منتشرش کنید. اگر یک حساب شخصی جدید دارید، یک مرحله اضافه هم هست: یک آزمایش بسته‌شده با دست‌کم ۱۲ آزمونگر برای ۱۴ روز متوالی پیش از آنکه بتوانید دسترسی عمومی بگیرید. این راهنما هر صفحه را به ترتیب طی می‌کند، با جزئیاتی که بیشتر تأخیرها از آن‌ها ناشی می‌شود.

اگر هنوز اپ را نساخته‌اید، از چطور یک اپ اندروید بسازیم شروع کنید.

پیش از شروع: چه چیزهایی لازم دارید

• اپ به‌صورت Android App Bundle (.aab). Google Play برای اپ‌های جدید این فرمت را می‌خواهد.
• سطح API هدف فعلی. از نوامبر ۲۰۲۶، اپ‌های جدید و به‌روزرسانی‌ها باید Android 16 (سطح API ۳۶) را هدف بگیرند.
• سیاست حریم خصوصی در یک آدرس وب عمومی. باید یک صفحه وب عادی باشد، نه PDF، و پشت ورود قرار نداشته باشد.
• آیکون، اسکرین‌شات و تصویر ویژگی (feature graphic). اندازه‌های فعلی را در Play Console بررسی کنید؛ در زمان نوشتن این راهنما، آیکون ۵۱۲ × ۵۱۲ پیکسل و تصویر ویژگی ۱۰۲۴ × ۵۰۰ است.
• یک ایمیل پشتیبانی.
• یک کارت و کارت شناسایی دولتی به نام قانونی خودتان برای ثبت‌نام. کارت‌های پیش‌پرداخت پذیرفته نمی‌شوند.

گام ۱: حساب توسعه‌دهنده را بسازید

به Play Console بروید و ثبت‌نام کنید. بین دو نوع حساب انتخاب می‌کنید:

• شخصی. برای افراد. هویتتان را تأیید می‌کنید و دسترسی به یک دستگاه اندروید را با اپ Play Console روی گوشی ثابت می‌کنید، و الزام آزمایش گام ۶ را انجام می‌دهید.
• سازمانی. برای کسب‌وکارهای ثبت‌شده. تأیید اطلاعات کسب‌وکار را می‌خواهد و زمان بیشتری می‌برد، اما الزام ۱۲ آزمونگر را ندارد.

باید دست‌کم ۱۸ سال داشته باشید. هزینه ۲۵ دلاری یک‌بار پرداخت می‌شود و اگر گوگل اطلاعات شما را نامعتبر بداند بازپرداخت نمی‌شود، پس نام قانونی‌تان را دقیقاً همان‌طور که روی کارت شناسایی‌تان است وارد کنید.

گام ۲: اپ را بسازید

در Play Console روی Create app کلیک کنید و این موارد را پر کنید:

• نام اپ همان‌طور که کاربران می‌بینند.
• زبان پیش‌فرض.
• اپ یا بازی.
• رایگان یا پولی. می‌توانید بعداً یک اپ پولی را رایگان کنید، اما یک اپ رایگان را نمی‌توانید پولی کنید.
• اعلام‌ها: سیاست‌های برنامه توسعه‌دهندگان، قوانین صادرات آمریکا و شرایط Play App Signing را بپذیرید.

نام بسته (مثل com.yourcompany.yourapp) با اولین بارگذاری تعیین می‌شود و هرگز قابل تغییر یا استفاده مجدد نیست، پس اگر خودتان اپ را می‌سازید، با دقت انتخابش کنید.

گام ۳: لیست فروشگاه را بنویسید

صفحه Main store listing (زیر Store presence در منوی سمت چپ) را باز کنید و این موارد را اضافه کنید:

• نام اپ، تا ۳۰ نویسه.
• توضیح کوتاه، تا ۸۰ نویسه. اغلب تنها چیزی است که مردم می‌خوانند، پس با آنچه اپ انجام می‌دهد شروع کنید.
• توضیح کامل، تا ۴٬۰۰۰ نویسه. توضیح دهید اپ برای چه کسی است، ویژگی‌های اصلی و هر آنچه کاربران باید بدانند را به زبان ساده بنویسید. کلمات کلیدی را انباشته نکنید؛ سیاست‌های گوگل این کار را ممنوع کرده‌اند.
• گرافیک‌ها: آیکون، تصویر ویژگی و اسکرین‌شات‌های گوشی. صفحه‌های واقعی اپ، نه ماکت ویژگی‌هایی که وجود ندارند.
• دسته‌بندی و اطلاعات تماس.

گام ۴: فرم‌های محتوای اپ را کامل کنید

صفحه App content (زیر Policy در منوی سمت چپ) را باز کنید. هر مورد پیش از انتشار پاسخ می‌خواهد:

• نشانی سیاست حریم خصوصی.
• دسترسی به اپ. اگر بخشی از اپ ورود می‌خواهد، برای بازبین‌ها اطلاعات ورود کاری بدهید. نبودن ورود یکی از دلایل رایج رد شدن است.
• تبلیغات. بگویید اپ تبلیغ نشان می‌دهد یا نه، از جمله از طریق کد شخص ثالث.
• رده‌بندی محتوا. یک پرسشنامه که رده سنی هر منطقه را تولید می‌کند. اگر آن را رد کنید، اپ «Unrated» می‌شود و انتشار را مسدود می‌کند.
• مخاطب هدف و محتوا. گروه‌های سنی‌ای که اپ برایشان است. اگر کودکان را شامل شود، الزامات سخت‌گیرانه‌تر سیاست Families اعمال می‌شود.
• Data safety. اینکه اپ چه داده‌هایی جمع یا به اشتراک می‌گذارد، چرا، و آیا رمزگذاری شده و قابل حذف است. برای همه چیز داخل اپ پاسخ دهید، از جمله تحلیل و ارائه‌دهندگان ورود.
• اعلام‌های دیگر وقتی درخواست می‌شوند، مثلاً برای اپ‌های خبری، سلامت، مالی یا دولتی، یا برای مجوزهای حساس مثل SMS.

دقیق باشید. گوگل پاسخ‌های شما را با کاری که اپ واقعاً انجام می‌دهد مقایسه می‌کند.

گام ۵: اولین نسخه را در آزمایش داخلی بارگذاری کنید

صفحه Internal testing (زیر Testing در منوی سمت چپ) را باز کنید، یک انتشار بسازید و .aab را بارگذاری کنید. در این اولین انتشار Play App Signing را راه‌اندازی می‌کنید: بگذارید گوگل کلید امضا را بسازد و نگه دارد، مگر دلیل خاصی برای مدیریت خودتان داشته باشید. خودتان و چند همکار را با ایمیل به‌عنوان آزمونگر داخلی اضافه کنید، سپس انتشار را شروع کنید. آزمونگران لینک opt-in را باز می‌کنند و اپ را از Play Store نصب می‌کنند.

هر بارگذاری بعدی باید versionCode بالاتری نسبت به قبلی داشته باشد.

اگر با Mythex می‌سازید

در پلن Pro، Mythex فایل AAB را از روی اپ منتشرشده شما می‌سازد. می‌توانید به دو روش کار کنید:

1. خودتان بارگذاری کنید. از عامل بخواهید برای Android بسازد، وقتی کارت نوشت Ready to upload روی Download کلیک کنید و فایل را در Play Console بارگذاری کنید. فایل تا حدود ۳۰ روز از Project settings قابل دانلود می‌ماند.
2. حساب سرویس Google Play خودتان را وصل کنید. یک حساب سرویس و کلید JSON در Google Cloud بسازید، ایمیلش را در Play Console زیر Users and permissions با دسترسی به این اپ دعوت کنید، و کلید را در Mythex بگذارید. از آن به بعد، هر ساخت Android خودکار به آزمایش داخلی می‌رود، با versionCode بالاتر از هر چیزی که در Google Play است. عامل می‌تواند لیست فروشگاه را هم ویرایش کند، و پیش از هر چیزی که عمومی شود، مثل انتشار در مسیر production، از شما می‌پرسد.

ساختن اپ (گام ۲)، فرم Data safety و رده‌بندی محتوا همچنان در Play Console می‌مانند؛ عامل وقتی یکی از آن‌ها کم باشد به شما می‌گوید. بیشتر را در صفحه سازنده اپ اندروید Mythex ببینید.

گام ۶: یک آزمایش بسته‌شده اجرا کنید (حساب‌های شخصی جدید)

اگر حساب شخصی شما بعد از ۱۳ نوامبر ۲۰۲۳ ساخته شده، باید یک آزمایش بسته‌شده با دست‌کم ۱۲ آزمونگر اجرا کنید که دست‌کم ۱۴ روز متوالی عضو بمانند، پیش از آنکه بتوانید دسترسی عمومی بگیرید. کسی که خارج شود و دوباره بپیوندد، ۱۴ روز را از نو شروع می‌کند.

نکات عملی:

• بیش از ۱۲ نفر را استخدام کنید. افراد کنار می‌کشند. هدف ۱۵ تا ۲۰ نفر است.
• از یک گروه گوگل یا فهرست ایمیل برای مدیریت آزمونگران استفاده کنید.
• استفاده واقعی بخواهید، نه فقط نصب. گوگل وقتی درخواست می‌دهید درباره آزمایشتان می‌پرسد، و بیشتر از این یاد می‌گیرید.
• در طول آزمایش یک به‌روزرسانی بفرستید با اصلاحات بازخوردها.

راهنمای آزمایش بتا جذب آزمونگران و جمع‌آوری بازخورد را پوشش می‌دهد. وقتی ۱۴ روز تمام شد، از Dashboard درخواست دسترسی عمومی کنید و به سؤال‌های مربوط به آزمایشتان پاسخ دهید.

گام ۷: انتشار عمومی

وقتی دسترسی عمومی فعال شد، Production را در منوی سمت چپ باز کنید:

1. کشورها و مناطقی را انتخاب کنید که اپ در آن‌ها در دسترس خواهد بود.
2. یک انتشار جدید بسازید و بسته را از آزمایش اضافه کنید، یا یک بسته جدید بارگذاری کنید.
3. یادداشت‌های انتشار را به زبان ساده بنویسید: چه چیزی جدید است یا اصلاح شده.
4. بررسی کنید و برای بازبینی بفرستید. تغییرات زیر Publishing overview جمع می‌شوند تا ارسالشان کنید.

زمان بررسی متغیر است. به‌روزرسانی‌ها اغلب سریع‌اند؛ نسخه‌های اول ممکن است چند روز طول بکشد. اگر می‌خواهید دقیقاً لحظه عمومی شدن انتشار تأییدشده را خودتان انتخاب کنید، managed publishing را انتخاب کنید.

گام ۸: بعد از راه‌اندازی

• Android vitals را برای کرش‌ها و گزارش‌های «app not responding» زیر نظر داشته باشید.
• به نظرات کاربران پاسخ دهید، به‌ویژه نظرات اولیه.
• سطح API هدف را به‌روز نگه دارید. گوگل هر سال آن را بالا می‌برد، و اپ‌هایی که عقب بمانند دیگر به کاربران گوشی‌های جدیدتر پیشنهاد نمی‌شوند.
• فرم Data safety را به‌روز کنید هر بار که جمع‌آوری داده جدیدی اضافه می‌کنید.

برای اپ وب‌پیچ‌شده‌ای مثل اپی که با Mythex ساخته شده، بیشتر تغییرات وقتی به کاربران اندروید می‌رسند که اپ وب را منتشر کنید، چون اپ گوشی، اپ منتشرشده شما را باز می‌کند. یک انتشار جدید در فروشگاه فقط برای چیزهایی مثل آیکون، نام، مجوزها یا یک سطح هدف جدید لازم است.

دلایل رایج رد شدن یا تأخیر

• نبودن ورود کاری برای بازبین‌ها.
• سیاست حریم خصوصی که وجود ندارد، یک PDF است، یا با پاسخ‌های Data safety همخوانی ندارد.
• اسکرین‌شات‌ها یا توضیحاتی که ویژگی‌هایی را وعده می‌دهند که اپ ندارد.
• درخواست مجوزهای حساس که اپ به‌وضوح به آن‌ها نیاز ندارد.
• اپ خراب یا خالی: متن جای‌نگهدار، دکمه‌های بی‌عملکرد.

آیا در iPhone هم منتشر می‌کنید؟

فرایند اپل متفاوت است: عضویت سالانه، TestFlight، و بررسی انسانی هر انتشار. برای آن مراحل، چطور اپ را در App Store منتشر کنیم را بخوانید.

پرسش‌ها