انتشار اپ در گوگل پلی و اپ استور؛ پیش‌نیاز، ریجکت و نگهداری

اگر می‌پرسید انتشار اپ در گوگل پلی از کجا شروع می‌شود، پاسخ فقط آپلود یک فایل نیست. باید حساب توسعه‌دهنده، هویت، صفحهٔ محصول، حریم خصوصی، طبقه‌بندی محتوا، تست مسیرهای حیاتی و برنامهٔ به‌روزرسانی آماده باشد. App Store اپل هم همین منطق را دارد، با سیاست‌ها و زمان بررسی متفاوت. تیمی که ساخت اپ را تمام‌شده می‌داند و استور را «یک بعدازظهر» می‌بیند، معمولاً با ریجکت، نقص مدارک یا صفحهٔ ناقص متوقف می‌شود.

جست‌وجوهایی مانند «انتشار اپ در گوگل پلی»، «انتشار در اپ استور»، «دلیل ریجکت گوگل پلی»، «حساب توسعه‌دهنده» و «به‌روزرسانی بعد از لانچ» نشان می‌دهند مسئله عملیاتی است. در این راهنما پیش‌نیازها، مسیر Play Console و App Store Connect، علت‌های رایج رد شدن، نگهداری بعد از انتشار و محدودیت‌های واقعی دسترسی به استورهای جهانی را بررسی می‌کنیم. این متن مشاورهٔ حقوقی یا دورزدن سیاست پلتفرم نیست. مسیر ساخت محصول در خدمات طراحی اپلیکیشن روبینش و انتخاب فریم‌ورک در مقایسه فلاتر و ری‌اکت نیتیو آمده است.

“You must verify your developer account before you can submit apps for consideration on Google Play.”

انتشار اپ در گوگل پلی چه پیش‌نیازهایی دارد؟

Google Play از طریق Play Console مدیریت می‌شود. برای ارسال اپ معمولاً به حساب Google، حساب توسعه‌دهنده، پروفایل پرداخت متصل، تکمیل احراز هویت طبق سیاست جاری، و بستهٔ انتشار با فرمت مورد قبول — اغلب Android App Bundle — نیاز دارید. علاوه بر فایل، سیاست حریم خصوصی، فرم Data safety، دسته‌بندی، مخاطب هدف، اسکرین‌شات، توضیح کوتاه و بلند و اطلاعات تماس باید کامل باشد. اگر هویت یا مدارک با پروفایل پرداخت هم‌خوان نباشد، بررسی ممکن است متوقف شود.

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

صفحهٔ محصول گوگل پلی را چطور آماده کنیم؟

کاربر استور قبل از نصب فقط چند ثانیه به عنوان، آیکون، اسکرین‌شات و توضیح نگاه می‌کند. عنوان باید کار اپ را بگوید، نه شعار مبهم. اسکرین‌شات مسیر واقعی را نشان دهد، نه موکاپ تزئینی که با بیلد فرق دارد. توضیح کوتاه ارزش اصلی را می‌گوید و توضیح بلند ویژگی، مخاطب و محدودیت را شفاف می‌کند. لینک حریم خصوصی باید از مرورگر باز شود و با رفتار واقعی اپ یکی باشد.

• آیکون خوانا در اندازهٔ کوچک
• اسکرین‌شات گوشی و در صورت نیاز تبلت، مطابق نسخهٔ فعلی
• ویدیوی کوتاه فقط اگر محصول را درست نشان می‌دهد
• دسته‌بندی و تگ نزدیک به کاربرد واقعی
• ایمیل پشتیبانی که تیم واقعاً می‌خواند
• فرم Data safety هم‌خوان با SDKهای تحلیلی و تبلیغاتی

ناهماهنگی بین ادعا و محصول از علت‌های ریجکت و حذف بعدی است. اگر اپ «پرداخت درون‌برنامه‌ای» ندارد، در متن ادعایش نکنید. اگر به موقعیت مکانی نیاز ندارید، مجوز را بردارید. بازبین انسان و سیستم خودکار هر دو به مجوزهای اضافی و رفتار مشکوک حساس‌اند.

