نیتیو یا کراس پلتفرم

نیتیو و کراس پلتفرم دقیقا چه فرقی دارند؟

نیتیو یعنی برنامه را با ابزار و زبان خود همان سیستم عامل بنویسید. سند خود گوگل صریح است: از سال ۲۰۱۹ توسعه اندروید به شکل فزاینده ای کاتلین محور اعلام شده و همان صفحه توصیه می کند اگر می خواهید اپلیکیشن اندروید بسازید با کاتلین شروع کنید. طرف اپل هم سوئیفت است. نتیجه اش این است که یک اپلیکیشن روی دو سیستم عامل، دو برنامه جداست.

کراس پلتفرم یعنی یک کد پایه بنویسید و همان کد روی هر دو اجرا شود. دو خانواده رایج، دو راه متفاوت را می روند و همین تفاوت را باید فهمید. مستند React Native می گوید هنگام اجرا همان ویوهای متناظر اندروید و iOS را می سازد و چون کامپوننت هایش پشتشان همان ویوهای بومی است، ظاهر و حس و کارایی اپلیکیشن مثل هر اپلیکیشن دیگری است. فلاتر راه دیگری دارد و صفحه سکوهای پشتیبانی شده اش نشان می دهد دامنه اش از اندروید و iOS فراتر می رود و ویندوز و مک و لینوکس را هم شامل می شود.

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

چهار چیزی که واقعا تصمیم را عوض می کند

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

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

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

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

برای بازار ایران، «هر دو فروشگاه» یعنی چه؟

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

پس وقتی کسی «انتشار در هر دو فروشگاه» را به عنوان مزیت اصلی کراس پلتفرم می فروشد، برای بازار ایران باید سوال را عوض کرد. اپلیکیشن اندرویدی اینجا از کافه بازار و مایکت نصب می شود و گاهی هم مستقیم از یک فایل روی خود سایت، و نسخه iOS داستان جداگانه ای دارد. جزئیاتش کار درس انتشار همین مسیر است.

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

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

کجا کراس پلتفرم جواب نمی دهد

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

حالت چهارم فنی تر است و بیشتر از سه تای دیگر پروژه ها را غافلگیر می کند. کراس پلتفرم به لایه ای وابسته است که قابلیت های سکو را برایش بسته بندی می کند. تا وقتی آن بسته بندی وجود دارد همه چیز خوب است. لحظه ای که قابلیتی تازه یا کم استفاده لازم شود و بسته بندی اش نباشد، باید همان تکه را نیتیو بنویسید، یک بار برای اندروید و یک بار برای iOS. آن وقت به جای یک کد پایه، سه تا دارید. این هزینه در برآورد اولیه هیچ وقت نوشته نمی شود.

و یک حالت پنجم که فنی نیست: تیمی که فقط نیتیو بلد است و قرار نیست عوض شود. یادگیری یک استک تازه وسط یک پروژه واقعی هزینه ای است که معمولا از صرفه جویی همان استک بیشتر می شود.

قبل از انتخاب استک، این پنج سوال را جواب بدهید

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

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

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