ဒီအခါမှာ ဈေးကွက်ထဲမှာရှိတဲ့ AI app ဆောက်သူတွေက ပလက်ဖောင်းအားလုံးအတွက် code တွေကို generate လုပ်ကြတယ်။ Bolt, Lovable, Rork ဆိုတဲ့ app တွေက အဓိကအားဖြင့် React Native (ဖုန်းအက်ပ်တည်ဆောက်ရေးစနစ်တစ်ခု) သို့မဟုတ် Expo (ဖုန်းအက်ပ်တည်ဆောက်ရေးစနစ်တစ်ခု) ကို သုံးထုတ်လုပ်ကြတယ်။ ဒါမှမဟုတ် web app တွေကို native ဖုန်းအက်ပ်တစ်ခုအဖြစ် ထည့်သွင်းကြတယ်။

ဒါကြောင့်ပဲ ဒီလိုလုပ်ကြတယ်ဆိုတာ နားလည်ရတယ်။ React က documentation (စာရွက်စာတမ်း) ပိုများတယ်၊ LLM (ကြီးမားတဲ့ ဘာသာစကားစနစ်) အတွက် training data ပိုများတယ်၊ ပလက်ဖောင်းတစ်ခုတည်းမှာ code တွေ ရေးရတာ လွယ်ကူတယ်၊ ဈေးကွက်ထဲကို မြန်မြန်ဝင်နိုင်တယ်။

ဒါပေမဲ့ ဒီလိုဖန်တီးထုတ်လုပ်ထားတဲ့ app တွေက ဆိုးတယ်။

ကျွန်တော်က ဒီလိုတွေ သုံးၿပီး app တစ်ခုလေးကို လုပ်ဖူးတယ်။ ဒါပေမဲ့ ဒီapp ထဲမှာ premium (အဆင့်မြင့်) ၊ native-feeling (ဖုန်းစနစ်နဲ့ကိုက်ညီတဲ့) ဒီဇိုင်းတွေလိုချင်တဲ့အခါ ပြဿနာတက်လာတယ်။ အားလုံးက AI slop (မသန်စွမ်းသေးတဲ့ AI) လိုပဲ ရှိနေတယ်။ လှုပ်ရှားမှုတွေ ပျက်စီးနေတယ်။ ဖုန်းစနစ်နဲ့ကိုက်ညီမှုမရှိဘူး။ App Store မှာ ဒီလိုapp တွေကို အပ်လိုက်ဖို့ ပြင်ဆင်ရတာ ပတ်ရက်ပိုနေတယ်။ Apple က Expo wrappers (web app တွေကို native ဖုန်းအက်ပ်အဖြစ် ထည့်သွင်းထားတာ) ကို မကြိုက်ဘူး။ users (အသုံးပြုသူတွေ) ကလည်း ဒီလိုကွာဟချက်တွေကို မသိပေမဲ့ ခံစားနိုင်ကြတယ်။

ဒါကြောင့်ပဲ ကျွန်တော်က Nativeline (ဖုန်းအက်ပ်တည်ဆောက်ရေးစနစ်တစ်ခု) ကို ဆောက်ဖို့ စတင်တဲ့အခါ အများစုက မမှန်ကန်ဘူးလို့ ပြောတဲ့ ရွေးချယ်မှုတစ်ခုကို လုပ်လိုက်တယ်။ ဒါကတော့ iPhone, iPad, Mac တွေအတွက် real SwiftUI (Apple ရဲ့ app ဆောက်ရေးစနစ်) ကို generate လုပ်တာပါ။ React Native မဟုတ်ဘူး။ web view တွေလည်း မဟုတ်ဘူး။ Xcode (Apple ရဲ့ app ဆောက်ရေးပရိုဂရမ်) မှာ ဖွင့်ရတဲ့ အမှန်တကယ် Swift code တွေကို generate လုပ်တာပါ။

ဒါက အရမ်းခက်ခဲတဲ့ကိစ္စတစ်ခုပါ။ အဓိကပြဿနာက LLM (ကြီးမားတဲ့ ဘာသာစကားစနစ်) တွေက Swift ရဲ့ ပျက်စီးသွားတဲ့ API (အပ်ပလီကေးရှင်းတွေ) တွေ၊ UIKit (ဖုန်းအက်ပ်ဒီဇိုင်းစနစ်တစ်ခု) ရဲ့ ဟောင်းကွဲပုံစံတွေ၊ SwiftUI (Apple ရဲ့ app ဆောက်ရေးစနစ်) ရဲ့ အစပိုင်းကတည်းက code တွေကို သင်ယူထားတာပါ။ ဒီလိုမှားယွင်းတဲ့ code တွေကို generate မလုပ်ဘဲ ဆက်လက်၍ modern (လက်ရှိ) ၊ ဖြူစင်တဲ့ SwiftUI code တွေကို generate လုပ်ဖို့ ကြိုးစားရတာ အရမ်းခက်ခဲတယ်။ ဒါက code တွေ အလုပ်လုပ်ဖို့ပဲ မဟုတ်ဘူး၊ error မရှိဘဲ compile ဖြစ်ဖို့၊ လက်ရှိ convention (စံထားမှုများ) ကို လိုက်နာဖို့၊ ကောင်းမွန်တဲ့ Swift developer တစ်ယောက်ရေးသားတဲ့ code လိုပဲ ရှိဖို့ပါ။

