راهنماهای این موضوع انتشار را مثلِ فشار دادنِ یک دکمه توصیف می‌کنند: فایل را بفرست، منتشر می‌شود. در عمل یک حلقه است — ارسال، بازبینی، رد یا تأیید، اصلاح، ارسالِ مجدد — و رد شدن در بارِ اول قاعده است، نه استثنا.

پس مفیدترین کاری که این راهنما می‌تواند بکند این است: به شما بگوید پیش از ارسال چه چیزهایی معمولاً باعثِ رد می‌شوند، و کدام تصمیم‌ها را باید قبل از شروعِ ساخت گرفته باشید.

مطالبی که در ادامه می خوانید:

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

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

این جدول ارزشِ اصلیِ راهنماست. این‌ها مواردِ شایع در تجربه‌ی انتشار هستند — سیاست‌های دقیق و روزِ هر بازار را از خودِ پنلِ توسعه‌دهنده بخوانید، چون تغییر می‌کنند:

علتِ شایعِ ردچرا رخ می‌دهدکارِ درست
سیاستِ حریمِ خصوصی نیست یا لینکش باز نمی‌شودآدرس را در فرم می‌نویسند بدونِ اینکه صفحه‌اش واقعاً منتشر شده باشدیک صفحه‌ی زنده و قابلِ دسترسِ عمومی که چهار سؤالِ اصلی را جواب دهد — صفحه‌ی حریمِ خصوصی که واقعاً چیزی می‌گوید
درخواستِ دسترسیِ بی‌دلیل (مخاطبین، موقعیت، پیامک)کتابخانه‌ها و قالب‌های آماده دسترسی‌هایی را اضافه می‌کنند که اپ استفاده‌شان نمی‌کندهر دسترسی باید یک کاربردِ قابلِ توضیح داشته باشد. فهرستِ دسترسی‌ها را قبل از ارسال یک‌به‌یک مرور و بی‌استفاده‌ها را حذف کنید
اپ بدونِ ثبت‌نام هیچ چیزی نشان نمی‌دهدبازبین نمی‌تواند چیزی را که نمی‌بیند تأیید کندیک حسابِ آزمایشی با نام و رمز در توضیحاتِ ارسال بگذارید — نکته‌ای که کمتر کسی می‌داند و به‌تنهایی یک چرخه‌ی رد را حذف می‌کند
اسکرین‌شات با اپ نمی‌خواندتصاویرِ تزئینی یا ساختگی جای نمای واقعیِ اپ گذاشته می‌شودتصاویر باید از خودِ اپ باشند؛ متنِ توضیحیِ رویشان مجاز است ولی صفحه‌ها باید واقعی باشند
کرش در اولین اجرانسخه‌ی ارسالی روی دستگاهِ خالی و بدونِ دادهِ قبلی تست نشدهنصبِ تازه روی یک دستگاهِ دیگر و اجرای اولین‌بار را آزمون کنید، نه روی گوشیِ توسعه‌دهنده
نام یا نشانِ برندی که مالکش نیستیداستفاده از نامِ برندهای دیگر در عنوان یا آیکون برای دیده‌شدنفقط نامِ خودتان. این مورد معمولاً بدونِ فرصتِ اصلاح رد می‌شود
توضیحاتِ پرشده از کلمه‌ی کلیدیتصورِ اینکه تکرارِ عبارت رتبه می‌آوردتوضیحِ خوانا برای آدم بنویسید؛ تکرارِ مصنوعی هم رد می‌آورد و هم نرخِ نصب را پایین می‌برد
نکته

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

این بند را بیشترِ کسب‌وکارها روزِ انتشار کشف می‌کنند و آن‌وقت دیر است: حسابِ توسعه‌دهنده‌ی بازار باید به نامِ خودِ کسب‌وکار باشد، نه به نامِ آژانسِ سازنده.

اگر حساب مالِ آژانس باشد، اپ در عمل مالِ شما نیست — نمی‌توانید به‌روزرسانی منتشر کنید، نمی‌توانید توضیحات و تصاویر را عوض کنید، و انتقالِ اپ به حسابِ دیگر فرایندِ ساده‌ای نیست. این دقیقاً همان قاعده‌ای است که برای مالکیتِ دامنه صادق است: دارایی باید به نامِ صاحبِ کسب‌وکار ثبت شود، حتی اگر کارِ فنی را کسِ دیگری انجام دهد.

