Why I sincerely think SwiftUI is ready for production

SwiftUI က ready မဖြစ်သေးဘူး။ SwiftUI က production app တွေမှာသုံးဖို့လိုသေးတယ်။ Navigation flow က အခုထိ အဆင်မပြေဖြစ်နေတုန်းဘဲ။ View တွေ reusable လုပ်လို့ရတဲ့ mechanism မရှိသေးဘူး။ ဒီစကားတွေက လွန်ခဲ့တဲ့တစ်နှစ်ခွဲလုံးလုံး ကျွန်တော်ပြောနေခဲ့တဲ့စကားတွေပါ။ ဒါပေမယ့် ပြီးခဲ့တဲ့ ခရစ္စမတ်ရုံးပိတ်ရက်တွေမှာ ကျွန်တော် SwiftUI ကို seriously လုပ်ဖြစ်တယ်။ ကျွန်တော့်အမြင်တွေ ပြောင်းသွားတယ်။ SwiftUI က လိုနေတာမဟုတ်ဘူး။ တစ်ကယ်လိုနေတာ ကျွန်တော်တို့တွေပါ။ ဒီတစ်ခေါက် SwiftUI က တစ်ကယ်ပဲ mature မဖြစ်သေးတာလား ကျွန်တော်တို့ကပဲလိုနေတာလားဆိုတာကို စမ်းစစ်လေ့လာကြည့်ကြပါမယ်။

၁။ UI ရေးရတာ တအားလွယ်တယ်

Flutter ရေးဖူးတယ်ဆို ဒီခံစားချက်ကို သိပါလိမ့်မယ်။ SwiftUI မှာ layout တွေရေးရတာ view တွေရေးရတာ တအားမြန်ပါတယ်။ မလိုအပ်တဲ့ set up တွေ ဘာတစ်ခုမှလုပ်နေစရာမလိုဘူး။ တအား intuitive ဖြစ်တယ်။ Live preview ကလည်း M1 မှာဆိုရင်တော့ ရှယ်ပဲ။ Intel chip တွေမှာတော့ အခုထိတိုင်ပတ်နေသေးတယ် xD ဘယ်လိုဘဲဖြစ်ဖြစ် UIKit ထက်စာရင် UI ရေးရတဲ့နှုန်းက နှစ်ဆနီးပါးမြန်တဲ့အတွက် MVP မြန်မြန်ထွက်တယ်။ Start-up တွေအတွက်ဆို လုံးဝ perfect ဘဲ။

၂။ State management ရေးရတာ သက်သာတယ်

Reactive programming ဘက်ကလာတဲ့သူဆိုရင် state တွေထိန်းရတာ နည်းနည်းလေးမှ မရှုပ်ဘူး။ MVVM နဲ့ရေးရေး Clean နဲ့ရေးရေး TCA(The Composable Architecture by PointFree) ပဲသုံးသုံး code တွေက သူ့အစိတ်အပိုင်းနဲ့သူ သပ်သပ်ရပ်ရပ်ရှိတယ်။ Uni-directional data flow အပြင် bi-directional data flow အတွက် Binding property wrapper တွေသုံးလို့ရတယ်။ Traditional way ကတော့ ကိုယ့်ဘာသာ explicitly observable stream တွေ ရေးပေတော့ဘဲ။ Property wrapper တွေ မှတ်ရတာရှိပေမယ့် ဒါကအလေ့အကျင့်ပါဘဲ။ အသစ်မလေ့လာချင်ရင် developer အဖြစ်အမြဲရပ်တည်နိုင်ဖို့ ဘယ်လွယ်ပါ့မလဲ ဟုတ်တယ်ဟုတ်?

၃။ Animation တွေလုပ်ရတာ မယုံနိုင်လောက်အောင် လွယ်တယ်

