Release App Store և Google Play

01Տարբերակավորում՝ version name ընդդեմ build number-ի

Յուրաքանչյուր build ունի երկու թիվ։ Օգտատիրոջը տեսանելի տարբերակը (iOS CFBundleShortVersionString, Android versionName) հետևում է semantic versioning-ին՝ 2.4.0 ֆունկցիոնալ release-ի համար, 2.4.1՝ ուղղման համար։ Build number-ը (iOS CFBundleVersion, Android versionCode) store-երի համար է և պետք է միշտ աճի․ Google Play-ը մերժում է versionCode, որն արդեն տեսել է, իսկ App Store Connect-ին պետք է եզակի build number յուրաքանչյուր տարբերակի համար։ Պահեք ճշմարտության մեկ աղբյուր և թողեք, որ CI-ը մեծացնի build number-ը, օրինակ՝ pipeline-ի run number-ից։ Git commit-ը tag արեք տարբերակով, որպեսզի միշտ կարողանաք վերակառուցել store-ում եղածը։ Հիշեք նաև, որ OTA թարմացումները (եթե օգտագործում եք դրանք) պետք է կապված լինեն runtime version-ի հետ, որպեսզի JavaScript թարմացումը երբեք չընկնի այլ native կոդով binary-ի վրա։

1// android/app/build.gradle
2android {
3  defaultConfig {
4    versionCode 2041      // integer, must always increase
5    versionName "2.4.1"   // shown to users
6    targetSdk 36          // Play: API 36 for new apps and updates from Aug 31, 2026
7  }
8}
9// iOS (Xcode build settings):
10// MARKETING_VERSION = 2.4.1       -> CFBundleShortVersionString
11// CURRENT_PROJECT_VERSION = 2041  -> CFBundleVersion

02Signing՝ iOS certificate-ներ և profile-ներ, Android keystore-ներ

Signing-ը ապացուցում է, որ build-ը ձեզնից է և չի փոփոխվել։ iOS-ում ձեզ պետք է Apple Developer Program-ի անդամակցություն, App ID (bundle identifier), distribution certificate (private key-ը ձեր keychain-ում կամ CI-ում) և provisioning profile, որը կապում է certificate-ը, App ID-ն և capability-ները (push, Sign in with Apple, associated domains)։ Xcode-ի automatic signing-ն աշխատում է փոքր թիմերի համար․ CI-ը սովորաբար օգտագործում է fastlane match կամ EAS credentials՝ դրանք անվտանգ կիսելու համար։ Android-ում ստորագրում եք upload key-ով keystore ֆայլից․ Play App Signing-ով (պարտադիր նոր հավելվածների համար, որոնք release են արվում որպես AAB bundle-ներ) Google-ը պահում է իրական app signing key-ը և վերաստորագրում։ Եթե կորցնեք upload key-ը, կարող եք reset խնդրել․ առանց Play App Signing-ի կորցրած key-ը նշանակում էր, որ երբեք չէիք կարող թարմացնել հավելվածը։ Երբեք keystore-ներ կամ գաղտնաբառեր commit մի արեք git-ում․ պահեք դրանք secrets manager-ում կամ CI secrets-ում։

1# Create an Android upload key (keep the file and passwords in a secret store)
2keytool -genkeypair -v -keystore upload-key.jks -alias upload \
3  -keyalg RSA -keysize 2048 -validity 10000
4 
5# Build a signed Android App Bundle
6cd android && ./gradlew bundleRelease
7 
8# iOS: archive and upload with fastlane (certificates via match)
9bundle exec fastlane ios beta

03Թեստային track-եր՝ TestFlight և Play testing

Երբեք production մի ուղարկեք build, որը իրական մարդիկ չեն տեղադրել store-ի սեփական pipeline-ից։ iOS-ում վերբեռնեք App Store Connect և օգտագործեք TestFlight․ ներքին թեստավորողները (ձեր թիմի անդամները) build-երը ստանում են գրեթե անմիջապես, արտաքին թեստավորողների համար (մինչև 10,000՝ email-ով կամ հանրային հղումով) տարբերակի առաջին build-ը կարճ beta review է պահանջում։ Build-երի ժամկետը լրանում է 90 օր հետո։ Android-ում Play Console-ն ունի internal testing (արագ, մինչև 100 թեստավորող), closed testing (ցուցակներ կամ խմբեր) և open testing։ Նշում՝ նոր անհատական developer հաշիվները պետք է անցկացնեն closed test առնվազն 12 թեստավորողով, որոնք opt-in են արել 14 անընդմեջ օր, նախքան production հասանելիության դիմելը․ կազմակերպությունների հաշիվները ազատված են։ Թեստավորեք release build-ը, ոչ միայն debug-ը․ minification-ը, signing-ը, push-ը և deep link-երը հաճախ այլ կերպ են վարվում։

