بررسی عمیق کاتالیست؛ آینده نرم‌افزارهای مک چگونه خواهد بود؟

اپل در رویداد توسعه‌دهنده‌های خود در سال جاری (WWDC 2019) از نسخه‌ی جدید سیستم‌عامل مک به‌نام کاتالینا رونمایی کرد. به‌علاوه راهکاری جدید برای تبدیل کردن اپلیکیشن‌های آیپد به مک معرفی شد که توجه بسیاری از توسعه‌دهنده‌ها و کاربران را به خود جلب کرد. راهکار جدید به‌نام پروژه‌ی کاتالیست (Project Catalyst) و با هدف افزایش دادن تعداد اپلیکیشن‌های پلتفرم مک معرفی شد. با استفاده از کاتالیست، اپلیکیشن‌های بسیار بیشتری که در اکوسیستم عظیم iOS و iPadOS حضور دارند به‌راحتی به مک منتقل خواهند شد.

پروژه‌ی کاتالیست علاوه‌بر کاربران برای توسعه‌دهنده‌ها هم سؤال‌هایی را ایجاد می‌کند. آیا کاتالیست جای پایی برای حرکت به سمت رابط کاربری SwiftUI خواهد بود؟ از آن مهم‌تر توسعه‌دهنده‌ها برای هماهنگ کردن اپلیکیشن‌های آیپد با مک چه چالش‌هایی خواهند داشت؟

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

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

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

افراد زیر در مصاحبه‌های مرتبط با پروژه‌ی کاتالیست آرس‌تکنیکا حضور داشتند:

• تاد بنجامین، مدیر ارشد بازاریابی اپل در بخش مک
• علی اوزر، مهندس ارشد پروژه‌ی Cocoa اپل که در کاتالیست هم حضور داشت
• شان پرودن، مدیر ارشد اپل در بخش مدیریت شرکا و ارتباط با توسعه‌دهنده‌ها
• مانو رویز، مهندس موتور نرم‌افزار در Gameloft که بازی آیپد آسفالت ۹ را به مک منتقل کرد
• الکس اربانو، مهندس گرافیک گیم‌لافت که در نسخه‌ی مک آسفالت ۹ فعالیت داشت
• ریک شیمانو، توسعه‌دهنده‌ی iOS در TripIt. اپلیکیشن مسافرتی که با استفاده از کاتالیست به مک منتقل شد
• نولان اوبراین، مهندس ارشد نرم‌افزار در توییتر که با استفاده از کاتالیست اپلیکیشن توییتر را به مک بازگرداند

بلومبرگ در گزارشی در دسامبر ۲۰۱۷ اعلام کرد که اپل پروژه‌‌ای برای توسعه‌ی آسان‌تر اپلیکیشن‌های مک درکنار iOS در سر دارد. در رویداد WWDC امسال جزئیات کامل‌تری از برنامه‌ی اپل و نام پروژه یعنی کاتالیست منتشر شد. پروژه‌‌ای که انتقال اپلیکیشن‌های آیپد به مک را بسیار آسان می‌کند.

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

وب‌سایت توسعه‌دهنده‌های اپل درباره‌ی قابلیت تغییر رابط کاربری می‌‌نویسد:

اپلیکیشن مکِ حاصل شده، دقیقا مانند یک اپلیکیشن Native عمل می‌کند. از همان فریمورک‌ها، منابع و محیط‌های اجرایی استفاده می‌کند که اپلیکیشن‌های اختصاصی مک به کار می‌گیرند. قابلیت‌های پایه‌ای مک و امکانات پنجره‌ای برای اپلیکیشن‌ها اضافه شده‌اند و کنترل‌های لمسی نیز به کیبورد و ماوس تغییر می‌کنند. عناصر شخصی‌سازی‌شده‌ی رابط کاربری که با کد اولیه توسعه داده می‌شوند هم به همان صورت اضافه می‌شوند. در ادامه می‌توانید قابلیت‌های را با استفاده از APIهای UIKit در Xcode ایجاد کنید که کیفیت بالای اپلیکیشن و کارکرد روان آن را تضمین می‌کند.

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

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

شان پرودن در بخشی از مصاحبه‌ی خود پیرامون انگیزه‌های پروژه‌ی کاتالیست می‌گوید:

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

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

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

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

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

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

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

۱- بخش شناسه‌ی بسته‌ به نسخه‌ی مک اپلیکیشن اضافه می‌شود.