ကျွန်တော်ကိုယ်တိုင် traditional way နဲ့ complex animation တွေကို မုန်းလောက်အောင် လုပ်ဖူးတယ်။ CALayer တွေကို animate လုပ်တာ သူ့အောက်က CGContext ထဲဝင်ပြီး vector တွေ draw တာ အများကြီးလုပ်ဖူးတယ်။ ကျွန်တော်မရောက်တာဆိုလို့ ဟိုးအောက်ဆုံးအလွှာက metal ပဲကျန်မယ်ထင်တယ်။ UIKit မှာလည်း ဒီနှစ်ပိုင်းတွေထဲ enhancement မရှိဘူးတော့မဟုတ်ဘူး။ UIViewPropertyAnimator ပေါ်လာပြီးနောက် fraction based animation တွေလုပ်တာ အသက်ရှုချောင်လာတယ်။ CGAffineTransform လိုကောင်မျိုးတွေကြောင့် view transform လုပ်ရတာ တော်တော်အဆင်ပြေတယ်။ ဘယ်လိုဘဲဖြစ်ဖြစ် အဲ့ API တွေအားလုံးက SwiftUI ကို မမီဘူး။ SwiftUI မှာ တအား complext ဖြစ်တဲ့ effect တွေကိုတောင် code အကြောင်းရေနည်းနည်းနဲ့ ရေးနိုင်တယ်။ ဖတ်ရတာလည်း ရှင်းတယ်။ Apple ကလုပ်ပေးတာဖြစ်တဲ့အတွက် utilization factor ကလည်း သူ့ device capability နဲ့ အံကိုက်ဖြစ်အောင်လုပ်ထားမှာဘဲ။

၄။ Gesture တွေ ထည့်ရလွယ်တယ်

ကိုယ့် app ရဲ့ user experience ကို ပိုကောင်းစေချင်ရင် gesture တွေနဲ့ လိုက်ဖက်တဲ့ interaction တွေ ထည့်ပေးဖို့လိုပါတယ်။ ဒီနေရာမှာလည်း SwiftUI က လွယ်လွယ်ကူကူနဲ့ gesture တွေထည့်လို့ရအောင် ပြင်ဆင်ပေးထားပါတယ်။ မလိုအပ်တဲ့ delegate တွေ callback တွေအစား လွယ်ကူရိုးရှင်းတဲ့ closure based APIs တွေနဲ့ ကိုယ်လုပ်ချင်တာကို မြန်မြန်ဆန်ဆန်လုပ်လို့ရပါတယ်။

၅။ Custom tab bar တွေရေးလို့ရတယ်

UIKit နဲ့ ကျွန်တော် custom tab bar နှစ်ကြိမ်လောက်ရေးဖူးပါတယ်။ တော်တော်လေး လက်ပေါက်ကပ်ပါတယ်။ Apple က သူ့ရဲ့ native tab bar style ကို များများစားစား customize လုပ်ခွင့်မပေးပါဘူး။ လုပ်ချင်ရင် tab bar ကို hidden ထားပြီးတော့မှ သူ့ရဲ့ tab bar controller ကို extend လုပ်ပြီး ကိုယ့် custom tab view သူ့ tab bar ပေါ်မှာအုပ်ပြီးပြ ပြီးရင် tab index တွေကို ကိုယ့်ဘာသာ simulate ပြန်လုပ် အင်မတန် လက်ဝင်ပါတယ်။ SwiftUI မှာတော့ custom tab bar တွေ ကြိုက်သလောက် complex ဖြစ်ချင်သလောက်ဖြစ်အောင် ရေးလို့ရပါတယ်။

၆။ Future support ကောင်းတယ်

Apple က သိတဲ့အတိုင်း framework တစ်ခု update ဖြစ်ဖို့ တစ်နှစ်ကြာပါတယ်။ ကောင်းသည်ဖြစ်စေ ဆိုးသည်ဖြစ်စေ တစ်နှစ်နေမှ fix ပေးပါတယ်။ ဒါပေမယ့် အဲ့လို တစ်နှစ်တစ်ခါ update လုပ်ပေးလိုက်ရင်လည်း future prove တော်တော်လေးဖြစ်ပါတယ်။ Future အတွက်လည်း တော်တော်လေး promising ဖြစ်ပါတယ်။ ကျွန်တော့်အမြင် နောက်ပိုင်းမှာ SwiftUI update တွေ ပိုများလာဖို့ရှိတယ်။ UIKit က မနှစ်ကအထိ update တွေလုပ်နေသေးပေမယ့် ကြီးကြီးမားမား api အသစ် introduce လုပ်လာတာမျိုးမတွေ့ရဘူး။ တစ်ဖက်က SwiftUI မှာတော့ async image တွေ form တွေ navigation link တွေ စသဖြင့် ကြီးကြီးမားမား အပြောင်းအလဲတွေ အင်တိုက်အားတိုက်လုပ်လာတာ တွေ့ရတယ်။ ဒါကြောင့် အခုအချိန် ကိုယ့်ရဲ့ app ကို SwiftUI ဘက် ပြောင်းနိုင်သမျှပြောင်းထားတာက နောက်ပိုင်း ground breaking technology တွေထွက်လာတဲ့အခါ လိုက်ရပိုလွယ်မယ်လို့ မြင်ပါတယ်။