• Թեստավորեք upgrade-ը store-ի նախորդ տարբերակից, ոչ միայն մաքուր տեղադրումները
• Release build-ում ստուգեք push-ը, deep link-երը, վճարումները և sign-in-ը
• Պատրաստ պահեք review/demo հաշիվ՝ օրինակ տվյալներով

04Store listing-ներ և գաղտնիության տեղեկատվություն

Listing-ը վաճառում է հավելվածը և նաև ներկայացնում փաստեր, որոնք store-երը ստուգում են։ Ձեզ պետք են անուն, subtitle/կարճ նկարագրություն, նկարագրություն, keyword-եր (iOS), screenshot-ներ պահանջվող սարքերի չափսերի համար, icon, կատեգորիա, տարիքային վարկանիշի հարցաթերթիկ, support URL և privacy policy URL։ Երկու store-երն էլ պահանջում են գաղտնիության բացահայտումներ․ Apple-ի App Privacy «nutrition labels»-ը և Google Play-ի Data safety ձևը պետք է համապատասխանեն նրան, ինչ իրականում հավաքում են հավելվածը և դրա SDK-ները (analytics, crash reporting, վճարումներ)։ iOS-ում հավելվածները և third-party SDK-ները պետք է ներառեն privacy manifest-ներ, որոնք հայտարարում են տվյալների օգտագործումը և «required reason» API-ները։ Եթե հավելվածը հետևում է օգտատերերին այլ ընկերությունների հավելվածներում կամ կայքերում, պետք է օգտագործեք App Tracking Transparency։ Listing-ները տեղայնացրեք յուրաքանչյուր թիրախային շուկայի համար։ Screenshot-ները պատրաստեք իրական build-ից՝ իրատեսական, ոչ անձնական demo տվյալներով։

05Review-ի կանոններ և տարածված մերժումներ

Apple-ը յուրաքանչյուր տարբերակ review է անում App Review Guidelines-ի համաձայն, Google-ը համակցում է ավտոմատ ստուգումները policy review-ի հետ։ Մերժումների մեծ մասը կանխատեսելի է։ Crash-եր կամ կոտրված flow-եր review-ի ժամանակ։ Բացակայող demo հաշիվ կամ login պատ, որը review-ողները չեն կարող անցնել։ Հաշվի ստեղծում առանց հավելվածի ներսում հաշվի ջնջման (Apple-ը դա պահանջում է)։ Third-party social login առանց համարժեք, գաղտնիության վրա կենտրոնացած տարբերակի, ինչպիսին է Sign in with Apple-ը։ Թվային ապրանքների կամ բաժանորդագրությունների վաճառք in-app purchase-ից դուրս, որտեղ այն պահանջվում է (ֆիզիկական ապրանքները և իրական աշխարհի ծառայությունները, օրինակ՝ սննդի պատվերները, օգտագործում են սովորական վճարային պրովայդերներ)։ Թույլտվության prompt-եր՝ առանց հստակ purpose string-ների։ Placeholder կոնտենտ, կոտրված հղումներ կամ հավելված, որը պարզապես կայքի wrapper է։ Գաղտնիության label-ներ, որոնք չեն համապատասխանում SDK-ներին։ Resolution Center-ում պատասխանեք հանգիստ և կոնկրետ․ շատ մերժումներ լուծվում են բացատրությամբ կամ կարճ տեսանյութով։

• Տրամադրեք աշխատող demo հաշիվ և նշումներ review-ողի համար
• Առաջարկեք հաշվի ջնջում հավելվածի ներսում, երբ օգտատերերը կարող են հաշիվներ ստեղծել
• Գրեք կոնկրետ թույլտվությունների purpose string-ներ (տեսախցիկ, location, լուսանկարներ)
• Store build-երը պահեք ընթացիկ SDK-ների վրա․ Apple-ը և Google-ը ամեն տարի բարձրացնում են նվազագույնները

