ਪਹਿਲੀ submission ਲਈ Flutter ਰਿਲੀਜ਼ ਤਿਆਰੀ ਚੈੱਕਲਿਸਟ

“ਰਿਲੀਜ਼-ਰੇਡੀ” ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ

“ਰਿਲੀਜ਼-ਰੇਡੀ” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਐਪ ਮੇਰੇ ਫ਼ੋਨ ਤੇ ਚੱਲਦੀ ਹੈ।” ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ production build ਬਣਾਕੇ, ਉਸਨੂੰ ਇੱਕ ਸਾਫ ਡਿਵਾਈਸ 'ਤੇ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਬਿਨਾਂ ਆਖਰੀ ਸਮੇਂ ਦੀਆਂ ਤਕਲੀਫਾਂ ਦੇ store ਨੂੰ submit ਕਰ ਸਕਦੇ ਹੋ।

ਜੋ ਗਲਤ ਹੁੰਦਾ ਹੈ ਪਹਿਲੀ submission ਤੋਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਪਹਿਲਾਂ, ਉਹ ਬਹੁਤ ਆਮ ਪਰ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ: signing keys ਦੀ ਕਮੀ, ਗਲਤੀ nal debug build upload ਹੋ ਜਾਣਾ, crash ਜਿਹੜੇ ਲਾਗ ਨਹੀਂ ਛੱਡਦੇ, permission prompts ਜੋ ਸ਼ੱਕਜਨਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਜਾਂ store assets ਜੋ ਐਪ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਹੀਂ (ਗਲਤ ਆਈਕਾਨ, ਪੁਰਾਣੀਆਂ screenshots, ਗੁੰਮ privacy ਟੈਕਸਟ)।

ਪਹਿਲੀ Flutter submission ਲਈ, “ਰਿਲੀਜ਼-ਰੇਡੀ” ਚਾਰ ਨਤੀਜਿਆਂ 'ਤੇ ਆ ਕੇ ਖਤਮ ਹੁੰਦਾ ਹੈ:

• ਤੁਸੀਂ ਇੱਕ ਦੁਹਰਾਇਆ ਜਾਣ ਵਾਲਾ production build ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋ ਅਤੇ ਉਸ artifact ਨੂੰ ਪਛਾਣ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ submit ਕਰ ਰਹੇ ਹੋ।
• ਤੁਹਾਡੇ signing credentials ਮਾਲਕੀ, ਬੈਕਅੱਪ ਕੀਤੇ ਹੋਏ ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਲੈਪਟੌਪ 'ਤੇ ਫਸੇ ਹੋਏ ਨਹੀਂ ਹਨ।
• ਜੇ ਐਪ field ਵਿੱਚ crash ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨੂੰ ਜਲਦੀ ਵੇਖੋਗੇ ਅਤੇ ਮਸਲੇ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸਮਝਣ ਲਈ ਕਾਫੀ ਵੇਰਵਾ ਮਿਲੇਗਾ।
• ਤੁਹਾਡੀ store listing ਪੂਰੀ ਹੈ: ਟੈਕਸਟ, ਆਈਕਾਨ, ਸਕ੍ਰੀਨਸ਼ਾਟ ਅਤੇ ਜ਼ਰੂਰੀ declarations।

ਇਹ ਲੇਖ ਪਹਿਲੀ submission ਲਈ ਜ਼ਰੂਰੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ: signing, flavors, crash reporting, permission copy ਅਤੇ timing, ਅਤੇ store assets. ਇਹ ਪੂਰਾ QA ਯੋਜਨਾ, performance audit ਜਾਂ ਕਾਨੂੰਨੀ ਸਮੀਖਿਆ ਨਹੀਂ ਹੈ।

ਘੱਟੋ-ਘੱਟ ਕੁਝ ਫੋਕਸਡ ਸੈਸ਼ਨ ਰੱਖੋ। ਇਕਲੌਤਾ ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ 1–2 ਦਿਨਾਂ ਵਿੱਚ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹੈ। ਟੀਮ 'ਤੇ, ਸਪਸ਼ਟ ਮਾਲਿਕ ਨਿਰਧਾਰਤ ਕਰੋ (signing/builds, crash reporting, store listing ਅਤੇ copy) ਤਾਂ ਜੋ ਕੁਝ ਵੀ ਆਖਰੀ ਘੰਟੇ 'ਚ ਫਸ ਕੇ ਨਾ ਰਹਿ ਜਾਵੇ।

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲੇ ਜਿਹੜੇ build ਤੋਂ ਪਹਿਲਾਂ ਲਾਕ ਕਰੋ

ਜ਼ਿਆਦਾਤਰ “ਆਖਰੀ ਸਮੇਂ” ਰਿਲੀਜ਼ ਸਮੱਸਿਆਵਾਂ ਵੋ early decisions ਹਨ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਕੀਤੀਆਂ। ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਹੁਣੇ ਲਾਕ ਕਰੋ, ਅਤੇ ਹੇਠਾਂ ਵਾਲਾ ਸਾਰਾ ਕੰਮ ਅਸਾਨ ਹੋ ਜਾਵੇਗਾ।

ਪہਚਾਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਉ_exact app name ਜੋ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ ਅਤੇ store ਜੋ ਅੰਦਰੂਨੀ IDs ਵਰਤਦਾ ਹੈ (Android ਦਾ package name, iOS ਦਾ bundle identifier). ਦੇਰ ਨਾਲ ਇਨ੍ਹਾਂ ਨੂੰ ਬਦਲਣਾ updates, deep links ਅਤੇ analytics ਇਤਿਹਾਸ ਨੂੰ ਟੁੱਟ ਸਕਦਾ ਹੈ। ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ releases ਨੂੰ ਕਿਵੇਂ version ਕਰੋਗੇ, ਤਾਂ ਜੋ ਹਰ build ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ ਨੰਬਰ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਕਦੇ ਅਫਸੋਸ ਨਾ ਕਰੋ ਕਿ ਕੀ ਲਾਈਵ ਹੈ।