၇။ Codebase တစ်ခုတည်းနဲ့ universal app တွေရေးလို့ရတယ်

ကိုယ့်ရဲ့ iPhone app ကို iPad ပါ support ပေးချင်ရင် ဒါမှမဟုတ် iPad app ကို iPhone အတွက်ထုတ်ပေးချင်ရင် နောက်ဆုံး Mac app ပါထုတ်ချင်လာရင် SwiftUI နဲ့ရေးထားတဲ့အခါ တအားလွယ်ပါတယ်။ Business logic တွေကိုသာ သေသေချာချာ moduralize လုပ်ထားခဲ့မယ်ဆိုရင် UI လေးပြောင်းလိုက်ရုံနဲ့ မြန်မြန်ဆန်ဆန် platform support တွေ တိုးနိုင်မှာပါ။ UI ကလည်း SwiftUI နဲ့ဖြစ်တဲ့အတွက် မျက်စိနောက်စရာတွေ သိပ်ရှိမှာမဟုတ်ပါဘူး။

၈။ Dependency Injection ကို native level ကနေ ထိန်းပေးထားတယ်

UIKit မှာဆို Swinject တို့လို 3rd party library တွေကိုသုံးပြီး dependency တွေ inject ကြတယ်။ SwiftUI မှာ @Inject တို့ @EnvironmentObject လို property wrapper တွေနဲ့ တော်ရုံတန်ရုံကလောက်တော့ ကိုယ့်ဘာသာ dependency inject လုပ်လို့ရပါတယ်။

၉။ Core Data နဲ့ တွဲသုံးရတာ အရသာရှိတယ်

Core Data ကို ကြိုက်တဲ့သူရှိသလို မုန်းတဲ့သူလည်းရှိတယ်။ ကျွန်တော်အရင်က မုန်းတယ်။ ဒါပေမယ့် SwiftUI နဲ့တွဲသုံးလိုက်တဲ့အခါ မုန်းစရာတစ်ကွယ်မှမရှိတော့ဘူး။ Swift ရဲ့ property wrapper နဲ့ key path နှစ်ခုကိုတွဲသုံးလိုက်တဲ့အခါ အခုနောက်ပိုင်း SwiftUI API တွေက ပြိုင်မြင်းကို အတောင်တပ်ပေးလိုက်သလိုဘဲ။ @FetchRequest နဲ့ data fetch တာတွေ လွယ်လွယ်ကူကူလုပ်လို့ရသလို data change သွားရင်လည်း build in animation လေးနဲ့ပြပေးလို့ရတော့ အတိုင်းထက်အလွန်ပါဘဲ။

၁၀။ လိုအပ်လာရင် UIKit ကိုထည့်သုံးလို့ရတယ်

SwiftUI ချည်းဘဲရေးလို့ရလားဆိုတော့ မရဘူးလို့ဘဲဖြေရပါမယ်။ တစ်ကယ်တန်း ကျွန်တော်တို့ရဲ့ SwiftUI View တွေသည်ပင်လျှင် နောက်ကွယ်မှာ UIHostingController က host လုပ်ပြီး ပြန်ပြပေးနေတာဖြစ်ပါတယ်။ UIImagePickerController လိုကောင်မျိုးတွေမှာ UIKit ကို မဖြစ်မနေသုံးရပါတယ်။ တစ်ခြား SwiftUI မှာမရသေးလို့ UIKit သုံးရမယ်ဆိုလည်း အချိန်မရွေး UIKit ကို အလွယ်တကူရောရေးလို့ရပါတယ်။ ဒီအချက်သည်ပင်လျှင် SwiftUI ကို production မှာ စိတ်ချလက်ချသုံးဖို့ အာမခံချက်ဖြစ်ပါတယ်။ တစ်ကယ်လို့ တစ်နေရာရာမှာ တစ်သွားပြီ SwiftUI မှာ မလုပ်တတ်တော့ဘူးဆိုရင် UIKit ကို ပြန်ပြီး fallback လုပ်လို့ရပါတယ်။ UIViewRepresentable တွေထည့်လိုက်ရုံနဲ့ ပြေလည်သွားမှာပါ။