06Staged rollout-ներ, hotfix-եր և OTA թարմացումներ

Մի release արեք միանգամից 100%-ի համար։ iOS-ում Phased Release-ը ավտոմատ թարմացումները բաշխում է յոթ օրվա ընթացքում (1%, 2%, 5%, 10%, 20%, 50%, 100%) և կարող է դադարեցվել․ օգտատերերը դեռ կարող են թարմացնել ձեռքով։ Google Play-ում staged rollout-ը թույլ է տալիս ընտրել տոկոս և մեծացնել այն, կամ կանգնեցնել այն, եթե Crashlytics-ը թռիչք է ցույց տալիս։ Յուրաքանչյուր քայլից առաջ հետևեք crash-free users-ին, հիմնական funnel-ներին և support-ի հաղորդագրություններին։ Արտակարգ իրավիճակների համար ունեցեք hotfix branch և expedited review-ի հարցումներ (օգտագործեք խնայողաբար), ինչպես նաև ձեր Remote Config kill-switch-երը։ OTA թարմացումները (EAS Update կամ self-hosted համարժեքներ․ Microsoft-ի CodePush ծառայությունը դադարեցվեց App Center-ի հետ 2025-ին) փոխարինում են JavaScript bundle-ը և asset-ները՝ առանց store review-ի։ Դրանք հիանալի են փոքր ուղղումների համար, բայց չեն կարող փոխել native կոդը, պետք է համապատասխանեն binary-ի runtime version-ին և չպետք է փոխեն հավելվածի հիմնական նպատակը․ store-ի կանոնները դեռ գործում են։ OTA թարմացումներն էլ rollout արեք աստիճանաբար։

07CI pipeline, որը build է անում, ստորագրում և upload անում

Ձեռքով release-ները ձախողվում են ձանձրալի ձևերով՝ սխալ scheme, մեկ laptop-ի վրա ժամկետանց certificate, մոռացված build number։ Ամբողջ ճանապարհը տեղափոխեք CI։ iOS-ի համար fastlane match-ը certificate-ներն ու profile-ները պահում է encrypt արված private storage repository-ում, և CI-ն դրանք քաշում է read-only․ App Store Connect API key-ը փոխարինում է անձնական Apple ID login-ներին և two-factor prompt-երին։ Android-ի համար CI-ն upload keystore-ը decode է անում secret-ից, build է անում AAB-ը և upload անում internal track։ Build number-ները գալիս են pipeline-ի run number-ից, commit-ը tag է արվում, և job-ը պահում է build artifact-ները և symbol ֆայլերը։ Մարդիկ պահում են այն որոշումները, որոնք դատողություն են պահանջում՝ production-ի promote և rollout-ի տոկոսների ավելացում, իսկ մեքենաներն անում են յուրաքանչյուր կրկնվող քայլ։

1# fastlane/Fastfile
2platform :ios do
3  lane :beta do
4    setup_ci
5    app_store_connect_api_key(key_id: ENV["ASC_KEY_ID"], issuer_id: ENV["ASC_ISSUER_ID"],
6                              key_content: ENV["ASC_KEY_P8"])
7    match(type: "appstore", readonly: true)
8    increment_build_number(build_number: ENV["CI_RUN_NUMBER"])
9    build_app(scheme: "MyApp", export_method: "app-store")
10    upload_to_testflight(skip_waiting_for_build_processing: true)
11  end
12end
13 
14platform :android do
15  lane :internal do
16    gradle(task: "bundle", build_type: "Release", project_dir: "android")
17    upload_to_play_store(track: "internal", aab: lane_context[SharedValues::GRADLE_AAB_OUTPUT_PATH])
18  end
19end

08Պլատֆորմի պահանջները փոխվում են ամեն տարի