ਫਿਰ platform ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਕਰੋ: Android, iOS, ਜਾਂ ਦੋਹਾਂ day one ਲਈ, ਅਤੇ ਘੱਟੋ-ਘੱਟ OS ਵਰਜਨ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗੀਆਂ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਘੱਟੋ-ਘੱਟਾਂ ਨੂੰ ਦੇਰ ਨਾਲ ਵਧਾਉਣਾ ਡਿਜ਼ਾਇਨ ਬਦਲਾਅ ਜਾਂ ਉਹ ਡਿਵਾਈਸ ਛੱਡ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਮਝਦੇ ਸੀ ਕਿ ਸਮਰਥਿਤ ਹਨ।

ਇਹ ਫੈਸਲੇ ਕਿਸੇ ਥਾਂ ਲਖ ਲਓ ਜਿੱਥੇ ਟੀਮ ਆਸਾਨੀ ਨਾਲ ਵੇਖ ਸਕੇ:

• App name, package/bundle ID, ਅਤੇ ਇੱਕ ਸਾਦਾ versioning rule
• Supported platforms ਅਤੇ minimum OS ਵਰਜਨ
• Environments (dev, staging, production) ਅਤੇ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਉਨ੍ਹਾਂ ਵਿੱਚ ਫਰਕ ਕਰਦੀਆਂ ਹਨ
• final “ship” ਜਾਂ “hold” ਕੌਲ ਦਾ ਮਾਲਿਕ
• Store account access: logins, roles, ਅਤੇ 2FA recovery ਤਰੀਕੇ

ਅਖ਼ੀਰ 'ਚ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੇ store accounts ਮੌਜੂਦ ਹਨ ਅਤੇ ਤੁਸੀਂ publish ਕਰ ਸਕਦੇ ਹੋ। ਕੋਈ ਵੀ account approvals, ਟੈਕਸ ਫਾਰਮਾਂ ਦੀ ਗੈਰ ਮੌਜੂਦਗੀ, ਜਾਂ upload permission ਦੀ कमी ਲਾਂਚ ਰੋਕ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ ਜਾਂ ਹੱਥੋਂ ਕੋਡ ਕਰ ਰਹੇ ਹੋ, ਇਹ ਫੈਸਲੇ ਫਿਰ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

App signing: keys, ownership, ਅਤੇ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ

App signing ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਐਪ ਅਪਡੇਟ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੀ ਆਈ ਹੈ। ਜੇ signing ਗ਼ਲਤ ਹੋਵੇ, store upload reject ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਅੱਗੇ update ਨਹੀਂ ਭੇਜ ਸਕੋਗੇ।

Android 'ਤੇ, signing ਆਮ ਤੌਰ 'ਤੇ upload key ਹੁੰਦੀ ਹੈ ਜੋ keystore ਫਾਇਲ ਵਿੱਚ ਹੁੰਦੀ ਹੈ (ਤੇ ਨਾੜੇ passwords)। iOS 'ਤੇ, ਇਹ certificates ਅਤੇ provisioning profiles ਹੁੰਦੇ ਹਨ ਜੋ Apple Developer account ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਭਾਵੇਂ ਤੁਸੀਂ Koder.ai ਨਾਲ build ਕਰੋ ਅਤੇ source export ਕਰੋ, ਤੁਹਾਨੂੰ ਪਹਿਲੀ submission ਤੋਂ ਪਹਿਲਾਂ store accounts ਅਤੇ signing assets ਦੀ ਸਪੱਸ਼ਟ ਮਲਕੀਅਤ ਚਾਹੀਦੀ ਹੈ।

مالکیت ਅਤੇ ਪਹੁੰਚ ਦਾ ਫੈਸਲਾ ਕਰੋ

ਹਰ platform ਲਈ system-of-record owner ਚੁਣੋ, ਅੱਛਾ ਹੋਵੇ ਤਾਂ company account ਨੁੰ ਪ੍ਰਧਾਨ ਕਰੋ ਨਾ ਕਿ personal account. ਐਕਸੈਸ ਨਿਯਮ ਲਗਾਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਲੈਪਟੌਪ ਜਾਂ ਇਕ ਵਿਅਕਤੀ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ।

ਥੋੜ੍ਹਾ ਰਿਕਾਰਡ ਰੱਖੋ ਜੋ ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹੋਣ:

• ਕਿਹੜੇ accounts signing keys ਦੇ ਮਾਲਕ ਹਨ (Google Play, Apple Developer)
• keystore ਅਤੇ iOS signing ਫਾਇਲਾਂ ਕਿੱਥੇ ਰੱਖੀਆਂ ਹਨ (vault, encrypted storage)
• ਕੌਣ releases ਕੱਟ ਸਕਦਾ ਹੈ ਅਤੇ ਕੌਣ credentials rotate ਕਰ ਸਕਦਾ ਹੈ
• Access recover ਕਰਨ ਦਾ ਤਰੀਕਾ (2FA recovery codes, admin roles)

ਬੈਕਅੱਪ ਅਤੇ “ਖੋਈ ਹੋਈ ਕੁੰਜੀ” ਯੋਜਨਾ

