طراحی اپ اندروید اختصاصی با سورس و کلید امضا به نام خودتان

اپلیکیشن‌ساز آماده یا طراحی اپ اندروید اختصاصی؟

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

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

جدول زیر همان سؤال‌هاست، به‌همراه دلیل اهمیت هرکدام. اگر پاسخ سازندهٔ فعلی‌تان به سه ردیف اول «نمی‌دانم» یا «لازم نیست نگرانش باشید» بود، همان‌جا بایستید و تا گرفتن پاسخ روشن جلو نروید.

کلید امضای اپ اندروید دست کیست؟ (مهم‌ترین سؤالی که کسی نمی‌پرسد)

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

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

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

• کلید امضا را در جایی امن نگه دارید و نسخهٔ پشتیبان آن را جدا از سرور پروژه ذخیره کنید — گم‌شدن کلید، برگشت‌ناپذیر است
• رمز کلید (keystore password) بخشی از دارایی است؛ کلید بدون رمز به‌اندازهٔ نداشتن کلید بی‌فایده است
• حساب توسعه‌دهندهٔ مارکت را با ایمیل سازمانی خودتان بسازید، نه با ایمیل شخصی یک کارمند یا پیمانکار
• اگر مارکت یا سرویسی «امضا را ما انجام می‌دهیم» گفت، بپرسید آیا نسخه‌ای از کلید به شما تحویل داده می‌شود یا خیر
• پیش از انتشار نسخهٔ اول، سیاست کلید را در قرارداد بنویسید — بعد از انتشار، تغییر آن هزینهٔ کاربر دارد
• برای اپ‌های منتشرشده در Google Play، سازوکار Play App Signing کلید نهایی را نزد گوگل نگه می‌دارد و کلید آپلود دست شماست؛ تفاوت این دو را پیش از انتشار بدانید

هزینه ساخت اپلیکیشن اندروید به چه چیزهایی بستگی دارد؟

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

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

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

• گسترهٔ کارکردها: پرنوسان‌ترین عامل و بزرگ‌ترین سهم در رقم پایانی
• ژرفای اتصال‌ها: هر پیوند با انبار، نرم‌افزار مالی یا باشگاه مشتریان، پیمانی فنی با سناریوهای خطای مخصوص خودش است
• سنگینی سمت سرور: بدون API و پنل، برنامه چیزی برای نمایش‌دادن ندارد
• وسعت آزمون: چند اندازهٔ نمایشگر و چند نسخهٔ اندروید قرار است پوشش داده شود
• بستر اجرا: سرور، پایگاه داده، گواهی امنیتی، سامانهٔ ارسال اعلان و فضای ذخیرهٔ رسانه
• پشتیبانی ماهانه: از ۱۰ میلیون تومان، با کمینهٔ تعهد شش‌ماهه

انتشار اپ اندروید در کافه‌بازار، مایکت و گوگل‌پلی چه شرایطی دارد؟

برای اکثر کسب‌وکارهای ایرانی، مسیر عملی انتشار اپ اندروید کافه‌بازار و مایکت است، نه گوگل‌پلی. مارکت‌های داخلی ورود ساده‌تر و سریع‌تری دارند: انتشار اپ رایگان است و حساب توسعه‌دهنده هزینهٔ سالانهٔ ناچیزی دارد که در منابع رسمی حدود ۴۰٬۰۰۰ تومان اعلام شده است. گوگل‌پلی اما مسئلهٔ هزینه نیست؛ مسئلهٔ احراز هویت است و این تفاوت را باید پیش از قرارداد بدانید، نه بعد از تحویل اپ.

گوگل برای حساب توسعه‌دهنده، هویت و آدرس تأییدشدهٔ خارج از ایران و حساب بانکی وریفای‌شده می‌خواهد؛ به‌دلیل تحریم، ثبت مستقیم از ایران ممکن نیست و هزینهٔ ثبت‌نام ۲۵ دلاری هم بی‌معنا می‌شود وقتی مرحلهٔ پیش از آن قابل عبور نباشد. گزارش‌های داخلی نشان می‌دهند این محدودیت‌ها در سال‌های اخیر سفت‌تر هم شده است. اگر می‌خواهید جزئیات این مسیر و پیش‌نیازهایش را کامل بخوانید، راهنمای اختصاصی ما را در وبلاگ برتینا ببینید: انتشار برنامه در گوگل پلی استور.

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