Երկու store-երն էլ իրենց նվազագույն պահանջները բարձրացնում են տարեկան ռիթմով, և release-ը կարող է արգելափակվել մի կանոնով, որը ոչ մի կապ չունի ձեր feature-ի հետ։ Apple․ 2026 թվականի ապրիլի 28-ից App Store Connect-ն ընդունում է միայն Xcode 26-ով և iOS 26 SDK-ով կամ ավելի նորով արված build-եր․ privacy manifest-ները և զգայուն API-ների համար հայտարարված պատճառները ստուգվում են upload-ի ժամանակ։ Google․ 2026 թվականի օգոստոսի 31-ից նոր հավելվածները և update-ները պետք է target անեն API 36, իսկ Android 15 կամ ավելի բարձր target անող հավելվածները պետք է աջակցեն 16 KB memory page size-երին, ինչը նշանակում է, որ native գրադարանները, ներառյալ React Native dependency-ների ներսում եղածները, պետք է build արված լինեն դրա համար։ Ամեն տարի պլանավորեք upgrade-ի ֆիքսված պատուհան (Xcode, Android Gradle Plugin, React Native, SDK-ներ), այլ ոչ թե կանոնը բացահայտեք հրատապ hotfix-ի ժամանակ, և բաժանորդագրվեք Apple-ի և Google-ի developer news-ին։

09Ինչ են անում store-երը ձեր binary-ի հետ

Android-ում դուք upload եք անում App Bundle, ոչ թե APK։ Google Play-ը այն բաժանում է APK-ների՝ ըստ սարքի կոնֆիգուրացիայի՝ CPU architecture, screen density, լեզու, և ստորագրում app signing key-ով, որպեսզի օգտատերերը ներբեռնեն միայն այն, ինչ պետք է իրենց սարքին։ bundletool-ը թույլ է տալիս լոկալ վերարտադրել այդ APK-ները՝ ճշգրիտ թեստավորելու համար, թե ինչ կտեղադրեր սարքը։ iOS-ում App Store Connect-ը մշակում է upload-ը, և App Thinning-ը ստեղծում է սարքին հատուկ variant-ներ․ App Store Connect-ի size report-ը ցույց է տալիս իրական download և install չափերը՝ ըստ սարքի։ Չափը կարևոր է conversion-ի համար, հատկապես mobile data-ի դեպքում․ հետևեք native գրադարաններին, bundle արված font-երին և նկարներին, չօգտագործվող locale-ներին։ Երկու store-երն էլ upload-ի ժամանակ կատարում են ավտոմատ ստուգումներ՝ private API-ի օգտագործում, բացակայող purpose string-եր, privacy manifest-ի խնդիրներ, target SDK, և այդ հաղորդագրությունները գալիս են email-ով, ուստի ինչ-որ մեկը պետք է կարդա դրանք։

1# Reproduce what Play would install on the connected device
2bundletool build-apks --bundle=app-release.aab --output=app.apks --connected-device
3bundletool install-apks --apks=app.apks
4 
5# Check which certificate signed an APK
6apksigner verify --print-certs app.apk
7 
8# Fingerprints of your upload key (needed for API consoles and resets)
9keytool -list -v -keystore upload-key.jks -alias upload

10OTA update-ներ․ runtime version-ներ, channel-ներ և rollback

OTA update-ը անվտանգ է միայն այն դեպքում, եթե հասնում է ճիշտ այն native կոդով binary-ին, որը սպասում է։ EAS Update-ը դրան հետևում է runtime version-ով։ appVersion policy-ն այն կապում է հավելվածի version-ին, ինչը պարզ է, բայց կոտրվում է, եթե ինչ-որ մեկը փոխում է native կոդը՝ առանց version-ը բարձրացնելու․ fingerprint policy-ն hash է անում native project-ը, ուստի ցանկացած native փոփոխություն ավտոմատ ստեղծում է նոր runtime՝ ավելի հաճախակի store build-երի գնով։ Build-երը լսում են channel (production, staging), որը map է արված update-ների branch-ին, ուստի կարող եք update-ը թեստավորել staging build-երի վրա՝ նախքան production-ը դրան ուղղելը։ Rollout արեք աստիճանաբար՝ տոկոսով, հետևեք crash-free users-ին և պահեք rollback-ի ճանապարհ․ նորից publish արեք նախորդ update-ը կամ rollback արեք binary-ի մեջ embed արված update-ին։ Ստորագրեք update-ները (code signing), որպեսզի կոտրված սերվերը չկարողանա push անել կամայական կոդ։

1# app.json (expo): runtime changes whenever native code changes
2# "runtimeVersion": { "policy": "fingerprint" }
3 
4# Publish to 10% of production users first
5eas update --branch production --message "Fix checkout crash" --rollout-percentage 10
6 
7# Increase, finish or revert the rollout
8eas update:edit
9eas update:revert-update-rollout
10 
11# Emergency: send clients back to the code embedded in the binary
12eas update:roll-back-to-embedded