Google Play နှင့် Apple App Store

နားလည်ထားရမယ့် အချက်

Google Play နဲ့ Apple App Store ဟာ လုပ်ငန်းစဉ် မတူညီပေမယ့် ပုံစံအနေနဲ့ တစ်ခုကို လေ့လာထားရင် တခြားတစ်ခုရဲ့ အများစုကို သင်ယူပြီးသားပါပဲ။ နှစ်ခုစလုံး platform ကိုယ်ပိုင် console ကနေ upload လုပ်တဲ့ signed build တစ်ခုကနေ စတင်ပါတယ်။

• App name နှင့် description
• Icon နှင့် screenshot
• Category
• data ဘာတွေကောက်ယူပြီး ဘာကြောင့်လဲ ဖော်ပြတဲ့ Privacy information
• Support contact
• Release notes

platform နှစ်ခုစလုံးက public release မလုပ်ခင် staged testing ကို ကမ်းလှမ်းပေမယ့် terminology ကွာဟပါတယ်။ Google Play က tester တွေကို internal, closed, open testing track တွေအဖြစ် စီစဉ်ပြီး Apple ရဲ့ equivalent ကတော့ invited tester တွေဆီ pre-release build ဖြန့်ဝေတဲ့ TestFlight ပါ။

store တစ်ခုခုမှာ approval ဟာ automatic မဟုတ်သလို သတ်မှတ်ထားတဲ့ timeline အတိအကျမှာ အာမခံချက် မရှိပါဘူး၊ platform နှစ်ခုစလုံးက guideline တွေကို ပုံမှန်ပြင်ဆင်ကြပါတယ်။ platform တစ်ခုမှ ရိုးရှင်းစွာ 'ပိုကောင်း' တယ်လို့ မရှိပါဘူး - ဒါက distribution problem တစ်ခုတည်းကို ဖြေရှင်းနေတဲ့ လုပ်ငန်းစဉ်နှစ်ခုပါပဲ။

TWO STORE RELEASE FLOWS
-----------------------
TWO STORE RELEASE FLOWS
-------------------------
GOOGLE PLAY
  Build -> Sign -> Upload AAB -> Automated Checks
        -> Testing Track -> Review -> Staged Rollout

APP STORE
  Build -> Sign -> Upload -> App Info -> TestFlight
        -> Review -> Release

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

console နှစ်ခုစလုံးကို မထိခင် store listing asset တွေကို build ပြီးမှ အလျင်စလို ထည့်တဲ့ item မဟုတ်ဘဲ ကိုယ်ပိုင် checklist item အဖြစ် စုစည်းပါ။

• app အမှန်တကယ်လုပ်ဆောင်ချက်နဲ့ ကိုက်ညီတဲ့ description။
• store တစ်ခုချင်းလိုအပ်တဲ့ size အလိုက် icon။
• version သုံးလေးခုကျော်ခဲ့ပြီးသား ဟောင်းနေတာမဟုတ်ဘဲ လက်ရှိ screenshot။
• ရိုးသားတဲ့ privacy disclosure နှင့် အလုပ်လုပ်တဲ့ support contact။

target release date မတိုင်ခင် testing track တွေအတွက် calendar time အစစ် ခွဲထားပါ - deadline နီးလို့ production ကို တိုက်ရိုက်ရှောင်ကျော်တာက ရှောင်လို့ရတဲ့ one-star review ကို ဖြစ်စေတတ်ပါတယ်။

architecture က support လုပ်နိုင်ရင် risky တစ်ခုခုအတွက် platform နှစ်ခုစလုံးမှာ staged rollout ကို သုံးပါ - အမှားတစ်ခုက user အားလုံးမဟုတ်ဘဲ အစိတ်အပိုင်းတစ်ခုပဲ ထိရောက်ပြီး ရပ်တန့်နိုင်ဖို့ပါ။

• Google Play နဲ့ App Store နှစ်ခုစလုံးမှာ release မလုပ်ခင် signed build၊ complete store listing၊ staged testing၊ review လုပ်ငန်းစဉ် လိုအပ်ပါတယ်။
• testing track (Google Play) နဲ့ TestFlight (Apple) ဟာ problem တူတူကို ဖြေရှင်းပေးပါတယ် - public မမြင်ခင် build ကို အသုံးချစမ်းသပ်ခြင်းပါ။
• လက်ရှိ fee၊ review ကြာချိန်၊ console UI position တွေကို planning ထဲ hardcode လုံးဝမလုပ်ပါနဲ့ - store နှစ်ခုစလုံးက ဒါတွေကို မကြာခဏ ပြောင်းလဲပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

function evaluateReleaseReadiness(app) {
  const missing = [];
  if (!app.hasSignedBuild) missing.push("signed build");
  if (!app.hasStoreListingComplete) missing.push("complete store listing");
  if (!app.hasPrivacyDisclosures) missing.push("privacy disclosures");
  if (!app.hasCompletedTesting) missing.push("completed testing round");
  return { ready: missing.length === 0, missing };
}

const notReady = {
  hasSignedBuild: true,
  hasStoreListingComplete: false,
  hasPrivacyDisclosures: false,
  hasCompletedTesting: true
};

const ready = {
  hasSignedBuild: true,
  hasStoreListingComplete: true,
  hasPrivacyDisclosures: true,
  hasCompletedTesting: true
};

console.log("Not ready app:", evaluateReleaseReadiness(notReady));
console.log("Ready app:", evaluateReleaseReadiness(ready));

not-ready app က { ready: false, missing: [ 'complete store listing', 'privacy disclosures' ] } ကို ပြန်ပေးပြီး ready app ကတော့ { ready: true, missing: [] } ဖြစ်ပါတယ်။

App store - Wikipedia — How Mobile Apps Work