ਇੱਕ ਗੁੰਮ ਹੋਈ Android key ਭਵਿੱਖ ਦੇ updates ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ। ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਬੈਕਅੱਪ ਨੂੰ ਵੱਖਰੀ ਥਾਂ 'ਤੇ ਰੱਖੋ ਅਤੇ ਉਸ ਨੂੰ restore ਕਰ ਕੇ ਟੈਸਟ ਕਰੋ। iOS ਲਈ, access ਖੋ ਜਾਣਾ ਆਮ ਤੌਰ 'ਤੇ account recovery ਦਰਦ ਬਣ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਕਈ ਭਰੋਸੇਯੋਗ admins ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਦਰਜ ਕਰੋ।

ਸਾਫ ਮਸ਼ੀਨ (fresh checkout, ਨਵਾਂ CI runner, ਜਾਂ ਟੀਮ ਮੈਬਰ ਦੀ ਲੈਪਟੌਪ) 'ਤੇ signing ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਇਹ ਸਿਰਫ ਇੱਕ ਕੰਪਿਊਟਰ 'ਤੇ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਤਿਆਰ ਨਹੀਂ ਹੈ।

Build flavors: dev ਅਤੇ production ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ

Flavors ਇਹ ਰੋਕਦੇ ਹਨ ਕਿ “ਮੇਰੇ ਫ਼ੋਨ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਬਦਲੇ “ਅਸੀਂ test server ਭੇਜ ਦਿੱਤਾ” ਵਿੱਚ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇੱਕ flavor ਇੱਕ ਨਾਂ ਵਾਲੀ build ਹੁੰਦੀ ਹੈ ਜੋ ਵੱਖਰੀ configuration ਵਰਤਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਫਾਇਲਾਂ ਸੋਧਣ ਦੇ।

ਅਧਿਕਤਮ ਟੀਮਾਂ ਵਾਸਤੇ ਦੋ flavors ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: dev (ਟੈਸਟ ਲਈ) ਅਤੇ prod (ਜੋ ਤੁਸੀਂ submit ਕਰਦੇ ਹੋ). ਜੇ ਤੁਹਾਡੀ ਟੀਮ “staging” ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਉਹ ਵਰਤੋ। ਗੁੰਝਲਦਾਰ ਨਾਵਾਂ ਗਲਤ build ਦੇแชร์ ਹੋਣ ਜਾਂ upload ਹੋਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ।

ਫਲਾਵਰਾਂ ਵਿੱਚ ਕੀ ਫਰਕ ਹੋਵੇਗਾ ਇਹ ਲਾਕ ਕਰੋ। ਆਮ ਤੌਰ 'ਤੇ ਫਰਕ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ: app identity (name ਅਤੇ bundle ID), ਆਈਕਾਨ, API endpoints, feature flags, analytics/crash reporting settings, ਤੇ logging level.

ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲ repo ਵਿੱਚ ਨਾ ਰੱਖੋ ਜੇ ਸੰਭਵ ਹੋਵੇ। environment files, CI secrets ਜਾਂ build-time variables ਵਰਤੋ ਤਾਂ ਜੋ ਚਾਬੀਆਂ commits ਵਿੱਚ ਨਾ ਚਲੀ ਜਾਣ।

ਅਖੀਰ 'ਤੇ, ਹਰ ਉਸ flavor ਨੂੰ build ਕਰੋ ਜੋ ਤੁਸੀਂ ਵਰਤਣ ਜਾ ਰਹੇ ਹੋ, ਸਮੇਤ ਇੱਕ clean release build। ਗੁੰਮ ਹੋਈ configurations ਇੱਥੇ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ, ਨਾਹ ਕਿ launch ਦਿਨ।

Crash reporting ਅਤੇ release logging

ਤੁਸੀਂ ਇੱਕ clean build ship ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ ਰੀਅਲ-ਵਰਲਡ ਮੁੱਦੇ ਮਿਸ ਕਰ ਸਕਦੇ ਹੋ: ਅਜਿਹੇ ਡਿਵਾਈਸ, ਖਰਾਬ ਨੈੱਟਵਰਕ, ਅਤੇ edge-case flows. Crash reporting ਉਹਨਾਂ ਹੈਰਾਨੀਆਂ ਨੂੰ actionable issues ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਇੱਕ crash reporting ਟੂਲ ਚੁਣੋ ਅਤੇ ਉਹਨੂੰ ਜਲਦੀ ਜੋੜੋ। ਬ੍ਰਾਂਡ ਥੋੜ੍ਹਾ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ, ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਰਿਲੀਜ਼ ਤੋਂ 유ਜ਼ਫੁੱਲ reports ਆਉਣ।

Symbols ਅਤੇ mapping ਰਿਲੀਜ਼ ਦਾ ਹਿੱਸਾ ਬਣਾਓ

ਕਈ “reproduce ਨਹੀਂ ਹੋ ਸਕਦਾ” ਸਥਿਤੀਆਂ missing symbols ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਰਿਲੀਜ਼ ਸਟੈਪ ਬਣਾਓ ਕਿ ਤੁਸੀਂ upload ਕਰੋ:

• iOS dSYM files ( ਤਾਂ ਕਿ stack traces ਪੜ੍ਹਨਯੋਗ ਹੋਣ)
• Android obfuscation mapping (ਜੇ ਤੁਸੀਂ shrink/obfuscate ਕਰਦੇ ਹੋ)
• ਉਹੀ build number ਅਤੇ git commit (ਜਾਂ build tag) ਜੋ upload ਨਾਲ ਜੋੜੇ ਹੋਣ