ဒါအပြင် Apple ရဲ့ အသစ်တွေကို ပြန်လည်ထိန်းသိမ်းနိုင်ဖို့ကလည်း ခက်ခဲတယ်။ Liquid Glass (Apple ရဲ့ အသစ်ထွက်ရှိလာတဲ့ framework) ကို ထုတ်လုပ်လိုက်တဲ့အခါ ရှိထားတဲ့ LLM (ကြီးမားတဲ့ ဘာသာစကားစနစ်) တွေက အဲဒီ framework ကို generate လုပ်ဖို့ အဆင်မပြေဘူး။ React Native ကို generate လုပ်တဲ့သူတွေအတွက်တော့ အဲဒါက ပြဿနာတစ်ခုမဟုတ်ဘူး။ ပလက်ဖောင်းပြောင်းလဲမှုတွေကို ဖယ်ရှားထားနိုင်ကြတယ်။ ဒါပေမဲ့ native Swift ကို generate လုပ်တဲ့သူတွေအတွက်တော့ Apple ရဲ့ frameworks တွေနဲ့ ကိုက်ညီဖို့ မလွတ်လပ်ဘူး။ ဒါက အဓိကရည်ရွယ်ချက်ပါပဲ။

ဒီနည်းပညာက အမှန်တကယ် ကောင်းကျိုးပေးတာကို ရရှိပြီ - သင့်ကိုယ်သင်ပိုင်ဆိုင်တဲ့ SwiftUI ကုဒ်ကို ထုတ်လုပ်ပေးတယ်။ ဒါကြောင့် သင့်ကွန်ပျူတာမှာ Xcode ပရောဂျက်တစ်ခု ရှိနေတယ်။ အသုံးပြုသူတစ်ဦးက Mac app တစ်ခု အကြံပေးခဲ့ပြီး ၆ ရက်ကြာအတွင်း တိုးတက်လာတာကို ကြည့်ရတယ်။ ဒီလူက Swift ကုဒ်ရေးတာ မဟုတ်ခဲ့ပေမယ့် ကုဒ်က သန့်ရှင်းလောက်တယ်လို့ ပြောတယ်။

ဒါပေမယ့် ကျွန်တော်တို့ ဆက်လုပ်နေတာကတော့ - ရှုပ်ထွေးတဲ့ backend integrations ကို လုပ်တာ ခက်ခဲတယ်။ ဒေတာဘေ့စ် ခ်ွနှိုင်းမှု၊ Supabase, CloudKit၊ ဒေတာ ရှင်းလင်းမှု နဲ့ပတ်သက်တာတွေမှာ ကျွန်တော်တို့ အလိုလို့ မလိုချင်တဲ့ အမှားတွေ ဖြစ်တတ်တယ်။ ဒါကြောင့် AI အတွက် ဒေတာဘေ့စ် patterns, သင်တို့ကိုယ်တိုင် စီမံထားတဲ့ backend တွေကို စာရွက်စာတမ်းတွေ ပိုပြီး ရေးသားနေတယ်။ ဒါမှ AI က ဒေတာဘေ့စ် schema configurations ကို မမှားတော့ဘဲ လုပ်ဆောင်နိုင်မှာပါ။

ကျွန်တော်တို့ ထင်တာကတော့ React Native ကို စက်ရုံတွေက ပိုအဆင်ပြေတာကြောင့် အများစုက အသုံးပြုကြတာ။ ဒါပေမယ့် အသုံးပြုသူတွေအတွက် ပိုကောင်းတာက native code ထုတ်လုပ်တာပါ။ ဒါကြောင့် app ကို သုံးတဲ်အခါမှာ ကွာခြားမှု ထင်ရှားတယ်။

Nativeline က စမ်းသပ်ရန် အခမဲ့ပါ - https://nativeline.ai

နည်းပညာ approach, trade-offs, သို့မဟုတ် အခြားတာတွေကို ဆွေးနွေးဖို့ အဆင်သင့်ပါ။