پس در همان جلسه‌ی اولِ پروژه سه چیز را روشن کنید: حساب به نامِ کی ثبت می‌شود، مدارکِ احراز هویت و کسب‌وکار چه کسی را لازم دارد، و دسترسیِ پنل بعد از تحویل دستِ کی می‌ماند.

«کلمه‌ی کلیدی بگذارید» توصیه‌ی مبهمی است. در عمل سه فیلد بیشترین اثر را دارند:

و درباره‌ی زمانِ درخواستِ نظر — که تقریباً همه‌جا غلط انجام می‌شود: بعد از یک تجربه‌ی موفق بپرسید، نه در اولین اجرا. برای اپِ فروشگاهی یعنی بعد از تحویلِ سفارش، نه لحظه‌ای که کاربر تازه وارد شده و هنوز چیزی ندیده. درخواستِ زودهنگام هم نظرِ کم می‌آورد و هم نظرِ بد.

در راهنمای عکس و توضیح محصول نوشتیم هرگز قیمت و تخفیف را روی عکسِ محصول ننویسید. اینجا خلافش را می‌گوییم و دلیلش آموزنده است: کارکردِ این دو تصویر فرق دارد.

عکسِ محصولِ فروشگاه باید توسطِ رباتِ موتورهای مقایسه‌ی قیمت خوانده شود و اطلاعاتش (قیمت، موجودی) مرتب عوض می‌شود — پس متنِ روی تصویر هم ناخوانا است و هم به‌سرعت کهنه. اسکرین‌شاتِ استور اما یک تصویرِ تبلیغاتی است: چیزی از آن استخراج نمی‌شود و محتوایش هم ثابت است. قاعده‌ی مشترکِ هر دو یکی است — اطلاعاتِ متغیر روی تصویر نرود — و همان قاعده در دو موقعیت به دو نتیجه‌ی متفاوت می‌رسد.

در برآوردِ اولیه‌ی پروژه‌ها این دو مورد تقریباً همیشه جا می‌افتند:

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

دو — و مهم‌ترش: کاربر باید به‌روزرسانی را نصب کند. بخشی از کاربران ماه‌ها نسخه‌ی قدیمی را نگه می‌دارند. پیامدِ مهندسی‌اش این است که API سمتِ سرورِ شما باید با نسخه‌های قدیمیِ اپ سازگار بماند — نمی‌توانید یک فیلد را حذف کنید و فرض کنید همه به‌روز شده‌اند. این بندِ کوچک همان چیزی است که هزینه‌ی نگه‌داریِ اپ را از سایت بیشتر می‌کند، و در اندروید، iOS یا PWA از منظرِ انتخابِ پلتفرم و در هزینه‌ی ساخت اپلیکیشن از منظرِ برآورد بررسی شده.

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

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

سه چیز را ببرید. اول: انتشار یک حلقه است نه یک رویداد؛ تاریخِ اعلامِ عمومی را به تأیید گره بزنید نه به ارسال، و یک چرخه‌ی بازبینی فاصله بگذارید. دوم: بیشترِ ردها از چند موردِ تکراری می‌آید و ارزان‌ترینشان قابلِ پیشگیری است — لینکِ زنده‌ی حریمِ خصوصی، حذفِ دسترسیِ بی‌دلیل، و گذاشتنِ حسابِ آزمایشی برای بازبین. سوم: حسابِ توسعه‌دهنده را به نامِ خودتان ثبت کنید، دقیقاً به همان دلیلی که دامنه باید به نامِ خودتان باشد.

در ادزو انتشار و پیگیریِ بازبینی بخشی از خدمت است؛ جزئیاتش در صفحه‌ی طراحی اپلیکیشن موبایل.

بگویید اپتان چه دسترسی‌هایی می‌خواهد و ثبت‌نام اجباری دارد یا نه — می‌گوییم کدام موردش احتمالاً باعث رد می‌شود.برآورد هزینه و زمان را در یک تماس کوتاه می‌گیرید.