ဆိုတော့ကာ ပြောရမယ်ဆိုရင် SwiftUI က ready မဖြစ်သေးတာမဟုတ်ဘဲ တစ်ကယ် ready မဖြစ်သေးတာ ကျွန်တော်တို့တွေပါ။ နေ့စဉ် UIKit နဲ့အသားကျနေပြီး daily comfort zone ကနေ ထွက်မကြည့်မိတဲ့အခါ SwiftUI ကို အရင်နှစ်နှစ်ကအတိုင်း ငချွတ်လေးလို့ ထင်ခဲ့ကြတယ်။ အခု အဲ့ငချွတ်လေးက အတောင်ပေါက်နေပါပြီ။

Navigation flow နဲ့ပတ်သက်ပြီး လိုအပ်နေသေးတယ်ဆိုတာတာ့ အမှန်ပါဘဲ။ ဒါပေမယ့် တနင်္လာနေ့ကျရင် နောက်ထပ် API အသစ် ထွက်လာဖို့များပါတယ်။ အခုလောလောဆယ်မှာတော့ navigation တွေက flat မဖြစ်ဘူးဆိုပေမယ့် တစ်ခြား library တွေထည့်သုံးလို့လည်းရပါတယ်။ ယုတ်စွအဆုံး UIKit navigation နဲ့အစားထိုးပြီးတော့တောင် ရေးလို့ရပါသေးတယ်။

ကျွန်တော်အရင်က ဖြစ်ခဲ့တဲ့ concern က Navigation Link နဲ့ပတ်သက်တဲ့ဟာပါ။ ဆိုကြပါစို့။ ကျွန်တော်တို့မှာ LazyVGrid နဲ့ scroll view တစ်ခု set up လုပ်ထားတယ်။ Grid item တွေကိုနှိပ်လိုက်ရင် detail page ပွင့်မယ်ပေါ့။ အဲ့တော့ကာ lazy ဖြစ်သည့်တိုင် ကျွန်တော်တို့ list မှာ item အခု ၁၀၀ ရှိရင် detail instance ကလည်း အခု ၁၀၀ နောက်ကွယ်မှာဆောက်နေမှာပါဘဲ။ ဒီတော့ ကျွန်တော်တို့က performance ထိမလား စိတ်ပူကြပါတယ်။ ကျွန်တော်ကိုယ်တိုင်လည်း အဲ့လိုတွေးခဲ့ပါတယ်။ ဒါပေမယ့် instrument သုံးပြီး သေသေချာချာစမ်းကြည့်တဲ့အခါ ကျွန်တော်တို့ထင်သလောက် performance ကြီးကြီးမားမားထိခိုက်သွားတာ မတွေ့ရပါဘူး။ စာလိုက်ဖတ်ကြည့်တဲ့အခါ ဘာကြောင့်လဲဆိုတာကို သွားတွေ့ရပါတယ်။