انتشار در اپ استور اپل چه فرقی دارد؟

App Store از حساب Apple Developer، برنامهٔ سالانه، گواهی امضا، App Store Connect و اغلب TestFlight برای آزمون داخلی استفاده می‌کند. بررسی اپل معمولاً روی کیفیت رابط، استفاده از قابلیت‌های سیستم، حساب آزمایشی برای ورود، و رعایت Guideline دقیق‌تر است. اگر اپ ورود دارد، حساب تست و توضیح مسیر را در یادداشت بازبین بگذارید. بدون آن، ریجکت «نتوانستیم وارد شویم» رایج است.

سیاست پرداخت درون‌برنامه‌ای، محتوای کاربر، سلامت و کودک در اپل سخت‌گیرانه است. اگر وب‌ویو فقط سایت را داخل اپ نشان دهد بدون ارزش موبایلی، احتمال رد وجود دارد. نام، اسکرین‌شات و عملکرد باید با باینری یکی باشند. زمان بررسی متغیر است؛ برنامهٔ لانچ را به «همان روز آپلود» گره نزنید. مستندات رسمی را در App Store Review Guidelines دنبال کنید.

دلیل ریجکت رایج چیست؟

رد شدن لزوماً به معنی محصول بد نیست؛ یعنی یک الزام بررسی برآورده نشده. در گوگل پلی ناقص بودن هویت، Data safety، سیاست حریم خصوصی، کرش در دستگاه تست، بدافزار یا رفتار گمراه‌کننده رایج است. در اپل، ورود بدون حساب تست، رابط ناقص، استفادهٔ نادرست از API، کپی بودن، و محتوای ذخیره‌نشده زیاد دیده می‌شود. پاسخ ریجکت را دقیق بخوانید، همان مورد را اصلاح کنید و در توضیحات ارسال بعد توضیح دهید چه عوض شده است.

1. کرش یا بن‌بست در مسیر اصلی: نصب، ورود، خرید، ثبت سفارش
2. مجوزهایی که در محصول استفاده نمی‌شوند
3. لینک حریم خصوصی خراب یا متنی که با SDKها نمی‌خواند
4. اسکرین‌شات یا عنوان گمراه‌کننده
5. محتوای ناقص، placeholder و دکمهٔ بدون عمل
6. نبود حساب تست برای بازبین
7. نسخه‌ای که روی معماری یا نسخهٔ سیستم اعلام‌شده اجرا نمی‌شود

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

یادداشت بازبین را مثل راهنمای نصب برای غریبه بنویسید: از کجا وارد شود، با چه حسابی، کدام دکمه مسیر اصلی است، و اگر پرداخت دارد آیا حالت آزمایشی وجود دارد. فرض نکنید بازبین محصول شما را می‌شناسد. اگر اپ چند نقش دارد — مشتری و فروشنده — مشخص کنید کدام نقش باید بررسی شود. مسیر پنهان‌شده پشت پرچم آزمایشی را برای بیلد استور روشن کنید؛ بازبین به نسخهٔ خالی «به‌زودی» حساس است.

حساب توسعه‌دهنده را چطور ببینیم؟

حساب، دارایی کسب‌وکار است نه ابزار شخصی یک برنامه‌نویس. مشخص کنید مالک حقوقی کیست، دسترسی‌ها با نقش جدا می‌شود، و با خروج فرد دسترسی قطع می‌شود. بازیابی حساب قفل‌شده گاهی از ساخت اپ جدید سخت‌تر است. رمز، تأیید دو مرحله‌ای و ایمیل بازیابی را مستند کنید. برای سازمان، حساب سازمانی معمولاً از حساب شخصی پایدارتر است چون وابستگی به یک فرد کمتر می‌شود.

