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

هرکدام چطور کار می‌کنند

نیتیو

برای هر پلتفرم جداگانه می‌نویسید: Kotlin برای اندروید و Swift برای iOS. اپلیکیشن مستقیم از ابزارها و اجزای همان سیستم‌عامل استفاده می‌کند. بیشترین اختیار را دارید و قابلیت‌های تازه سیستم‌عامل را زودتر از همه می‌گیرید، اما عملاً دو پایگاه کد دارید.

Flutter

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

React Native

با جاوااسکریپت یا TypeScript می‌نویسید و رابط از اجزای بومی سیستم ساخته می‌شود. از نسخه ۰٫۷۶، معماری تازه به‌صورت پیش‌فرض فعال است و ارتباط میان جاوااسکریپت و بخش بومی به‌جای پل قدیمی، مستقیم از طریق JSI انجام می‌شود. مستندات خودش یادآوری می‌کند که این معماری به‌خودی‌خود برنامه را سریع‌تر نمی‌کند و گاهی بازنویسی کد لازم است.

Kotlin Multiplatform

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

پنج پرسشی که واقعاً تصمیم را عوض می‌کنند

  1. چقدر به دستگاه وابسته‌اید؟ بلوتوث، پردازش تصویر زنده، کار پس‌زمینه و قابلیت‌های تازه سیستم‌عامل کفه را به سمت نیتیو می‌برند. نمایش فهرست، فرم و پرداخت با هر گزینه‌ای شدنی است.
  2. چه کسی نگهش می‌دارد؟ اگر تیم شما وب‌کار و مسلط به TypeScript است، React Native منطقی‌تر است. فناوری‌ای که در تیم و بازار کار شما نیرو ندارد، بعداً گران تمام می‌شود.
  3. چقدر باید طبیعی به نظر برسد؟ برخی محصولات باید دقیقاً مثل بقیه برنامه‌های سیستم رفتار کنند و برخی هویت بصری یکسان می‌خواهند. این دو نیاز به انتخاب‌های متفاوتی می‌رسند.
  4. کد موجود چیست؟ اگر همین حالا منطق یا رابط وب دارید، استفاده دوباره از آن می‌تواند زمان زیادی ذخیره کند.
  5. برنامه چند سال باید زنده بماند؟ برای محصول چندساله، پایداری اکوسیستم و بار ارتقای نسخه‌ها از سرعت ساخت نسخه اول مهم‌تر است.

درباره سرعت و هزینه

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

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

یک راهنمای کوتاه

  • وابستگی شدید به دستگاه یا تجربه کاملاً بومی: نیتیو
  • تیم وب با TypeScript: React Native
  • ظاهر یکسان و کنترل کامل رابط: Flutter
  • تیم Kotlin با رابط بومی و منطق مشترک: Kotlin Multiplatform

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

منابع