۲- App Sandbox Entitlement به پروژه‌ اضافه می‌شود. Xcode این بخش را تنها به نسخه‌ی مک اضافه می‌کند و نسخه‌ی iOS دست نخورده باقی می‌ماند.

۳- گزینه‌ی My Mac در بخش اجرا و مشاهده‌ی اپلیکیشن اضافه می‌شود که توسعه‌دهنده می‌تواند در زمان بازبینی آن را در شبیه‌سازی مک بررسی کند.

۴- فریمورک‌ها، افزودنی‌ها و دیگر محتوای داخل اپلیکیشن که با مک سازگار نیستند، حذف می‌شوند.

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

• منوی پیش‌فرض برای اپلیکیشن
• پشتیبانی از ورودی‌های ترک‌پد، ماوس و کیبورد
• پشتیبانی از تغییر ابعاد پنجره‌‌ها و فعالیت در حالت تمام‌صفحه
• نوار اسکرول به سبک مک
• پشتیبانی از کپی و الصاق
• پشتیبانی از درگ اند دراپ
• پشتیبانی از کنترل‌های سیستمی Touch Bar

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

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

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

اوزر در توضیح استفاده از عملگرهای شرطی در کدها می‌گوید:

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

اپل ادعا می‌کند که بسیاری از توسعه‌دهنده‌ها در اولین تجربه با کاتالیست در مدت ۲۴ ساعت به اپلیکیشنی مناسب و قابل اجرا در مک رسیده‌اند. البته برخی از آن‌ها نیز بسته به اپلیکیشن و سرویس مورد نظر چالش‌هایی را تجربه کرده‌اند.

اپل از تعداد توسعه‌دهنده دعوت کرد تا با استفاده از کاتالیست، اپلیکیشن‌های خود را آماده کنند. اپلیکیشن‌های آن‌ها در WWDC نمایش داده شد که چشم‌اندازی کامل را از نتیجه‌ی پروژه‌ی کاتالیست نشان می‌داد. آرس‌تکنیکا با توسعه‌دهنده‌های سه اپلیکیشن که محصولاتشان را در WWDC نمایش دادند به‌صورت مجزا مصاحبه کرده است. آن‌ها اپلیکیشن‌های Asphalt 9 و TripIt و Twitter را از آیپد به مک منتقل کردند.

توییتر از سال ۲۰۱۶ پشتیبانی از اپلیکیشن مک خود را پایان داد. البته اپلیکیشن‌های متفرقه‌ای برای استفاده از توییتر در سیستم‌عامل مک وجود دارند، اما شرکت اصلی تصمیم گرفت تا وب را به‌عنوان پلتفرم اصلی کاربران مک خود در نظر بگیرد.

اوبراین در مصاحبه پیرامون اپلیکیشن توییتر در مک گفت:

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

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

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

حذف OpenGL چالش‌های متعددی را برای توسعه‌دهنده‌های اپل ایجاد کرد. البته چالش‌های مذکور نسبت به مشکلاتی که در جابه‌جایی اپلیکیشن‌ها از آیپد به مک وجود داشت، ناچیز محسوب می‌شدند. به‌هرحال اوبراین صرف‌نظر از همه‌ی چالش‌ها اعتقاد دارد پروژه‌ی کاتالیست، پشتیبانی از اپلیکیشن توییتر در مک را به سطحی برابر با اپلیکیشن‌های آیفون، آیپد و آیپاد نزدیک می‌کند.

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

فرایند انتقال واقعا آسان بود. پروژه‌ی موجود iOS را باز، گزینه‌ی مورد نظر را انتخاب کرده و کامپایل جدیدی استخراج کردیم. البته اپلیکیشن حاصل در مرحله‌ی اول بدون مشکل اجرا نشد، چون برخی از کتابخانه‌های ما (همچون کنترل حرکتی) در دستگاه‌های غیرموبایلی پشتیبانی نمی‌شدند. به‌علاوه برخی کتابخانه‌های متفرقه هم برای macOS و پلتفرم‌های x86 و ۶۴ بیت طراحی نشده‌اند. با توجه به این موارد، برخی از کدهای پایه‌ای را اصلاح کردیم و پس از ۲۴ ساعت نسخه‌ی کامل آسفالت کامپایل شد.

اربانو در بخش گرافیکی آسفالت فعالیت می‌کند و درباره‌ی تجربه‌ی استفاده از کاتالیست می‌گوید:

روش کاملا ساده‌ای بود. باید بخش‌هایی از دقت گرافیکی سایه‌ها را تغییر می‌دادیم تا آن‌ها را با رزولوشن بالاتر مک هماهنگ کنیم و همچنین عملکرد بازی را هم بهبود دهیم. برخی بخش‌های پردازشی همچون Metal Buffer را هم تغییر دادیم که مرحله‌ای الزامی بود. تغییرات ایجادشده به ما امکان داد تا جلوه‌های منحصربه‌فرد استفاده کنیم که در پلتفرم‌های دیگر در دسترس نیستند. به‌هرحال همه‌ی فرایندها با حفظ نرخ فریم 60fps در رزولوشن مقصد انجام شد.

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

پردازنده‌های گرافیکی دسکتاپ و موبایل تفاوت‌های عمده‌ای با هم دارند. البته هرگونه بهینه‌سازی در گرافیک موبایل می‌تواند در پلتفرم جدید هم بسیار کارآمد باشد. بهینه‌سازی‌هایی که شامل مواردی همچون پیش‌گیری از وضعیت Overdraw، محدود کردن حداکثری اشیاء ترکیب‌شونده، بهینه‌سازی هندسه با تمرکز روی مقدار Draw calls و موارد مشابه می‌شوند.با استفاده از قدرت بیشتر مک می‌توان تفاوت رزولوشن را در دستگاه‌ها برطرف کرد و جلوه‌های اضافه‌ای به تصویر نهایی افزود. در پروژه‌ی آسفالت ۹ ما جلوه‌هایی همچون سایه‌های عمیق‌تر برای خودرو، نمونه‌سازی دقیق‌تر و جلوه طبیعی‌تر بلور را به‌همراه SSR اضافه کردیم.درنهایت پورت کردن آسفالت ۹ به مک با سرعت بالایی انجام شد چون بازی ما هم‌اکنون برای هماهنگی حداکثری با رزولوشن‌ها، نسبت‌های ابعادی، APIها و ظرفیت‌های گوناگون دستگاه‌ها طراحی شده است. این قابلیت‌ها از مزایای توسعه‌ی فناوری به‌صورت داخل سازمانی هستند که انعطاف لازم را برای هماهنگی با پلتفرم‌های جدید به‌ شما می‌دهد.

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

توسعه‌دهنده‌های اپلیکیشن تریپ‌ایت توضیح کامل و جامعی از فرایند پورت کردن سرویس به مک ارائه دادند. ریک شیمانو توسعه‌دهنده‌ی این استارتاپ ایمیل کاملی به آرس‌تکنیکا ارسال کرد که توضیحات کاملش را درباره‌ی روند استفاده از کاتالیست می‌خوانیم:

در مرحله‌ی اول اپلیکیشن کنونی آیپد خود را برای کار در Xcode آماده کردیم که نیاز به کارهایی همچون شناسایی و حذف قابلیت‌های مبتنی بر منابع ناموجود داشت. بخش‌هایی همچون فریمورک‌های مبتنی بر تماس تلفنی و SDKهای متنوع iOS که از مک پشتیبانی نمی‌کنند، حذف شدند.سپس گزینه‌ی مورد نظر برای آماده‌سازی اپلیکیشن برای مک انتخاب شد. انتخاب گزینه، حذف بخش‌های اضافی و استخراج اپلیکیشن مخصوص مک با سرعت بالا و خطاهای پایین انجام شد و بسیار سریع‌تر از ساخت یک پروژه‌ی مک از ابتدا و وارد کردن منابع مورد نیاز به آن بود.در مرحله‌ی بعدی برخی از فریمورک‌ها و APIهایی که از مدت‌ها پیش توسط اپل پشتیبانی نمی‌شدند را حذف یا جایگزین کردیم. از میان آن‌ها می‌توان به MessageUI و UIWebView اشاره کرد که در کاتالیست پشتیبانی نمی‌شوند. سپس وابستگی اپلیکیشن به فریمورک‌های مبتنی بر موبایل هم حذف شد.اپلیکیشن ما به برخی فریمورک‌های متفرقه هم وابسته بود که باید حذف می‌شدند. از میان آن‌ها می‌توان به Crashlytics، ورود با اکانت فیسبوک و گوگل مپس اشاره کرد. امیدوارم پشتیبانی از این سرویس‌ها با عرضه‌ی iOS 13 حل شود. رابط کاربری بخش مدیریت پروژه‌ی Xclode به‌خوبی به‌روزرسانی شده است و حذف و اضافه کردن فریمورک‌ها، فایل‌های منبع و دیگر منابع آن‌چنان دشوار نیست. درنهایت با استفاده از UIKitForMac کدهای اولیه‌ی برنامه را در سویفت و Objective-C بررسی کردیم.مرحله‌ی دوم، اجرای همه‌ی فرایندهای کاربر و هماهنگی ‌داده‌ها بود تا هرگونه قابلیت ناموجود یا پشتیبانی نشده، حذف شود. به‌عنوان مثال سرویس موبایل ما از ورود با حساب کاربری گوگل پشتیبانی می‌کند، اما به‌خاطر عدم پشتیبانی در مک، دکمه‌های مذکور را غیرفعال کردیم. به‌علاوه ما قابلیت‌هایی داریم که به فریمورک‌های متفرقه برای ارائه‌ی نقشه وابسته هستند. درنتیجه المان‌های رابط کاربری را که اجرا کننده‌ی آن قابلیت‌ها هستند حذف کردیم. حتی کدهای دریافت داده از این بخش نیز پاک شدند.خوشبختانه بخش‌های مهمی از عملکرد سیستم همچون شبکه، قابلیت امنیتی Keychain و کدهای ماندگاری Core Data بدون تغییر کد عملکرد خود را حفظ کردند. درنتیجه نیازی به بازنویسی کدها در بسیاری از بخش‌ها پیدا نشد و زمان زیادی در توسعه‌ی اپلیکیشن مک صرفه‌جویی کردیم.مرحله‌ی نهایی به بهینه‌سازی رابط کاربری برای مک و قابلیت‌هایی همچون پنجره‌های چندگانه و پشتیبانی از ورودی ماوس و کلیک بود. معماری اطلاعاتی اپلیکیشن که در حالت موبایل به‌صورت تب عمل می‌‌کرد در حالت مک به بخش سایدبار منتقل شد. به‌علاوه یک نوارابزار جامع برای جابه‌جایی‌های داخل برنامه در بالای آن اضافه شد.طراحی‌های جدیدی برای حالت‌های تقسیم پنجره به اپلیکیشن اضافه شد تا استفاده از کل نمایشگر به‌صورت بهینه انجام شود. سپس طراحی‌های عبور نشان‌گر از روی المان‌های منو طراحی شدند که قابل کلیک بودن آن‌ها را به کاربر نشان می‌دهند. به‌علاوه بخش‌هایی برای میان‌برهای صفحه‌کلید هم به اپلیکیشن اضافه شد که البته اکنون به‌صورتی دیگر برای کاربران آیپد با صفحه‌کلید اکسترنال در دسترس هستند. در همین مرحله گزینه‌هایی برای مرور آسان‌تر صفحات توسط کاربران با محدودیت‌های حرکتی هم اضافه شد.در مراحل پایانی منوی ناوبری اصلی بهینه‌سازی شد تا همه‌ی عملکردهای مورد نیاز کاربر در آن تأمین شود. به‌علاوه ترکیب قابلیت‌های درگ اند دراپ آیپد با قبلیت‌های چند پنجره‌ای مک هم انجام شد تا ارتباط بین بخش‌های گوناگون اپلیکیشن به آسانی صورت بگیرد.

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

کاربران حرفه‌ای مک نگران هستند که آسان کردن انتقال اپلیکیشن‌های آیپد به مک، انگیزه‌های توسعه‌دهنده‌ها را برای ساخت اپلیکیشن‌های حرفه‌ای مک کاهش خواهد داد. برخی از نگرانی به این خاطر ایجاد می‌شود که اپلیکیشن‌های موبایلی عموما برای انجام وظایف محدود استفاده می‌شوند و مجموعه‌ی قابلیت‌های عظیمی که در اپلیکیشن‌های دسکتاپ وجود دارد، در آن‌ها دیده نمی‌شود. به‌علاوه ترکیب UIKit و Catalyst قابلیت‌های بی‌شمار و فریمورک‌های متنوع قبلی را در اختیار توسعه‌دهنده‌ها قرار نمی‌دهند. درواقع اگر توسعه‌دهنده از ابتدا با استفاده از Appkit یک اپلیکیشن مک بسازد، قطعا قابلیت‌های بیشتری در اختیار خواهد داشت.

