اگر محصول شما به دوربین، سنسورها، پردازش سنگین یا اجرای پایدار در پس‌زمینه وابسته است، نیتیو (Swift برای iOS و Kotlin برای اندروید) امن‌تر است. اگر با تیم و بودجهٔ محدود هر دو پلتفرم را می‌خواهید و رابطتان استاندارد است، Flutter یا React Native معمولاً منطقی‌تر است.
این مقاله برای مدیر محصول یا صاحب کسب‌وکاری است که قرار است وارد جلسه‌ای با تیم فنی یا شرکت توسعه‌دهنده شود. در چنین جلسه‌ای معمولاً یک جمله شنیده می‌شود: «هر دو شدنی است». درست هم هست، ولی تصمیم را حل نمیکند. پایان این مقاله شما را به چهار متغیر مشخص می‌رساند که با آن‌ها می‌توانید گزینه را برای بررسی با تیم فنی انتخاب کنید و پرسش‌های درست را بپرسید.
با چه معیارهایی نیتیو و کراسپلتفرم را مقایسه کنیم
نیتیو یعنی برای هر سیستمعامل یک اپ جدا با ابزار رسمی خودش بسازید: Swift با Xcode برای iOS و Kotlin با Android Studio برای اندروید. کراسپلتفرم یعنی یک پایگاه کد مشترک که روی هر دو سیستمعامل اجرا می‌شود؛ رایج‌ترین نمونه‌هایش Flutter و React Native هستند.
دو تفکیک را همین ابتدا نگه دارید. کراسپلتفرم با وب‌اپ یکی نیست، و با رویکردهای هیبریدی که صفحهٔ وب را داخل یک WebView می‌گذارند هم یکی نیست. هر کدام هزینه و محدودیت خودشان را دارند. در این مقاله وب‌اپ و PWA فقط در یک موقعیت مشخص و کوتاه می‌آیند.
چرا فقط شش معیار
فهرست ویژگی‌ها را می‌شود تا بی‌نهایت بلند کرد، ولی تصمیم شما با شش معیار گره خورده است که هر کدام مستقیم به هزینه یا ریسک محصول می‌رسند: عملکرد، تجربهٔ کاربری، دسترسی به قابلیت‌های دستگاه، سرعت توسعه، نگهداری و نیاز تیم. معیاری که روی پول یا ریسک اثر نگذارد، در این مقایسه جایی ندارد.
اشتراک کد چه چیزی را حذف نمیکند
اینجا رایج‌ترین سوءتفاهم رخ میدهد. اشتراک کد یعنی بخش بزرگی از منطق و رابط یک‌بار نوشته می‌شود. یعنی کار اختصاصی هر پلتفرم صفر نمی‌شود. تنظیم مجوزها، اعلان‌ها، آماده‌سازی و انتشار در فروشگاه‌ها و رفتارهای خاص هر سیستمعامل همچنان کار جدا می‌خواهد، و تست روی هر دو سیستمعامل هم سر جایش می‌ماند. اگر زمینهٔ فنی کافی ندارید، راهنمای برنامه‌نویسی برای مدیران کسب‌وکار واژه‌های این جلسه را برایتان روشن می‌کند.
جدول مقایسه: شش معیار در یک نگاه و عواملی که هزینه را می‌سازند
جدول زیر عمداً عدد و بنچمارک ندارد. سلول‌ها شرطی‌اند، چون جواب هر ردیف به نوع محصول بستگی دارد و بعد از جدول می‌گوییم دقیقاً به چه چیزی.
| معیار | نیتیو (Swift، Kotlin) | کراسپلتفرم (Flutter، React Native) |
|---|---|---|
| عملکرد | کنترل دقیق‌تر روی عملکرد و حافظه | برای رابط و منطق معمول کافی است؛ برای بار سنگین باید با نمونهٔ آزمایشی سنجید |
| تجربهٔ کاربری | هماهنگ‌ترین حس با هر سیستمعامل | رابط یکدست روی هر دو؛ رفتار بومی گاهی کار اضافه می‌خواهد |
| دسترسی به قابلیت‌های دستگاه | دسترسی مستقیم و زودهنگام به قابلیت‌های تازهٔ سیستمعامل | بسته به نوع قابلیت؛ گاهی پلاگین کافی است، گاهی ماژول بومی لازم می‌شود |
| سرعت توسعه | دو مسیر موازی، با هماهنگی زمان‌بندی | معمولاً سریع‌تر برای محصولی با رابط و منطق نسبتاً یکسان |
| نگهداری | دو پایگاه کد برای به‌روزرسانی | یک پایگاه کد، به‌اضافهٔ وابستگی به پکیج‌ها و نسخهٔ فریم‌ورک |
| نیاز تیم | توسعه‌دهندهٔ iOS و اندروید جدا | توسعه‌دهندهٔ موبایل کراسپلتفرم، با تکیه‌گاه بومی در صورت نیاز |
هزینه را چه چیزی تعیین می‌کند
این فرض که کراسپلتفرم ارزان‌تر است، بدون شرط درست نیست. هزینه از چند عامل ساخته می‌شود: حجم قابلیت‌های بومی، تعداد صفحه‌ها و پیچیدگی انیمیشن‌ها، تست روی دستگاههای متنوع، ترکیب تیم، نگهداری بلندمدت و هزینهٔ بازنویسی اگر انتخاب اولیه اشتباه از آب درآمد. صرفه‌جویی کراسپلتفرم وقتی کم می‌شود که ماژول‌های بومی زیاد شوند؛ آن‌وقت عملاً هر دو نوع تخصص را لازم دارید. برای برآورد هزینهٔ واقعی پروژهٔ خودتان، باید از شرکت‌ها پیشنهاد مبتنی بر فهرست قابلیت‌های همین محصول بگیرید، نه عددی کلی.
ماتریس تصمیم چهارمتغیره
به‌جای «بستگی دارد»، چهار متغیر را بسنجید. هر کدام می‌گوید کدام گزینه کجا جلوتر است.
- وابستگی به سخت‌افزار: نیتیو جلوتر است وقتی دوربین، سنسور، دستگاه جانبی یا پردازش لحظه‌ای هستهٔ محصول است. کراسپلتفرم جلوتر است وقتی سخت‌افزار فقط پشتیبان است، مثل عکس‌گرفتن ساده یا نمایش نقشه.
- اختصاصی‌بودن رابط: نیتیو جلوتر است وقتی هر پلتفرم باید حس و رفتار خودش را داشته باشد. کراسپلتفرم جلوتر است وقتی رابط شما فرم، فهرست و صفحه‌های استاندارد است.
- افق نگهداری: نیتیو جلوتر است وقتی محصول چند سال عمر می‌کند و می‌خواهید با هر نسخهٔ جدید سیستمعامل از قابلیت‌های تازه سریع استفاده کنید. کراسپلتفرم جلوتر است وقتی هنوز می‌خواهید بازار را بسنجید و نسخهٔ اول باید زود بیرون بیاید.
- ترکیب تیم: نیتیو جلوتر است وقتی تیم یا شریک فنی‌تان از قبل در Swift و Kotlin مسلط است. کراسپلتفرم جلوتر است وقتی تیمی کوچک دارید و استخدام دو تخصص جدا شدنی نیست.
اگر چهار متغیر به یک سمت اشاره کردند، تصمیم ساده است. اگر دو به دو شدند، وزن را به متغیری بدهید که اشتباه در آن گران‌تر تمام می‌شود، معمولاً وابستگی به سخت‌افزار.
نیتیو: کجا واقعاً برنده است و کجا نه
نیتیو وقتی برنده است که محصول شما به رفتار خود سیستمعامل تکیه دارد و اشتباه در آن را نمی‌شود با یک وصله جبران کرد.
وقتی محصول به سخت‌افزار و رفتار سیستمعامل تکیه دارد
پردازش تصویر و صدا، اتصال به دستگاههای جانبی و اجرای پس‌زمینه‌ای حساس، نقاطی‌اند که در عمل دیده‌ایم نیتیو کمتر شما را غافلگیر می‌کند. دلیلش روشن است: ابزار رسمی هر سیستمعامل اول از همه به قابلیت‌های جدید خودش دسترسی میدهد و کنترل روی عملکرد و حافظه دقیق‌تر است. اگر فقط یک پلتفرم را هدف دارید، مسیر توسعهٔ اپ آیفون یا توسعهٔ اپ اندروید ساده‌تر و مستقیم‌تر از هر راه میانی است.
بهایش را هم باید دید: دو پایگاه کد، دو مهارت و هماهنگی زمان‌بندی میان دو تیم. هر قابلیت جدید باید دو بار ساخته و دو بار تست شود.
وقتی نیتیو توجیه خود را از دست میدهد
اگر رابط شما ساده و فرم‌محور است، تیمتان کوچک است و فقط می‌خواهید بازار را زود بسنجید، دو اپ جدا بیشتر سرعت شما را می‌گیرد تا کیفیت را بالا ببرد. نیتیو در این موقعیت اغلب دقت اضافه می‌خرد که کاربر نسخهٔ اول هنوز مطالبه نمیکند.
کراسپلتفرم: کجا برنده است و کجا اشتراک کد وعده‌ای است که کامل محقق نمی‌شود
کراسپلتفرم وقتی برنده است که یک تیم کوچک باید محصولی با رابط و منطق تقریباً یکسان را روی هر دو سیستمعامل ببرد و مدام روی آن تکرار کند.
Flutter و React Native در یک پاراگراف
این دو بحث آموزش فریم‌ورک نیستند، فقط در حدی که تصمیم را تغییر می‌دهند. Flutter رابط را با موتور رسم خودش می‌سازد و کنترل یکدستی ظاهر را بالا می‌برد. React Native عناصر رابط خود پلتفرم را به کار می‌گیرد و برای تیمی که با دنیای جاوااسکریپت آشناست مسیر نزدیک‌تری است. انتخاب را با محبوبیت یا تعداد برنامه‌نویس‌های موجود در بازار نکنید. معیار این است که کدام با نیاز محصول و مهارت تیم واقعی شما می‌خواند.
نشانه‌های اینکه کار اختصاصی هر پلتفرم دارد برمی‌گردد
اشتراک کد زمانی به وعده‌ای نیمه‌کاره تبدیل می‌شود که این نشانه‌ها را ببینید:
- تعداد ماژول‌های بومی در پروژه مدام بیشتر می‌شود.
- باگ‌هایی گزارش می‌شود که فقط روی یکی از دو سیستمعامل رخ میدهد.
- پروژه به پکیج‌هایی تکیه دارد که دیگر نگهداری نمی‌شوند.
- هر به‌روزرسانی سیستمعامل، کار پیش‌بینی‌نشده می‌آورد.
هر کدام از این‌ها یعنی آن صرفه‌جویی اولیه دارد خرج می‌شود. و تست جداگانه روی اندروید و iOS در هر حال لازم است؛ کراسپلتفرم آن را حذف نمیکند، فقط پایگاه کدی را که تست می‌شود کمتر می‌کند.
قابلیت‌های حساس: دوربین، موقعیت مکانی، پردازش سنگین و اجرای پس‌زمینه
هر قابلیت را جدا بسنجید، نه کل اپ را. یک اپ می‌تواند بیشتر صفحه‌هایش ساده باشد و فقط یک قابلیت حساس داشته باشد؛ همان یک قابلیت تصمیم را میچرخاند.
هر قابلیت را جدا بسنجید
- دوربین: ضبط ساده با پلاگین معمولاً شدنی است. پردازش لحظه‌ای تصویر، مثل اسکن زنده، به بررسی دقیق نیاز دارد.
- موقعیت مکانی: نمایش نقشه و ردیابی وقتی اپ باز است یک مسئله است. ردیابی پایدار در پس‌زمینه مسئلهٔ دیگری است.
- پردازش سنگین و انیمیشن پیچیده: فقط با نمونهٔ آزمایشی روی دستگاه واقعی روشن می‌شود.
- اجرای پس‌زمینه: محدودیت‌های دو سیستمعامل با هم فرق دارد و اغلب کد بومی می‌خواهد.
جایی که توصیهٔ متعارف شکست می‌خورد
توصیهٔ رایج می‌گوید «برای اپ معمولی کراسپلتفرم بزنید». این توصیه وقتی می‌شکند که اپ ظاهراً معمولی است ولی یک قابلیت پس‌زمینه‌ای در دلش پنهان است. در بازار ایران چند ملاحظه هم اضافه می‌شود: اعلان‌ها اغلب به سرویس‌های گوگل تکیه دارند و روی دستگاه‌هایی که این سرویس‌ها را ندارند یا محدود است، باید راه‌حل جایگزین پیش‌بینی شود. انتشار در بازارهای داخلی مثل کافه‌بازار و مایکت شرایط خودش را دارد، و آزمون باید روی دستگاههای رایج همین بازار انجام شود، نه فقط روی گوشیهای گران تیم توسعه.
هر ادعای «سریع» یا «کند» بدون شرایط آزمون و منبع قابل‌پذیرش نیست. از شرکت توسعه‌دهنده بخواهید برای قابلیت حساس شما نمونهٔ آزمایشی بسازد و نتیجه‌اش را روی دستگاه واقعی نشانتان بدهد.
کدام برای شما: سه موقعیت، چک‌لیست و پرسش‌هایی برای شرکت توسعه‌دهنده
این سناریوها فرضی‌اند و نام و عدد ندارند، ولی الگوی تصمیم را نشان می‌دهند.
سناریوی ۱: MVP خدماتی با رزرو، نقشه و پرداخت
کسب‌وکاری می‌خواهد خدمات در محل را از طریق اپ رزرو کند: انتخاب خدمت، نمایش نقشه، پرداخت و اعلان وضعیت. رابط استاندارد است، قابلیت پس‌زمینهٔ سنگینی در کار نیست و تیم کوچک است. در این موقعیت معمولاً کراسپلتفرم منطقی‌تر است. شرط‌هایش را بررسی کنید: اتصال به درگاه پرداخت روی هر دو سیستمعامل، رفتار اعلان بدون اتکای کامل به سرویس‌های گوگل، و انتشار در بازارهای داخلی. اگر یکی از این‌ها به ماژول بومی سنگین نیاز داشت، هزینه را دوباره حساب کنید.
سناریوی ۲: اپ با تعامل عمیق با سخت‌افزار
اپی که با دوربین اسکن می‌کند یا موقعیت را در پس‌زمینه ردیابی می‌کند. اینجا معمولاً نیتیو، یا کراسپلتفرم همراه با ماژول بومی قوی، انتخاب امن‌تر است. شرط روشن است: اگر هستهٔ محصول به دوربین، سنسور یا پردازش لحظه‌ای وابسته است، تیمی با تجربهٔ بومی لازم دارید و گزینهٔ «همه‌چیز را کراسپلتفرم بزنیم» را فقط با نمونهٔ آزمایشی قبول کنید.
سناریوی ۳: ابزار داخلی یا محتوایی
اگر اپ برای نمایش محتوا یا ابزار داخلی سازمان است، به اعلان قوی و دسترسی به سخت‌افزار نیازی ندارد و نصب از فروشگاه هم ضروری نیست، وب‌اپ یا PWA ممکن است کافی باشد. این را با کراسپلتفرم یکی نگیرید؛ مسیر دیگری است با محدودیت‌های دیگر.
چک‌لیست تصمیم‌گیری
- کدام قابلیت‌ها حیاتی‌اند و محصول بدون آن‌ها معنا ندارد؟
- تیم فعلی یا شریک فنی‌تان چه مهارتی دارد؟
- افق نگهداری چند سال است؟
- چند پلتفرم همزمان لازم دارید، یا شروع با یکی هم کافی است؟
پرسش‌هایی که باید از شرکت توسعه‌دهنده بپرسید
- برای این محصول چند ماژول بومی لازم می‌شود و کدام‌ها؟
- برای قابلیت حساس ما نمونهٔ آزمایشی چیست و روی کدام دستگاه‌ها تست می‌شود؟
- تست روی هر دو سیستمعامل چگونه انجام می‌شود؟
- هزینهٔ نگهداری و به‌روزرسانی با تغییر نسخهٔ سیستمعامل چگونه محاسبه می‌شود؟
از شرکتی که وعدهٔ قطعی برای انتشار در فروشگاه‌ها میدهد محتاط باشید؛ فرایند بررسی را خود فروشگاه‌ها تعیین می‌کنند، نه شرکت.
قدم بعد و مرز کاربرد این توصیه
قدم بعد روشن است: فهرست قابلیت‌های حیاتی را بنویسید، چهار متغیر ماتریس را روی آن اجرا کنید و با همین سند سراغ شرکت‌ها بروید. برای بررسی ارائه‌دهندگان متناسب با نیاز فنی پروژه، صفحهٔ شرکت‌های توسعه اپ موبایل نقطهٔ شروع خوبی است.
و مرز این توصیه‌ها: اگر نیاز محصول هنوز روشن نیست، یا قابلیت‌های حساس هنوز در نمونهٔ آزمایشی امتحان نشده‌اند، هیچ‌کدام از دو مسیر را نهایی نکنید. ماتریس بالا برای انتخاب میان دو گزینه است، نه برای جبران ندانستنِ اینکه محصول دقیقاً چه کاری باید بکند.
پرسش‌های متداول
اگر اپ را اول کراسپلتفرم بسازیم، بعداً می‌شود به نیتیو مهاجرت کرد؟
نمونهٔ آزمایشی برای قابلیت حساس اپ باید چه شرایطی داشته باشد تا قابلاتکا باشد؟
اپ کراسپلتفرم را می‌شود در کافه‌بازار و مایکت منتشر کرد؟
اگر بودجه فقط برای یک پلتفرم باشد، اول اندروید را بسازیم یا iOS را؟
به این مقاله امتیاز دهید
اولین نفری باشید که امتیاز میدهد
درباره نویسنده