هزینهٔ ثبت حساب را با هزینهٔ نگهداری اشتباه نگیرید. اپل معمولاً حق عضویت سالانه دارد؛ گوگل مدل متفاوتی برای ثبت دارد و جزئیات را در کنسول رسمی ببینید. هیچ عدد ثابتی را به‌عنوان تعرفهٔ همیشگی در قرارداد مشتری ننویسید مگر منبع رسمی همان روز را چک کرده باشید. اگر چند اپ دارید، سیاست نام توسعه‌دهنده، برند و انتقال مالکیت را از اول روشن کنید.

به‌روزرسانی بعد از لانچ

لانچ پایان کار نیست. کرش، نسخهٔ سیستم‌عامل جدید، تغییر سیاست استور و وابستگی کتابخانه‌ها نیاز به انتشار منظم دارند. برای هر نسخه یادداشت تغییرات، شمارهٔ نسخه و سازگاری را ثبت کنید. اگر پرداخت یا ورود را عوض می‌کنید، مرحله‌ای منتشر کنید و گزارش کرش را همان هفته ببینید. حذف ناگهانی API یا مجوز بدون توضیح، هم کاربر و هم بررسی بعدی را خراب می‌کند.

پشتیبانی استور بخشی از محصول است. ایمیل پشتیبانی را به پوشهٔ مرده نفرستید. امتیاز پایین بدون پاسخ، نصب را کم می‌کند. به بازخوردهای تکراری در نسخهٔ بعد رسیدگی کنید و در پاسخ فروشگاه مودب و مشخص باشید. اگر اپ را موقتاً از دسترس خارج می‌کنید، دلیل و مسیر بازگشت را به تیم پشتیبانی بگویید تا کاربر سردرگم نشود.

مسیر تست داخلی، انتشار مرحله‌ای و نسخه‌گذاری

ارسال مستقیم بیلد به همهٔ کاربران اولین اشتباه عملیاتی است. در Play Console معمولاً مسیرهای داخلی، بسته و تولید وجود دارد؛ در اپل، TestFlight نقش آزمون را پر می‌کند. اول بیلد را به تیم خودتان بدهید، بعد به گروه کوچک‌تر واقعی، و فقط وقتی کرش و مسیر خرید پایدار شد به تولید بروید. انتشار مرحله‌ای یعنی درصد کمی از کاربران نسخهٔ جدید را می‌گیرند تا اگر کرش بالا رفت، عقب‌گرد ممکن باشد.

شمارهٔ نسخه را جدی بگیرید. کاربر و پشتیبانی باید بتوانند بگویند کدام بیلد روی دستگاه است. یادداشت تغییرات را برای انسان بنویسید، نه فهرست فنی داخلی. اگر مجوز تازه، SDK تحلیلی یا رفتار ورود عوض شده، در توضیحات ارسال به بازبین بنویسید تا همان تغییر دوباره سؤال نشود. وابستگی کتابخانه‌ها را قفل کنید؛ به‌روزرسانی خاموش یک کتابخانهٔ پرداخت می‌تواند بیلد استور را بشکند در حالی که روی میز کار هنوز کار می‌کند.

گزارش کرش را در هفتهٔ اول لانچ هر روز ببینید، نه ماه بعد. دستگاه‌های ضعیف، نسخهٔ قدیمی سیستم‌عامل و قطعی شبکه را در آزمون پوشش دهید. اگر فقط روی یک پرچمدار تست کرده‌اید، ریجکت یا امتیاز پایین از دستگاه واقعی دور نیست. یک مسئول انتشار مشخص کنید تا دو نفر هم‌زمان دو بیلد روی همان مسیر تولید نفرستند.

اگر گوگل پلی یا اپ استور در دسترس نباشد