مدیران و کارمندان اپل نگرانی بالا را آن‌چنان تأیید نمی‌کنند. به‌عنوان مثال اوزر می‌گوید که UIKit تاحدودی به کاربران دسترسی به AppKit را ارائه می‌کند. او می‌گوید توسعه‌دهنده‌ها حتی در زمان استفاده از UIKit در پورت کردن اپلیکیشن‌ها حتی به‌صورت غیرمستقیم به‌هرحال از AppKit استفاده می‌کنند و برخی از قابلیت‌های آن در دسترس خواهد بود.

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

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

بنجامین براساس نظر پرودن اعتقاد دارد که انواع مختلفی از اپلیکیشن برای کاربرد پروژه‌ی جدید وجود دارند. نظرات او بازتاب قابل‌توجهی از برنامه‌ی اپل در پروژه‌ی کاتالیست نشان می‌دهند:

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

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

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

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

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

بنجامین در تکمیل توضیحات پرودن می‌گوید:

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

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

درحالی‌که اپل و مایکروسافت همه‌ی تلاش خود را برای جذب توسعه‌دهنده‌ها به ساخت اپلیکیشن‌های اختصاصی دسکتاپ انجام می‌دهند، گوگل رویکردی متفاوت با انگیزه‌های مالی متفاوت در نظر دارد. گوگل در اکوسیستم کروم‌بوک خود تلاش می‌کند تا تجربه‌ای مبتنی بر اپلیکیشن‌های وب به کاربر ارائه دهد. درمقابل اپل همیشه به رویکرد اپلیکیشن‌های اختصاصی پایبند بوده است. اکنون چرا توسعه‌دهنده‌های اپل باید به‌جای توسعه‌ی نسخه‌های وب اپلیکیشن خود (و دسترسی از کروم یا سافاری)، راضی به پورت کردن نرم‌‌‌‌افزارها از آیپد به مک شوند؟

بنجامین در پاسخ به ابهام بالا همه‌چیز را وابسته به کارایی و قدرت اپلیکیشن می‌داند. او می‌گوید قطعا اپلیکیشن‌های اختصاصی کارایی بیشتری نسبت به تجربه‌ی وب به کاربران ارائه می‌کنند. به‌علاوه از نظر او تجربه‌‌ی کاربران نیز در زمان جابه‌جایی بین دستگاه‌ها مشابه خواهد بود.

شیمانو از تیم تریپ‌ایت درباره‌ی تجربه‌ی استفاده از وب نظری مشابه با مدیران اپل دارد. او اعتقاد دارد واکنش‌های اپلیکیشنی که به‌صورت بومی (Native) در سیستم‌عامل اجرا شود، بسیار سریع‌تر و بهتر از نسخه‌ب وب خواهد بود. شیمانو درباره‌ی تجربه‌ی کاربران هم نظر مشابهی می‌دهد:

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

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

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

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

پرودن در پاسخ به سؤال‌های بالا تأکید می‌کند که سیستم‌عامل‌های گوناگون، کاربردهای متفاوت دارند و درنهایت نمی‌توان هیچ‌کدام را برای توسعه‌دهنده‌ها حیاتی‌تر از دیگری دانست:

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

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

کاتالیست تنها رونمایی بزرگ اپل در WWDC نبود. همان‌طور که گفته شد سویفت‌یوآی هم بخش اعظمی از اخبار را به خود اختصاص داد و به‌عنوان «ابزاری برای طراحی و آماده‌سازی رابط کاربری اپلیکیشن برای همه‌ی پلتفرم‌ها» معرفی شد. ابزار جدید از Xcode و زبان برنامه‌نویسی سویفت استفاده می‌کند.

در سند پشتیبانی اپل برای سویفت‌یوآی می‌خوانیم:

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

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

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

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

سند اپل پیرامون ابزارهای جدید درباره‌ی هماهنگی سویفت‌یوآی و ابزارهای دیگر اپل می‌گوید که می‌توان پنجره‌های سویفت‌یوآی را با اشیاء موجود در فریمورک‌‌های UIKit، AppKit، WatchKit هماهنگ کرد تا از کاربردهای اختصاصی منحصر به پلتفرم هرکدام بهره‌برداری داشت.