ਜੇ ਇਹ ਮੈਨੂਅਲ ਹੈ, ਤਾਂ ਇਹ busy ਹਫ਼ਤੇ ਦੇ ਦੌਰਾਨ skip ਹੋ ਜਾਵੇਗਾ।

ਉਹ logs ਲਿਖੋ ਜੋ ਮਸਲਾ ਠੀਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ

ਪਹਿਲੇ ਦਿਨ ਲਈ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ: app version/build, device model, OS version, locale, ਅਤੇ ਆਖਰੀ screen ਜਾਂ action। ਜੇ ਤੁਹਾਡੇ ਕੋਲ accounts ਹਨ, ਤਾਂ ਇੱਕ stable anonymous user ID ਅਤੇ “logged in/logged out” flag ਸ਼ਾਮਲ ਕਰੋ। ਲਾਗਾਂ ਵਿੱਚ ਨਿੱਜੀ ਡੇਟਾ ਨਾ ਰੱਖੋ।

ਨੌਨ-ਫੈਟਲ errors ਵੀ ਕੈਪਚਰ ਕਰੋ। Flutter ਵਿੱਚ ਕਈ ਮੁੱਦੇ exceptions ਵਜੋਂ ਆਉਂਦੇ ਹਨ ਜੋ ਐਪ ਨੂੰ crash ਨਹੀਂ ਕਰਦੇ (parse errors, timeouts, unexpected nulls)। ਇਨ੍ਹਾਂ ਨੂੰ non-fatal events ਵਜੋਂ ਛੋਟਾ message ਅਤੇ ਕੁਝ key-value fields ਨਾਲ ਭੇਜੋ।

ਇਸਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ: ਇੱਕ staging build ਬਣਾਓ, ਇੱਕ forced crash trigger ਕਰੋ (debug menu ਜਾਂ secret gesture ਦੇ ਪਿੱਛੇ), ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ readable stack trace ਮਿਲ ਰਿਹਾ ਹੈ ਜਿਸ 'ਚ ਸਹੀ version ਅਤੇ context ਹੈ।

Permissions: ਉਪਭੋਗੀ-ਹਿੱਤ ਵਾਲੀ copy ਅਤੇ ਸਹੀ timing

Permissions ਪਹਿਲੀ ਲਾਂਚ 'ਤੇ ਭਰੋਸਾ ਖੋਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਹਨ। ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਹਰ permission ਨੂੰ ਲਿਸਟ ਕਰੋ ਜੋ ਐਪ ਮੰਗ ਸਕਦਾ ਹੈ, ਉਹ ਫੀਚਰ ਜੋ ਇਸਨੂੰ ਲੋੜੀਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗੀ ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ sentence ਵਿੱਚ ਇਹ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਇਹ permission ਨਹੀਂ ਮੰਗਣਾ ਚਾਹੀਦਾ।

copy ਸਧਾਰਨ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ। “We need access to your photos” ਦੀ ਥਾਂ “Allow photos so you can attach a receipt to your expense.” ਵਰਗਾ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। “storage” ਵਰਗੇ ਤਕਨੀਕੀ ਸ਼ਬਦ ਇਸ ਸਮੇਂ ਵਰਤਣ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਦਾ ਸਾਫ-ਸੁਥਰਾ ਵਰਨਣ ਨਹੀਂ ਦਿੰਦੇ।

ਉਹਦੀ ਮੰਗ ਸਿਰਫ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ ਉਪਭੋਗੀ ਸੰਬੰਧਿਤ action ਕਰੇ। Photos permission app start ਤੇ ਨਾ ਮੰਗੋ। “Add photo” 'ਤੇ ਟੈਪ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਛੋਟੀ pre-permission screen ਦਿਖਾਓ ਜੋ ਕਾਰਣ ਸਮਝਾਉਂਦੀ ਹੈ, ਫਿਰ system prompt ਦਿਖਾਓ।

ਜੇ ਉਪਭੋਗੀ ਨਾ ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਐਪ ਨੂੰ ਫਿਰ ਵੀ ਵਰਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। fallback ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਿਤ ਕਰੋ: ਫੀਚਰ ਦਿੱਖਦਾ ਰਹੇ, ਕਿਹਾ ਜਾਵੇ ਕਿ ਕੀ ਰੁਕਿਆ ਹੈ, ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਵਿਕਲਪ ਦਿਓ, ਅਤੇ ਪ੍ਰਗਤੀ ਸੇਵ ਕਰੋ ਤਾਂ ਕਿ ਉਹ ਕੰਮ ਨਾ ਖੋਵੇ। ਜੇ ਉਹ “Don’t ask again” ਚੁਣਦੇ ਹਨ, ਤਾਂ ਜ਼ਬਰਦਸਤੀ ਨਾ ਕਰੋ—ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ Settings ਤੱਕ ਰਹਿਨੁਮਾਈ ਦਿਓ।

Platform-specific text ਨੂੰ ਦੂਬਾਰਾ ਜਾਂਚੋ। iOS ਨੂੰ Info.plist ਵਿੱਚ ਸਪਸ਼ਟ usage descriptions ਦੀ ਲੋੜ ਹੈ। Android ਨੂੰ ਸਹੀ manifest entries ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਕਈ ਵਾਰ in-app ਛੋਟਾ ਸਪੱਸ਼ਟੀਕਰਨ ਵੀ। ਗਾਇਬ ਜਾਂ vague text review ਵਿੱਚ ਦੇਰ ਜਾਂ user drop-off ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ release testing pass (ਪੂਰੀ ਟੈਸਟ ਯੋਜਨਾ ਨਹੀਂ)