• دسترسی‌هایی که برنامه از کاربر می‌خواهد باید دقیقاً با کارکردش بخواند؛ درخواست زیادی، از رایج‌ترین علت‌های پذیرفته‌نشدن است
• متن سیاست حریم خصوصی روی دامنهٔ خودتان منتشر و از درون برنامه در دسترس باشد
• نماد، تصاویر و توضیح صفحهٔ فروشگاه، ورودی جست‌وجوی درون همان فروشگاه‌اند — بهینه‌سازی این بخش را جدی بگیرید
• برنامه‌های دارای تراکنش مالی معمولاً مدارک و بازبینی بیشتری می‌طلبند
• گوگل‌پلی برای برنامه‌های تازه قالب AAB می‌خواهد؛ فروشگاه‌های داخلی فایل APK امضاشده را می‌پذیرند
• نمرهٔ کاربران و پاسخ‌دادن به نقدها روی رتبهٔ برنامه در جست‌وجوی فروشگاه اثر می‌گذارد و باید کسی مسئولش باشد

Native با Kotlin یا چندسکویی با Flutter و React Native؟

اگر فقط اندروید هدف شماست و اپ به سخت‌افزار دستگاه یا پردازش سنگین وابسته است، Kotlin انتخاب درست‌تری است؛ اگر قرار است نسخهٔ iOS هم داشته باشید و اپ از جنس اپ‌های کسب‌وکاری است، کدپایهٔ مشترک صرفهٔ روشنی دارد. این کل ماجراست، و بقیه جزئیات است. Kotlin زبان رسمی توسعهٔ اندروید است و بیشترین کنترل را روی عملکرد، مصرف باتری، رفتار پس‌زمینه و قابلیت‌های تازهٔ سیستم‌عامل می‌دهد. Flutter و React Native از یک کدپایه، نسخهٔ هر دو سکو را بیرون می‌دهند و برای بیشتر برنامه‌های فروشگاهی، خدماتی و رزروی کاملاً کافی‌اند.

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

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

تنوع دستگاه‌های اندروید: اپ روی چه چیزی تست می‌شود؟

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

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

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

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

حجم اپ، مصرف باتری و عملکرد؛ سه دلیل خاموش حذف‌شدن اپ

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

حجم بستهٔ نصبی روی گوشی‌ای که حافظه‌اش پر است، مستقیماً روی تصمیم نصب اثر می‌گذارد. ابزارهای استاندارد اندروید برای این کار وجود دارند: کوچک‌سازی و حذف کد بلااستفاده هنگام ساخت، فشرده‌سازی و انتخاب فرمت درست تصاویر، و استفاده از فرمت App Bundle که به‌جای یک بستهٔ همه‌کاره، فقط منابع متناسب با همان دستگاه را به کاربر می‌رساند. اینکه اپ در اولین اجرا چقدر طول می‌کشد تا صفحهٔ اول را نشان دهد نیز عدد قابل اندازه‌گیری است و باید هدف‌گذاری شود.

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

• کوچک‌سازی کد و حذف کلاس‌ها و منابع بلااستفاده در زمان ساخت بستهٔ نهایی
• بهینه‌سازی تصاویر و انتخاب فرمت مناسب — سنگین‌ترین بخش اغلب اپ‌ها همین است
• استفاده از App Bundle تا کاربر فقط منابع دستگاه خودش را دانلود کند
• زمان‌بندی کارهای پس‌زمینه با سازوکارهای رسمی اندروید، نه سرویس دائماً بیدار
• کش محلی داده تا اپ در شبکهٔ ضعیف هم پاسخ‌گو بماند
• هدف‌گذاری زمان باز شدن صفحهٔ اول و اندازه‌گیری آن روی دستگاه میان‌رده

Push Notification: چطور کاربر را برگردانیم بدون اینکه اپ حذف شود؟

اعلان، تنها کانالی است که بدون هزینهٔ تبلیغات، کاربر را به اپ برمی‌گرداند — و تنها کانالی است که با یک اشتباه، اپ را برای همیشه از گوشی حذف می‌کند. مرز میان این دو، یک کلمه است: ارتباط. اعلانی که به وضعیت واقعی همان کاربر ربط دارد («سفارش شما ارسال شد»، «نوبت شما فردا ساعت ۱۰ است»، «کالای موردنظرتان موجود شد») باز می‌شود. اعلان همگانی که برای همه ارسال می‌شود و به هیچ‌کس ربط ندارد، ابتدا خاموش می‌شود و بعد کل اپ پاک می‌شود.