من در تاریخ ۱۵ ژانویه‌ی ۲۰۱۹، همه‌ی ۱۱۰ اپلیکیشن برتر رایگان اپ استور را دانلود کردم. سپس اپلیکیشن‌ها را کدگشایی و از ابزاری برای تحلیل محتوای آن‌ها استفاده کردم. هدف نهایی، شناسایی مقدار استفاده از سویفت در کدهای اپلیکیشن‌ بود.برای آن که اپلیکیشنی را متشکل از کدهای سویفت بدانیم، باید در پوشه‌ی فریمورک‌ها یآن فایلی به‌نام libswiftCore.dylib وجود داشته باشد. به‌علاوه در اجرا‌کننده‌ی اصلی آن باید یه کلاس سویفت سازگار با Objective-C دیده شود. برخی اپلیکیشن‌ها لزوما از سویفت در اجرا کننده‌ی اصلی استفاده نمی‌کنند، اما از فریمورک‌های متصل به هم بهره می‌برند که سویفت در آن‌ها نقش دارد.

مدسن متوجه شد که ۴۲ درصد از اپلیکیشن‌های مورد بررسی از سویفت استفاده کرده‌اند. البته پس از حذف بازی‌ها از فهرست، نرخ به ۵۷ درصد رسید. درواقع هیچ‌یک از بازی‌های فهرست از سویفت استفاده نکرده بود و ابزارهای چندپلتفرمی همچون Unity برای توسعه‌ی آن‌ها به‌کار گرفته شد. به‌علاوه همان‌طور که پرودن توضیح داد، بسیاری از کاربران سویفت آن را به‌صورت پیوسته با کد Objective-C به‌کار گرفتند.

مدسن در پایان بررسی خود نتیجه گرفت:

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

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

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

اوبراین توسعه‌دهنده‌ی توییتر درباره‌ی استفاده از سویفت‌یوآی می‌گوید:

ما اکنون تلاش می‌کنیم تا مجموعه کدهای عظیم خود را که شامل طراحی‌های متعدد UIKit هستند، به مک منتقل کنیم. پروژه‌ی کاتالیست در مرحله‌ی کنونی مزایای زیادی برای ما دارد.تیم توییتر درباره‌ی امکانات و قابلیت‌هایی که SwiftUI ارائه‌ می‌کند بسیار هیجان‌زده است و شرکت ما قطعا نظر مثبتی درباره‌ی استفاده از آن در توسعه‌ی قابلیت‌های آتی دارد.

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

• ابتدا اپلیکیشن iOS/iPadOS با اسنتفاده از UIKit ساخته شود. سپس با استفاده از کاتالیست آن را به اپلیکیشن مک تبدیل می‌کنند. طبق پیشنهاد اپل، این روش برای اپلیکیشن‌های متمرکز بر وظایف خاص پیشنهاد می‌شود که در فضای موبایل شناخته‌شده بوده‌اند و در دسکتاپ حضور نداشتند.
• توسعه‌ی اپلیکیشن از ابتدا توسط AppKit و فریمورک‌ها و APIهای اختصاصی انجام شود که منجر به استفاده از کل ظرفیت پلتفرم خواهد شد. اپل می‌گوید این روش برای توسعه‌ی اپلیکیشن‌های سنتی با ظرفیت‌ها و کارایی‌های بسیار بالا مناسب خواهد بود.
• ساخت اپلیکیشن از ابتدا با هدف توسعه برای چند پلتفرم که با SwiftUI انجام می‌شود. اپل انتظار دارد تا توسعه‌دهنده‌ها برای ساخت اپلیکیشن‌های چندپلتفرمی از این روش استفاده کنند.

مجددا یادآور می‌شویم که برخی کاربران تصور می‌کنند اپل iOS را به‌عنوان ستاره‌ی اکوسیستم خود در نظر گرفته است. از نظر آن‌ها مک به‌مرور به عضوی علی‌البدل در اکوسیستم تبدیل خواهد شد. البته برای موفقیت همه‌ی سیستم‌عامل‌ها اعم از iOS، iPadOS، watchOS و tvOS، مک هم باید موفقیت‌هایی را تجربه کند. کاتالیست را می‌توان تلاشی برای پیشرفت مک در عین حفظ هماهنگی آن با پلتفرم‌های موبایل دانست. البته هنوز برای پیش‌بینی موفقیت و ادامه‌ی راه پروژه زود است. درواقع فاکتورهای زیادی باید محقق شوند تا انتظارات همه اعم از اپل، توسعه‌دهنده‌ها و کاربران فراهم شود.

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

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