ਇਹ ਇੱਕ lightweight pass ਹੈ ਜੋ ਉਹਨਾਂ ਮਸਲਿਆਂ ਨੂੰ ਫੜਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਸਿਰਫ real release build ਵਿੱਚ ਹੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ। ਇਸਨੂੰ ਘੰਟੇ ਤੋਂ ਘੱਟ ਵਿੱਚ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਸਾਦਾ script ਲਿਖੋ ਜੋ ਕੋਈ ਵੀ follow ਕਰ ਸਕੇ, ਭਾਵੇਂ ਉਹਨਾਂ ਕੋਲ developer tools ਨਾ ਹੋਣ। ਨਿਯਮ: ਉਹਨਾਂ ਗੱਲਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ ਜੋ ਉਪਭੋਗੀ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਜੋ ਡਿਵੈਲਪਰ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹਨ।

ਇੱਕ ਤੇਜ਼ release QA script

ਇੱਕ ਛੋਟੀ ਫੋਨ ਅਤੇ ਇੱਕ ਵੱਡੇ ਡਿਵਾਈਸ 'ਤੇ (ਅਤੇ ਭਲਕੇ ਇੱਕ ਪੁਰਾਣੇ OS ਵਰਜਨ) ਰਨ ਕਰੋ:

• Release build install ਕਰੋ (debug ਨਹੀਂ) ਅਤੇ تصدیق ਕਰੋ ਕਿ ਇਹ store app ਵਾਂਗ ਵਰਤਦਾ ਹੈ (ਕੋਈ debug banner, dev menus ਨਹੀਂ)।
• Onboarding ਅਤੇ login ਸ਼ੁਰੂ ਤੋਂ ਕਰੋ (password reset ਜਾਂ magic link ਸਮੇਤ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਹੈ)।
• ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ “money” flow (subscription, in-app purchase, checkout, ਜਾਂ paywall) ਨੂੰ حقیقی test accounts ਨਾਲ trigger ਕਰੋ।
• Notifications end-to-end ਚੈੱਕ ਕਰੋ: permission prompt, ਸੁਨੇਹਾ ਮਿਲਣਾ, ਅਤੇ ਉਸ 'ਤੇ ਟੈਪ ਕਰਨ 'ਤੇ ਸਹੀ screen ਖੁਲਣਾ।
• Offline ਅਤੇ poor network ਨੂੰ ਟੈਸਟ ਕਰੋ: airplane mode चालੂ करके ਐਪ ਓਪਨ ਕਰੋ, ਫਿਰ ਕਨੈਕਸ਼ਨ ਵਾਪਸ ਆਉਣ 'ਤੇ recovery ਕਰੋ।

ਰਨ ਤੋਂ ਬਾਅਦ, ਫੋਰਸ-ਕਲੋਜ਼ ਅਤੇ ਦੁਬਾਰਾ launch ਕਰੋ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣੇ ਕਿ ਐਪ clean ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ warm state 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ।

ਜੇ ਕੁਝ ਫੇਲ ਹੋ ਜਾਏ, ਤਾਂ ਅਖੀਰਲੇ screen, ਆਖਰੀ action, ਅਤੇ ਕੀ ਇਹ ਕੇਵਲ ਇੱਕ device size 'ਤੇ ਹੀ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਦਾ ਨੋਟ ਲਵੋ। ਇਹ ਅਕਸਰ ਫਾਸਟ fix ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।

Store listing assets: ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰ ਰੱਖੋ

ਜ਼ਿਆਦਾ launch tension store pages ਤੋਂ ਆਉਂਦੀ ਹੈ, ਕੋਡ ਤੋਂ ਨਹੀਂ। listing ਨੂੰ release ਕੰਮ ਦਾ ਹਿੱਸਾ ਸਮਝੋ ਤਾਂ ਜੋ ਆਖਰੀ ਸਮੇਂ ਡਿਜ਼ਾਈਨ ਦੀਆਂ ਮੰਗਾਂ, ਗੁੰਮ privacy answers, ਅਤੇ screenshot хаос ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।

ਉਹ ਚੀਜ਼ਾਂ ਇਕੱਠਾ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਲੋੜ ਪਏਗੀ: app icon, screenshots, ਇੱਕ ਛੋਟੀ subtitle, ਲੰਬੀ description, ਅਤੇ ਜੋ ਵੀ platform-specific graphics ਜ਼ਰੂਰੀ ਹਨ। Promo video ਵਿਕਲਪਿਕ ਹੈ ਅਤੇ ਕੇਵਲ ਉਸ ਵੇਲੇ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸਨੂੰ ਅੱਪ-ਟੂ-ਡੇਟ ਰੱਖ ਸਕੋ।

Screenshots ਲਈ, ਆਪਣੀਆਂ device sizes ਪਹਿਲਾਂ ਚੁਣੋ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਟਿਕੇ ਰਹੋ। ਇੱਕ consistent order ਰੱਖੋ (onboarding, core screen, key feature, settings, upgrade) ਤਾਂ ਜੋ ਅਪਡੇਟਸ ਘੜੀਆਂ-जੈਸੀ ਨਹੀਂ ਬਣਦੀਆਂ।

Description ਨੂੰ ਮਨੁੱਖੀ ਜਿਹਾ ਲਿਖੋ: ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਜੋ ਦੱਸੇ ਕਿ ਐਪ ਕੀ ਕਰਦੀ ਹੈ, ਫਿਰ ਕੁਝ ਛੋਟੇ ਫਾਇਦੇ ਵਾਲੇ ਲਾਈਨ, ਅਤੇ ਫਿਰ subscription ਜਾਂ accounts ਬਾਰੇ ਸਧਾਰਣ ਨੋਟ ਜੇ ਤੁਸੀਂ ਉਹ ਰੱਖਦੇ ਹੋ। ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਸਹਾਇਤਾ ਨਹੀ—ਉਹਦਾ ਵਾਅਦਾ ਨਾ ਕਰੋ।

