اپلیکیشن موبایل یا وب‌اپلیکیشن؟ کدام را بسازید

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

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

اول ببینید کاربرتان روی کدام سیستم‌عامل است

بدون این عدد، بقیهٔ بحث حدس است. طبق آمار استت‌کانتر از سهم سیستم‌عامل موبایل در ایران در اوت ۲۰۲۶، سهم اندروید از گوشی‌های همراه حدود ۸۵٫۵ درصد و سهم iOS حدود ۱۴٫۵ درصد است.

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

چیزی که مقایسه‌های رایج نمی‌گویند: مسیر انتشار

فرض کنید تصمیم گرفتید اپ نیتیو بسازید. حالا باید آن را به دست کاربر برسانید.

گوگل‌پلی. در جدول رسمی گوگل از کشورهای مجاز برای ثبت‌نام توسعه‌دهنده و فروشنده، نام ایران نیامده است. فهرست از افغانستان تا زیمبابوه ادامه دارد و ایران در آن نیست.

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

پس در عمل دو مسیر می‌ماند. برای اندروید، مارکت‌های داخلی مثل کافه‌بازار و مایکت، یا دانلود مستقیم فایل APK از سایت خودتان. هر دو کار می‌کند؛ مارکت داخلی احراز هویت و پذیرش قرارداد می‌خواهد و دانلود مستقیم یعنی هر به‌روزرسانی را باید خودتان به کاربر اطلاع بدهید.

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

همین بن‌بست است که سرویس‌های بزرگ ایرانی را به سمت وب برده. نسخهٔ تحت وب اسنپ روی app.snapp.taxi بالا می‌آید و فایل manifest دارد، یعنی عمداً به شکل یک وب‌اپلیکیشن نصب‌شدنی ساخته شده، نه یک صفحهٔ موبایلی ساده.

وب‌اپلیکیشن امروز چه می‌تواند که چند سال پیش نمی‌توانست

بخش زیادی از مقاله‌های فارسی این حوزه هنوز تصویری از وب دارند که مربوط به قبل از سال ۲۰۲۳ است.

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

نوتیفیکیشن روی آیفون. اپل در وبلاگ WebKit اعلام کرد از iOS 16.4 وب‌پوش برای وب‌اپلیکیشن‌هایی که به صفحهٔ اصلی اضافه شده‌اند کار می‌کند، به شرط اینکه display در فایل manifest روی standalone یا fullscreen باشد و درخواست مجوز در پاسخ به یک کنش مستقیم کاربر انجام شود. در iOS 18.4 هم نسخهٔ سبک‌تری از این قابلیت اضافه شد که بدون سرویس‌ورکر کار می‌کند.

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

و چه چیزهایی هنوز از دستش برنمی‌آید

اینجا جایی است که خیلی از پروژه‌ها وسط کار به دیوار می‌خورند.

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

دسترسی به سخت‌افزار خاص. طبق Can I Use، سافاری در هیچ نسخه‌ای Web Bluetooth را پشتیبانی نمی‌کند. اگر محصول شما باید با ترازو، بارکدخوان بلوتوثی یا دستگاه POS حرف بزند، روی آیفون از مرورگر کاری ساخته نیست.

کارهای پس‌زمینه. همگام‌سازی در پس‌زمینه و ردیابی موقعیت وقتی برنامه بسته است، بیرون از توان وب‌اپلیکیشن‌اند. برای یک اپ پیک یا سرویس میدانی، این تفاوت تعیین‌کننده است.

سه سؤالی که تصمیم را می‌سازند

به‌جای مقایسهٔ فهرست امکانات، این سه را برای محصول خودتان جواب بدهید.

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

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

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

کراس‌پلتفرم کجای این تصمیم است؟

هر تیمی که استعلام بدهید، احتمالاً Flutter یا React Native را پیشنهاد می‌کند: یک کدپایه، خروجی اندروید و iOS. این پیشنهاد یک مسئلهٔ واقعی را حل می‌کند و یک مسئلهٔ واقعی را دست‌نخورده می‌گذارد.

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

آنچه حل نمی‌کند همان چیزی است که این نوشته با آن شروع شد. کراس‌پلتفرم یک فایل نصبی iOS تولید می‌کند؛ ولی مسیری برای رساندن آن فایل به دست کاربر ایرانی نمی‌سازد. مشکل انتشار مشکل زبان برنامه‌نویسی نیست، مشکل حساب توسعه‌دهنده است. پس اگر دلیل اصلی شما برای کراس‌پلتفرم پوشش دادن آیفون بود، آن دلیل در بازار ایران کمتر از چیزی که به نظر می‌رسد وزن دارد.

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

هزینه: «وب ارزان‌تر است» جواب کاملی نیست

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

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

کجا واقعاً باید اپ نیتیو ساخت

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

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

اشتباه‌هایی که تکرار می‌شوند

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

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

فراموش کردن پنل مدیریت. هر اپلیکیشنی پشتش یک جای مدیریت داده می‌خواهد و این معمولاً از قلم می‌افتد. اینکه پنل اختصاصی بسازید یا از آماده استفاده کنید خودش یک تصمیم جدا است و روی زمان‌بندی پروژه اثر می‌گذارد.

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

پرسش‌های پرتکرار

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

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

می‌شود وب‌اپلیکیشن را در کافه‌بازار منتشر کرد؟ مارکت‌ها فایل نصبی اندروید می‌گیرند. برای حضور در مارکت باید یک اپ اندروید واقعی داشته باشید.

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

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