ပထမတစ်ချက်က SwiftUI ရဲ့ view တွေသည် heavy operation တွေကိုဘယ်အချိန်မှာလုပ်သလဲဆိုတော့ “var body: some View {}”ဆိုတဲ့ computed property ကို execute တဲ့အချိန်မှလုပ်ပါတယ်။ တစ်နည်းပြောရရင် init လုပ်တဲ့အချိန်မဟုတ်ဘဲ တစ်ကယ် view appear ဖြစ်တဲ့အချိန်ကိုဆိုလိုတာပါ။ ဒုတိယချက်က struct တွေဖြစ်တဲ့အတွက် value semantic ရဲ့ memory allocation အားသာချက်တွေလည်း ရနေပါတယ်။ နောက်ဆုံး အရေးအကြီးဆုံးကတော့ ကျွန်တော်တို့ဟာ swiftui view တွေရဲ့ init ထဲမှာ ဘယ်တော့မှ expensive computation တွေကို မလုပ်မိစေနဲ့ဆိုတဲ့အချက်ပါဘဲ။ ဒါက SwiftUI မှမဟုတ်ဘဲ ဘယ် API မဆို မလိုအပ်ဘဲ initialize လုပ်တဲ့အချိန်မှာ heavy task တွေ မရေးမိစေဖို့ သတိပြုရမယ့်အချက်ပါ။ ကျွန်တော်တို့က init ထဲမှာ expensive logic တွေမရှိရင် ကျွန်တော်တို့ရဲ့ struct instance အခုတစ်ရာ အခုတစ်ထောင်ရှိနေလည်း ကျွန်တော်တို့က instance အခွံတွေသာရှိပြီး အထဲက logic တွေက lazy loading ဖြစ်နေတဲ့အတွက် app ရဲ့ peformance ကို ဆိုးဆိုးရွားရွားမထိခိုက်စေပါဘူး။ Unlimited scrolling လုပ်မယ်ဆိုရင်တောင် screen glitch အနည်းငယ်ရှိတာကလွဲရင် လုပ်လို့ရပါတယ်။ အခုလက်ရှိ swiftui ရဲ့ navigation အခြေအနေက အကောင်းဆုံးလို့မပြောနိုင်သော်လည်း production မှာ သုံးလို့မရလောက်အောင် စုတ်ပြတ်နေတာမျိုးမဟုတ်ဘူးလို့ ပြောချင်တာပါ။ နောက်ပိုင်း table view တို့ collection view တို့လို resue strategy ရှိရင်တော့ အတိုင်းထက်အလွန်ပါဘဲ။ ဒီနှစ် ပါလာမယ်လို့လည်း အားလုံးက မှန်းထားကြပါတယ်။

ကျွန်တော်ဒီနေ့အဓိကပြောချင်တာက တစ်ကယ်လို့ ကိုယ့်ရဲ့ project မှာ iOS support version ကသာ iOS 14 နဲ့အထက်ရှိမယ်ဆိုရင် SwifUI ကို သုံးသင့်တယ်လို့ ပြောချင်တာပါ။ UIKit ကောင်းတယ် SwiftUI ကောင်းတယ်ဆိုတာထက် နှစ်ခုလုံးက ကောင်းတာတွေကိုယူပြီး ရောစပ်အသုံးပြုရင် ပိုပြီး ကောင်းမွန်တဲ့ ရလဒ်တွေရလာမှာ အမှန်ပါဘဲ။ ရက်ပိုင်းအတွင်း iOS 16 လည်းထွက်လာတော့မှာဆိုတော့ ပုံမှန် support -2 of latest version အရဆိုရင် iOS 14 ကနေစလို့ရပါပြီ။ iOS 13 မှာတော့ SwiftUI ရေးဖို့ ကျွန်တော် recommend မလုပ်ပါဘူး။ ဘာလို့လဲဆိုတော့ iOS 13 ထွက်လာတုန်းက ကျွန်တော်လည်း SwiftUI ပြေးလုပ်ပြီး ပြသနာပေါင်းစုံတက်ခဲ့ဖူးလို့ပါ။ iOS 14 ကတော့ SwiftUI ကို လူလိုသူလို ရေးလို့တစ်ကယ်ကိုရပါပြီ။ ဘာကြောင့်လဲဆိုတော့ ကျွန်တော့် production app တစ်ခုကို iOS 14 မှာ SwiftUI နဲ့ ရေးခဲ့ဖူးလို့ပါ။ ဘာပြသနာမှမကြုံရပါဘူး။

ဒီနေ့ကတော့ စာလည်းရှည်သွားပြီဆိုတော့ ဒီလောက်ပါဘဲ။ Framework အသစ်တွေလေ့လာရတာ beginner ပြန်ဖြစ်သွားသလိုခံစားရတယ်ဆိုပေမယ့် excitement level ကတော့ so high ပါဘဲ။ အားလုံးပဲ SwiftUI ကို လေ့လာချိန်တန်ပါပြီလို့ နှိုးဆော်လိုက်ပါတယ်ခင်ဗျာ။