ਇਸੇ ਤਰ੍ਹਾਂ ਆਪਣੀਆਂ privacy ਅਤੇ data usage answers ਪਹਿਲਾਂ ਇਕੱਤਰ ਕਰੋ। ਤੁਹਾਨੂੰ tracking, ਇਕੱਤਰ ਕੀਤੇ ਡੇਟਾ ਟਾਈਪ, ਅਤੇ permissions ਬਾਰੇ ਪੁੱਛਿਆ ਜਾਵੇਗਾ। ਜੇ ਐਪ location, contacts, ਜਾਂ photos ਮੰਗਦੀ ਹੈ, ਤਾਂ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਾਰਨ ਦੱਸੋ।

ਜੇ ਤੁਸੀਂ assets ਸੰਗਠਿਤ ਰੱਖਦੇ ਹੋ, ਤਾਂ updates routine ਬਣ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ structure ਕਾਫੀ ਹੈ (icon, screenshots by device type, copy, privacy notes, ਅਤੇ release notes)।

Dry-run submission ਕਰੋ ਤਾਂ ਜੋ ਕੋਈ ਅਚੰਭਾ ਨਾ ਹੋਵੇ

Dry-run ਉਹ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ store submission flow ਨੂੰ ਉਹੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ ਲਾਂਚ ਕਰਨ ਵਾਲੇ ਹੋ, ਪਰ Publish ਦਬਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕ ਜਾਂਦੇ ਹੋ। ਇਹ ਅਨੁਮਾਨਾਂ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ।

ਉਸ ਬਿਲਡ ਨੂੰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ submit ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ (ਭਾਵੇਂ ਤੁਸੀਂ ਉਹ ਸੱਚਮੁੱਚ publish ਨਾ ਕਰੋ). Upload ਕਰੋ, ਫਾਰਮ ਭਰੋ, ਅਤੇ ਸਭ ਕੁਝ draft ਵਜੋਂ save ਕਰੋ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਗੁੰਮ ਦੀ ਜਾਣਕਾਰੀ ਸਮੇਂ ਦੇ ਨਾਲ before it's too late ਮਿਲ ਜਾਵੇ।

ਤਸਦੀਕ ਕਰੋ:

• Version ਅਤੇ build number ਉਮੀਦ ਅਨੁਸਾਰ ਹਨ, ਅਤੇ release notes ਤਿਆਰ ਹਨ।
• Compliance questions (data collection, ads, encryption, login requirements, sensitive permissions) ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਭਰੇ ਗਏ ਹਨ।
• Supported countries, pricing (ਜੇ ਕੋਝ), ਅਤੇ age rating ਚੋਣ ਸਹੀ ਹਨ।
• Contact details ਤਿਆਰ ਹਨ: support email, privacy policy text location, ਅਤੇ ਕੋਈ review notes।
• Review info ਪੂਰੀ ਹੈ: demo account (ਜੇ ਲੋੜ ਹੋਵੇ) ਅਤੇ key features ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਸਾਫ steps।

"ਜੇ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਬੁਰਾ ਹੋਵੇ" ਤਾਂ ਉਸਦਾ rollback plan ਵੀ ਤਿਆਰ ਕਰੋ (ਪਹਿਲਾ signed artifact ਰੱਖੋ), hotfix ਕਿਵੇਂ ship ਕਰੋਂਗੇ, ਅਤੇ ਕਿਸ ਸਥਿਤੀ 'ਤੇ rollout ਨੂੰ ਰੋਕਣਾ ਹੈ (crash spikes, login failures)।

ਇਸ ਦੇ ਨਾਲ ਇਹ ਵੀ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਪਹਿਲੇ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਤੁਸੀਂ ਸਵੇਰੇ feedback ਕਿਵੇਂ ਇਕੱਠਾ ਕਰੋਗੇ। ਇੱਕ ਛੋਟੀ ਗਰੁੱਪ ਚੈਨਲ, ਇੱਕ support inbox ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਮਾਨਿਟਰ ਕਰਦੇ ਹੋ, ਅਤੇ ਇੱਕ in-app “Send feedback” ਵਿਕਲਪ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਇੱਕ-ਸਟਾਰ reviews ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਸਕਦੇ ਹਨ।

ਆਮ ਫੰਦਾ ਜਿਹੜੇ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦਿਨ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਦੇਰਾਂ ਇਸ ਲਈ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਜੋ build ਤੁਸੀਂ ਟੈਸਟ ਕੀਤਾ ਉਹੀ build ਤੁਸੀਂ ship ਨਹੀਂ ਕਰਦੇ। ਇੱਕ debug ਜਾਂ profile build ਸ਼ਾਨਦਾਰ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ release build ਅਸਲ ਡਿਵਾਈਸ 'ਤੇ fail ਕਰ ਸਕਦੀ ਹੈ minification, ਵੱਖਰੀ config value, ਜਾਂ missing runtime permissions ਕਾਰਨ।

ਹੋਰ ਸਮੇਂ ਲਾਉਣ ਵਾਲੀ ਗਲਤ ਫੈਸਲ development ਅਤੇ production settings ਨੂੰ mix ਕਰਨਾ ਹੁੰਦੀ ਹੈ: staging API URL ship ਹੋਣਾ, ਗਲਤ analytics key, ਜਾਂ test payment settings। production ਨੂੰ ਆਪਣੇ environment ਵਜੋਂ treat ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਹੀ release artifact ਤੇ verify ਕਰੋ।