برای برخی کسب‌وکارها و مناطق، ساخت حساب یا احراز هویت استورهای جهانی محدود یا غیرممکن است. این محدودیت را با «ترفند حساب خارجی» حل نکنید. گزینه‌های قانونی معمولاً شامل فروشگاه‌های داخلی مانند کافه‌بازار و مایکت، توزیع سازمانی برای کارکنان، یا وب‌اپ/PWA است. هر کانال سیاست، کمیسیون و روند بررسی خودش را دارد. انتخاب کانال را در کشف محصول ببینید، نه بعد از اتمام کدنویسی.

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

فروشگاه داخلی هم بررسی، صفحهٔ محصول، امضا و به‌روزرسانی دارد. فرض نکنید کافه‌بازار یا مایکت «بدون سیاست» است. کمیسیون، روش پرداخت، محتوای مجاز و زمان بررسی را از پنل همان فروشگاه بخوانید. اگر هم استور جهانی و هم داخلی می‌خواهید، یک کدبیس با پیکربندی جدا بهتر از دو محصول کاملاً منشعب است، اما شناسهٔ بسته، کلید امضا و صفحهٔ محصول را قاطی نکنید. توزیع سازمانی برای کارکنان معمولاً حساب استور عمومی نمی‌خواهد، ولی نصب، به‌روزرسانی و جمع‌آوری دستگاه را باید خودتان مدیریت کنید.

حریم خصوصی و متن صفحهٔ محصول را از روی قالب آماده برندارید

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

متن استور را مثل متن تبلیغ ننویسید. ادعای «بهترین»، «شماره یک» و اسکرین‌شات ویرایش‌شده که دکمهٔ واقعی ندارد، ریسک گمراه‌کنندگی دارد. کلمات کلیدی را در عنوان و توضیح کوتاه طبیعی بگذارید، نه تکرار ماشینی. اگر اپ به فروشگاه وب وصل است، مسیر خرید را در اسکرین‌شات نشان دهید؛ همگام‌سازی سبد و موجودی را در اتصال اپ به فروشگاه اینترنتی ببینید تا صفحهٔ استور با محصول یکی باشد.

چک‌لیست ارسال به استور

1. مالک حساب، دسترسی‌ها و بازیابی مشخص است.
2. هویت و مدارک طبق کنسول رسمی کامل شده، بدون دورزدن سیاست.
3. بیلد امضاشده روی دستگاه واقعی نصب و مسیر اصلی تست شده است.
4. حریم خصوصی، مجوزها و Data safety با SDKهای واقعی یکی است.
5. اسکرین‌شات، عنوان و توضیح با نسخهٔ فعلی می‌خوانند.
6. حساب تست و یادداشت بازبین آماده است.
7. برنامهٔ نسخهٔ بعد، مانیتور کرش و پاسخ به نظرها وجود دارد.
8. اگر استور جهانی در دسترس نیست، کانال جایگزین قانونی انتخاب شده است.

اشتباهات رایج در انتشار اپ

• گذاشتن استور برای آخرین روز قبل از کمپین تبلیغاتی
• ارسال بیلد با کرش مسیر ورود یا پرداخت
• کپی سیاست حریم خصوصی بی‌ارتباط با محصول
• وابسته‌کردن کل کسب‌وکار به یک حساب شخصی بدون مالک مشخص
• تلاش برای دورزدن احراز هویت یا خرید حساب آماده
• نادیده‌گرفتن فروشگاه‌ها و محدودیت منطقه‌ای تا لحظهٔ آپلود
• نبود فرایند به‌روزرسانی بعد از اولین انتشار
• اسکرین‌شات طراحی‌شده که با اپ واقعی فرق دارد

جمع‌بندی: استور بخشی از محصول است

انتشار اپ در گوگل پلی و اپ استور یعنی آماده بودن هویت، بیلد پایدار، صفحهٔ صادقانه، حریم خصوصی و ظرفیت نگهداری. ریجکت معمولاً قابل اصلاح است اگر همان علت را ببندید. محدودیت دسترسی به استورهای جهانی را با روش غیررسمی حل نکنید؛ کانال قانونی و مخاطب واقعی را از ابتدا انتخاب کنید.

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