چرا در SwiftUI از استراکچر استفاده می‌کنیم ولی در UIKit از کلاس‌ها؟
در دنیای برنامه‌نویسی iOS، وقتی با SwiftUI کار می‌کنید، بیشتر Viewها به صورت استراکچر (Struct) ساخته می‌شوند. اما در UIKit، اغلب با کلاس‌ها (Class) سروکار داریم (در یک پست در مورد دو تفاوت اصلی class و struct صحبت کردیم) . شاید از خودتان بپرسید چرا؟ بیایید این موضوع را به زبان ساده و با استفاده از مثال‌های کدی بیشتر توضیح دهیم.
چرا در SwiftUI از استراکچر استفاده می‌کنیم؟
معماری متفاوت: SwiftUI یک روش متفاوت برای ساخت رابط کاربری ارائه شده می‌دهد. این روش را Declarative می‌نامند، یعنی شما فقط می‌گویید «چه چیزی» می‌خواهید نشان دهید و سیستم خود را بهینه‌ترین روش را برای انجام این کار پیدا کنید. از آنجایی که استراکچرها Value-Type هستند (یعنی وقتی کپی می‌شوند، یک کپی برای این سریع می‌سازند)، خیلی و سبک هستند و نوع معماری بسیار مناسب‌اند.
بازدهی بالا: در SwiftUI، هر بار که رابط کاربری تغییر می‌کند، یک نسخه جدید از View ساخته می‌شود. چون استراکچرها خیلی سریع کپی می‌شوند، این کار باعث کاهش مصرف حافظه و افزایش سرعت برنامه می‌شود.
ایمنی در برابر تغییرات ناخواسته: چون استراکچرها یک کپی از خودشان ایجاد می‌کنند، هر وقت شما یک استراکچر را به متغیر دیگری اختصاص می‌دهید، تغییرات در متغیر جدید تأثیری روی نسخه اصلی ندارد. این باعث می‌شود برنامه‌های شما ایمن‌تر و کمتر مستعد خطا باشند.
در این مثال، ContentView یک استراکچر است که یک متن ساده را نمایش می‌دهد.
چرا در UIKit از کلاس‌ها استفاده می‌کنیم؟
نیاز به تغییرات پویا: UIKit به شما اجازه می‌دهد که رابط کاربری را به صورت Imperative بسازید، یعنی می‌توانید به طور دقیق «چطور» و «چه زمانی» را مشاهده کنید. کلاس‌ها به عنوان Refrence-Type خیلی برای این نوع تغییرات پویا مناسب‌اند، چون تغییر در یک مرجع باعث تغییر در همه جاهایی می‌شود که به آن مرجع اشاره می‌کنند.
وراثت و قابلیت‌های پیشرفته: کلاس‌ها امکان وراثت (Inheritance) دارند، یعنی می‌توانید یک کلاس پایه داشته باشید و کلاس‌های دیگری بسازید که از آن ارث‌بری کنند. این ویژگی در UIKit بسیار مفید است، چرا که می‌توانید ویژگی‌ها و رفتارهای مشترک بین Viewها را به راحتی به اشتراک بگذارید.