ਇਹ traps ਟੀਮਾਂ ਨੂੰ ਬਾਰ-ਬਾਰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ:

• "close to release" test ਕਰਨ ਦੀ ਅਗਵਾਈ, ਬਜਾਏ ਕਿ ਉਹੀ signed artifact ਟੈਸਟ ਕੀਤਾ ਜਾਵੇ ਜੋ upload ਕੀਤਾ ਜਾਣਾ ਹੈ।
• configs ਸਾਫ ਨਹੀਂ ਹੋਣ ਕਾਰਨ ਗਲਤ endpoints ਜਾਂ feature flags ship ਹੋ ਜਾਣਾ।
• Review rejections permission prompts vague ਜਾਂ missing ਹੋਣ ਕਾਰਨ।
• Crash reports ਜਿਨ੍ਹਾਂ ਤੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ symbols/mapping upload ਨਹੀਂ ਕੀਤੇ ਗਏ।
• Signing keys ਅਤੇ ਸਿਰਫ ਇਕ ਕੰਪਿਊਟਰ 'ਤੇ काम ਕਰਨ ਵਾਲੀ setup।

ਇਕ ਸੀਨੇ-ਯਾਦ ਕਰੋ: ਸ਼ੁਕਰਵਾਰ ਨੂੰ upload—ਇੱਕ reviewer ਐਪ ਖੋਲ੍ਹਦਾ ਹੈ, ਕਿਸੇ ਫੀਚਰ 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ ਜੋ access ਮੰਗਦਾ ਹੈ, ਅਤੇ text vague ਹੈ। ਤੁਸੀਂ copy ٹھیک ਕਰਦੇ ਹੋ, ਪਰ signing key ਉਸ colleague ਦੇ ਮਸ਼ੀਨ 'ਤੇ ਹੈ ਜੋ ਆਫਲਾਈਨ ਹੈ। ਇਹ ਦੋ ਦਿਨ ਬਰਬਾਦ ਹੋ ਸਕਦੇ ਹਨ—ਜੋ ਰੋਕੇ ਜਾ ਸਕਦਾ ਹੈ।

ਤੇਜ਼ release readiness checklist (ਪ੍ਰਿੰਟ ਕਰਨ ਯੋਗ)

ਇਸਨੂੰ ਉਸ ਦਿਨ ਵਰਤੋ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲੀ store build ਕੱਟਣ ਵਲ ਹੋ। ਇਹ ਸੰਖੇਪ ਹੈ ਇਰਾਦੇ ਨਾਲ। ਜੇ ਕੋਈ ਆਈਟਮ “ਸ਼ਾਇਦ” ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ store ਫਾਰਮ 'ਤੇ ਸਮਾਂ ਖਰਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ।

• Signing works on a clean machine. ਇੱਕ fresh checkout signed release bina hunting for files ਬਣ ਸਕਦੀ ਹੈ। Keys/certs backup ਕੀਤੇ ਹੋਏ, access limited, ਅਤੇ ownership ਸਪੱਸ਼ਟ ਹੋਵੇ।
• All build flavors succeed. Dev, staging (ਜੇ ਵਰਤਿਆ), ਅਤੇ production bina manual tweaks build ਹੋਣ। Production config confirm ਕੀਤਾ ਹੋਵੇ (bundle id/applicationId, app name, icons, API endpoints, analytics keys)।
• Crash reporting works in a release build. Release build 'ਚ test crash ਜਾਂ event readable symbols/mapping ਨਾਲ ਆ ਰਹੀ ਹੋਵੇ।
• Permissions are justified and readable. ਹਰ permission ਲਈ ਸਪੱਸ਼ਟ, ਮਨੁੱਖੀ copy ਹੋਵੇ ਅਤੇ ਜੇ ਉਪਭੋਗੀ deny ਕਰੇ ਤਾਂ ਐਪ ਹਾਲੇ ਵੀ ਵਰਤਣਯੋਗ ਬਣੀ ਰਹੇ। Timing context ਵਿੱਚ ਹੋਵੇ।
• Store listing assets are done. Icons, screenshots, required graphics, short/long descriptions, support email, privacy labels, ਅਤੇ age rating info drafted ਅਤੇ reviewed ਹੋਣ।

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਗੇ platform ਨਾਲ build ਕਰ ਰਹੇ ਹੋ ਜੋ source export ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਹੋਰ ਚੈਕ ਜੋੜੋ: exported project ਤੋਂ ਉਹੀ signed release build produce ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ upload ਕਰਨ ਜਾ ਰਹੇ ਹੋ, ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਉਦਾਹਰਨ: ਪਹਿਲੀ submission ਹਫ਼ਤੇ ਨੂੰ ਬਿਨਾਂ panic ਦੇ ਕਿਵੇਂ ਚਲਾਇਆ ਜਾਵੇ

ਇੱਕ ਛੋਟੀ ਟੀਮ ਤਿੰਨ ਲੋਕਾਂ ਦੀ—ਇਕ developer, ਇਕ designer, ਅਤੇ ਇੱਕ part-time PM—ਉਹਨਾਂ ਦੀ ਪਹਿਲੀ Flutter ਐਪ stores ਵਿੱਚ ਪਾਉਣ ਲਈ ਤਿਆਰੀ: ਉਹਨਾਂ ਪਹਿਲੀ submission ਨੂੰ ਇੱਕ rehearsal ਵਾਂਗ ਲੈਂਦੇ ਹਨ।