از نظر فنی، ارسال اعلان روی اندروید نیازمند یک سرویس واسط است که پیام را به دستگاه می‌رساند؛ استاندارد رایج پلتفرم، سرویس اعلان گوگل (FCM) است. در ایران، پایداری دسترسی به سرویس‌های گوگل همیشه قابل اتکا نیست و به همین دلیل انتخاب سرویس اعلان — و اینکه آیا از سرویس‌های داخلی به‌عنوان جایگزین یا مکمل استفاده شود — بخشی از نیازسنجی است و در پروپوزال با دلیل نوشته می‌شود. هر کسی که پیش از دیدن پروژه بگوید «حتماً از فلان سرویس استفاده می‌کنیم»، هنوز نیازسنجی نکرده است.

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

• اعلان تراکنشی: تأیید سفارش، تغییر وضعیت ارسال، یادآوری نوبت — بالاترین نرخ باز شدن را دارند
• اعلان رفتاری: سبد رهاشده، بازگشت به محصول دیده‌شده، موجود شدن کالای موردنظر
• Deep Link: اعلان باید کاربر را دقیقاً به همان صفحهٔ داخل اپ ببرد، نه به صفحهٔ اول
• زمان‌بندی و سقف ارسال: تعیین حداکثر تعداد اعلان در هفته، بخشی از طراحی است نه سلیقهٔ لحظه‌ای
• کنترل در دست کاربر: امکان خاموش‌کردن دسته‌ای از اعلان‌ها، از حذف کامل اپ جلوگیری می‌کند
• اندازه‌گیری: نرخ باز شدن هر دستهٔ اعلان باید ثبت شود تا تصمیم بعدی بر پایهٔ داده گرفته شود

اتصال اپ اندروید به سایت، انبار و درگاه پرداخت

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

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

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

• اتصال به انبار: موجودی و قیمت لحظه‌ای، بدون ورود دستی دوباره
• اتصال به حسابداری: ثبت خودکار سفارش و صدور فاکتور
• اتصال به CRM: تاریخچهٔ کاربر در اپ و سایت، در یک پرونده
• درگاه پرداخت مستقیم به نام کسب‌وکار شما، یا پرداخت درون‌برنامه‌ای مارکت — بسته به نوع کالا و قوانین مارکت
• پنل مدیریت مشترک: یک نقطه برای مدیریت محصول، سفارش، کاربر و محتوا
• مستندسازی API: تا تیم بعدی — هرکسی که باشد — بتواند کار را ادامه دهد

نگهداری اپ اندروید: چرا اپ رهاشده از کار می‌افتد؟

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

به همین سبب، پشتیبانی نزد ما یک سرویس مکتوب و قیمت‌خورده است: از ۱۰ میلیون تومان در ماه با کمینهٔ تعهد شش‌ماهه، شامل هم‌گام‌کردن برنامه با نسخه‌های تازهٔ سیستم‌عامل، هم‌سازی با قواعد نوشدهٔ فروشگاه‌ها، برطرف‌کردن ایرادهای گزارش‌شده، نو کردن کتابخانه‌ها و نشاندن وصله‌های امنیتی. اگر سمت سرور برنامه روی بستر خودِ برتینا اجرا شود، دیده‌بانی سرور و پشتیبانی تلفنی ۲۴/۷ هم در همان بسته می‌نشیند و برای یک اختلال نیمه‌شب لازم نیست میان دو شرکت پیام‌رسانی کنید و منتظر بمانید هرکدام گناه را گردن دیگری بیندازد.

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

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

در پایان پروژه چه چیزی تحویل می‌گیرید؟

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

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

برای بررسی ایدهٔ برنامهٔ اندروید یا کوچ از اپلیکیشن‌ساز کنونی، فرم برآورد را پر کنید یا با شمارهٔ ۰۲۱۴۹۱۳۵ تماس بگیرید. برتینا بیش از ۲۰ سال در زمینهٔ زیرساخت و خدمات وب کار کرده و بیش از ۱۰۰٬۰۰۰ مشتری را همراهی کرده است؛ همان بستر — سرور، دامنه، گواهی امنیتی و پشتیبانی ۲۴/۷ با آپ‌تایم ۹۹.۹٪ — پشت برنامهٔ اندروید شما هم می‌ایستد. همهٔ ارقام «شروع از» هستند و رقم پایانی، پس از نیازسنجی و دیدن گسترهٔ واقعی کار، اعلام می‌شود.

• سورس‌کد کامل اپ اندروید، بک‌اند و پنل مدیریت
• کلید امضای اپ (keystore) به‌همراه رمز آن
• بستهٔ نهایی APK و AAB
• مستندات فنی، مستندات API و راهنمای استقرار
• حساب توسعه‌دهندهٔ کافه‌بازار و مایکت به نام کسب‌وکار شما
• دسترسی مدیریتی سرور، دیتابیس و دامنه