Monday ਨੂੰ, developer release build generate ਕਰਦਾ/ਕਰਦੀ ਹੈ ਅਤੇ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ signing key ਇਕ ਲੈਪਟੌਪ 'ਤੇ ਹੈ ਜੋ ਝਟ ਪਟੀ ਹੋਣ ਵਾਲੀ ਹੈ। ਉਹ ਇਸਨੂੰ ਉਹੀ ਦਿਨ ਠੀਕ ਕਰਦਾ/ਕਰਦੀ ਹੈ: key ਨੂੰ shared, access-controlled vault ਵਿੱਚ移, ownership document ਕਰਦਾ/ਕਰਦੀ ਹੈ, ਅਤੇ CI machine ਨੂੰ sign ਕਰ ਸਕਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ/ਕਰਦੀ ਹੈ।

Tuesday ਨੂੰ, PM ਹਰ permission prompt ਉਤਾਰ-ਪੜਤਾਲ ਕਰਦਾ/ਕਰਦੀ ਹੈ। ਇੱਕ prompt ਅਜਿਹਾ ਹੈ: photo permission text "required" ਕਹਿੰਦਾ ਹੈ ਪਰ ਐਪ ਸਿਰਫ optional profile pictures ਲਈ ਇਸਦੀ ਲੋੜ ਹੈ। ਉਹ copy ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ/ਲਿਖਦੀਆਂ ਹਨ ਅਤੇ ਮੰਗ "Add photo" ਦੇ ਸਮੇਂ 'ਤੇ ਲਿਆਉਂਦਾ/ਲਿਆਉਂਦੀ ਹੈ।

Thursday ਨੂੰ, ਉਹ final screenshots, release notes, ਅਤੇ production build ਨਾਲ ਪੂਰਾ dry-run submission ਕਰਦੇ ਹਨ। Store description ਅਤੇ in-app subscription label ਵਿੱਚ mismatch ਨਿਕਲਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ dry-run ਸੀ, ਉਹ wording ਠੀਕ ਕਰਦੇ ਹਨ ਅਤੇ launch ਦਿਨ ਤੋਂ ਪਹਿਲਾਂ resubmit ਕਰ ਦਿੰਦੇ ਹਨ।

ਅਗਲੀ ਵਾਰੀ ਲਈ ਉਹ ਸਾਦਾ timeline ਰੱਖਦੇ ਹਨ:

• Mon: Freeze features, verify signing and production build
• Tue: Review permissions and in-app copy
• Wed: Smoke test on real devices, confirm analytics and crash reporting
• Thu: Dry-run store submission
• Fri: Submit for review and keep buffer for fixes

ਅਗਲੇ ਕਦਮ: ਆਪਣੀ ਅਗਲੀ ਰਿਲੀਜ਼ ਪਹਿਲੀ ਤੋਂ ਅਸਾਨ ਬਣਾਓ

ਪਹਿਲੀ ਲਾਂਚ ਤੁਹਾਨੂੰ ਸਿਖਾਉਂਦੀ ਹੈ ਕਿ "ready" ਦਾ ਅਸਲ ਰੂਪ ਕੀ ਹੈ। ਇਹਨਾਂ ਸਿਖਲਾਈਆਂ ਨੂੰ ਤੁਰੰਤ capture ਕਰੋ।

ਸਪੱਸ਼ਟ ਮਾਲਿਕ ਨਿਰਧਾਰਤ ਕਰੋ। ਛੋਟੀ ਟੀਮ ਵਿੱਚ ਵੀ, “everyone” ਅਕਸਰ “no one” ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੁੱਖ ਕੰਮ ਲੰਘ ਜਾਂਦੇ ਹਨ:

• Signing ਅਤੇ key storage
• Final device checks ਅਤੇ go/no-go
• Store listing assets ਅਤੇ copy
• Submission steps ਅਤੇ reviewer follow-up

ਜੋ ਤੁਸੀਂ ਹੁਣ ਕੀਤਾ ਉਹ ਇੱਕ ਦੁਹਰਾਇਆ ਜਾਣ ਵਾਲਾ checklist ਅਤੇ release note template ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ: commands ਜੋ ਤੁਸੀਂ ਚਲਾਏ, approvals ਜਾਂਦੀਆਂ, ਅਤੇ ਫਾਇਲਾਂ ਜੋ ਤੁਸੀਂ upload ਕੀਤੀਆਂ। ਗੋਟਚਾਜ਼ ਵੀ ਜੋੜੋ, ਜਿਵੇਂ ਕਿ ਕਿਹੜਾ flavor production ਹੈ ਅਤੇ ਕਿਹੜੇ permission texts reviewers ਨੇ sawaal ਕੀਤਾ।

ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ 20-minute post-release review ਤੇ ਨਿਯਤ ਕਰੋ। ਧਿਆਨ ਫਿਕਸ 'ਤੇ ਰੱਖੋ, ਨਾ ਕਿ ਦੋਸ਼ ਤੇ:

• Submission ਜਾਂ review ਦੌਰਾਨ ਸਾਨੂੰ ਕੀ ਹੈਰਾਨੀ ਹੋਈ?
• ਕਿਸ ਚੀਜ਼ ਨੂੰ ਉਮੀਦ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਿਆ, ਅਤੇ ਕਿਉਂ?
• ਅਗਲੀ ਵਾਰੀ ਅਸੀਂ ਕੀ ਪਹਿਲਾਂ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ (assets, copy, support inbox)?

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ build ਕਰਦੇ ਹੋ, ਤਾਂ Planning Mode release tasks ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ snapshots ਤੁਹਾਨੂੰ last-minute ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ known-good state ਦੇ ਸਕਦੇ ਹਨ।