Mobile app: publish to Play Store & App Store

The release path

1. Live server on https:// with the app API — apps in the stores cannot use your PC.
2. Production builds in Expo's cloud: an Android App Bundle (.aab) and an iPhone app (.ipa).
3. Store listings: text, screenshots, privacy answers, a demo login for the reviewers.
4. Testing with your team: Google Play internal/closed testing, Apple TestFlight.
5. Review by Google and Apple, then release to everyone.
6. Updates: raise the version, build, upload, release.

Plan about 1–2 weeks for the first release: account approvals, the first reviews and (for a personal Google account) a 14-day closed test.

Accounts and costs

1. Live server

Deploy SiteCash as described in DEPLOY.md on a domain with HTTPS, for example https://app.sitecash.in. Installed apps refuse plain http://. Then check:

Check in a browser (use your domain):

• https://app.sitecash.in/api/health → {"ok":true,"db":"up",…}
• https://app.sitecash.in/privacy and /account-deletion → pages show your support email
• https://app.sitecash.in/help/index.html → the manual

2. Final app settings

App ids (decide once)

In mobile/app.json: android.package and ios.bundleIdentifier are com.sitecash.app. They can never change after the first store release — a new id is a different app. If you change the Android package, also add that package as an app in Firebase and replace google-services.json.

Server address for store builds

The address is written into the app when it is built. Store it in Expo for the production (store) and preview (tester APK) builds:

cd C:\Projects\PettyCash-RealEstate\mobile
eas env:set --environment production --name EXPO_PUBLIC_API_URL --value https://app.sitecash.in --visibility plaintext
eas env:set --environment preview    --name EXPO_PUBLIC_API_URL --value https://app.sitecash.in --visibility plaintext
eas env:list production     # check what the production build will use

--visibility plaintext: the value is not secret (it is visible inside the app anyway). To change it later run the same eas env:set command with the new value, or manage it on expo.dev → project → Environment variables.

Version

"version" in app.json is what users see (start with 1.0.0). The internal build numbers (Android versionCode, iOS buildNumber) are counted by Expo and go up by themselves on each production build ("appVersionSource": "remote" and "autoIncrement": true in eas.json).

Try a preview build first

eas build -p android --profile preview

This is the same app as the store version but installed from a link (APK), connected to the live server. Install it on a few phones and go through the test checklist before building for the stores.

3. Signing and push keys

Stores only accept apps signed with your keys. EAS creates and keeps them for you.

4. Production builds

cd C:\Projects\PettyCash-RealEstate\mobile
git pull                                  # build the latest committed code
eas build -p android --profile production # → .aab for Google Play
eas build -p ios --profile production     # → .ipa for the App Store
# or both at once:
eas build -p all --profile production

• Each build takes about 15–40 minutes. Follow it on the link shown, or list builds with eas build:list.
• The production profile uses the production environment variables (your https server address) and raises the build number.
• You can build and upload in one go with --auto-submit once the store setup below is done: eas build -p all --profile production --auto-submit.

5. Demo login for reviewers

Google and Apple both sign in to test the app. They need a working login that is not a real company. Create the made-up demo company on the live database once:

cd C:\Projects\PettyCash-RealEstate
$env:DATABASE_URL = "postgres://…your live database…"
$env:SAMPLE_PASSWORD = "Review-2026!secure"      # choose your own strong password
$env:SAMPLE_ONLY_COMPANY = "1"                   # only the demo company, no extra sample companies
npx tsx scripts/seed-sample.ts

It creates Sunrise Developers Pvt Ltd with an active plan for one year, sites, entries with bill photos, vendor bills and cash requests, and these logins (with your password):

• kiran@sunrise.example — site user (give this to reviewers)
• neha@sunrise.example — accountant (give this too, to show approvals)
• ravi@sunrise.example — owner

6. Screenshots and graphics

1. Install the preview/production app on a phone, log in with the demo company (step 5).
2. Capture: Home, Cash book, New expense with a bill photo, Voucher, Approvals (as Neha), Request cash. Android: Power + Volume down. iPhone: Side button + Volume up. For the App Store use a large iPhone (e.g. iPhone 15/16 Plus or Pro Max) so the size matches.
3. Use only the demo company — never real company names or amounts.

7. Google Play

7a. Create the app

1. Play Console → Create app.
2. App name SiteCash – Site Petty Cash, default language English (India) or English (US), App, Free. Accept the declarations → Create app.

7b. App content (Dashboard → "Set up your app")

7c. Data safety answers

7d. Store listing

Grow users → Store presence → Main store listing: short and full description (text to paste), 512 × 512 icon, 1024 × 500 feature graphic, phone screenshots. Store settings: category Business, contact email = your support email, website = your domain.

7e. First upload: internal testing

1. Test and release → Testing → Internal testing → Testers: create an email list with your team's Google accounts.
2. Create new release. When asked about app signing, keep Google-managed signing (Play App Signing).
3. Download the .aab from the build page on expo.dev and drag it into App bundles. (Google requires this first upload by hand.)
4. Release name is filled in; add release notes ("First release"). Next → Save and publish.
5. Share the join link from the Testers tab. Testers open it, accept, and install SiteCash from the Play Store.

7f. Closed testing (personal accounts) and production

1. Personal developer account: create a Closed testing track, add at least 12 testers who stay opted in for 14 days, then use Apply for production on the dashboard. (Organization accounts can skip this.)
2. Production → Create new release → Add from library (choose the tested bundle) → release notes → countries (e.g. India) → Save.
3. Publishing overview → Send changes for review. The first review can take from a few hours to about a week; you get an email.

7g. Upload later versions from the command line (optional)

1. Google Cloud console (same Google account) → create a service account → create a JSON key and download it (keep it outside the repo).
2. Play Console → Users and permissions → Invite new users → the service account's email → give it release permissions for SiteCash.
3. Then, after each Android production build:

   eas submit -p android --latest

   The first time it asks for the JSON key file and remembers it. --latest uploads your most recent build. Uploads go to the internal testing track; promote them in the Play Console.

8. Apple App Store

8a. Upload the build

cd C:\Projects\PettyCash-RealEstate\mobile
eas submit -p ios --latest

Sign in with your Apple ID when asked. EAS creates the app record in App Store Connect if it does not exist (name, bundle id, SKU), creates an App Store Connect API key, and uploads the latest iOS production build. Apple then processes it (about 15–60 minutes; you get an email).

8b. TestFlight

1. App Store Connect → Apps → SiteCash → TestFlight.
2. The encryption question does not appear: app.json already declares the app uses only standard HTTPS.
3. Internal testing: add people from your App Store Connect team (up to 100) — available at once. External testing (anyone by email or public link): the first build needs a short Beta App Review.
4. Testers install the TestFlight app and accept the invitation.

8c. App information

8d. Prepare the version and submit

1. App Store tab → version 1.0: screenshots (6.9-inch or 6.7-inch), promotional text, description, keywords (e.g. petty cash,expense,voucher,builder,construction,site,bill,approval,tally), support URL (your domain), marketing URL (optional).
2. Build → Add Build → choose the tested build.
3. App Review Information: sign-in required → kiran@sunrise.example + password; contact name, phone, email. Notes:

   SiteCash is a business app for construction companies. Accounts are created and
   paid for by the customer company on the SiteCash website; there is no sign-up or
   purchase in the app. Demo site user: kiran@sunrise.example. Demo accountant (can
   approve entries): neha@sunrise.example. Both use the password above.
   Office features (vendor bills, reports, Tally export) are on the website.

4. Version Release: "Manually release this version" (you choose the day) or "Automatically".
5. Add for Review → Submit for Review. Status goes Waiting for Review → In Review → Pending Developer Release / Ready for Distribution, usually within 1–3 days.

Store text to paste

Full description (both stores):

SiteCash is the petty cash book for construction sites. Site staff record every
expense and every rupee received from their phone, with a photo of the bill —
even without signal; entries upload when the phone is back online.

• Cash book per site with running balance and low-balance warnings
• Expenses, cash received and cash returned with bill photos
• Approvals: accountants approve or send entries back with a note
• Cash requests with the site's spending pace and a suggested amount
• Alerts on the phone for requests, approvals and low balance
• Works with the SiteCash website for vendor bills, reports and Tally export

A SiteCash company account is needed; your company's admin adds you.

Release notes for version 1.0.0: First release: site cash book, expenses with bill photos, approvals, cash requests, alerts and offline entries.

9. Updates

1. Raise "version" in mobile/app.json: 1.0.1 for fixes, 1.1.0 for new features. Commit and push.
2. Build: eas build -p all --profile production (build numbers go up by themselves).
3. Upload: eas submit -p android --latest and eas submit -p ios --latest.
4. Play Console: promote the release from internal testing to production (you can use a staged rollout, e.g. 20% of users first). App Store Connect: create the new version, choose the build, add "What's New", submit (you can use phased release over 7 days).

Yearly: Google Play requires apps to target a recent Android version (the deadline is usually each August), and Apple requires builds made with a recent Xcode. Upgrade the Expo SDK about once a year (npx expo install expo@latest --fix, then follow Expo's upgrade notes), test, and release an update.

10. After launch

• Crashes and errors: Play Console → Android vitals; App Store Connect → TestFlight and Analytics → Crashes. Server errors: your server logs.
• Reviews: answer store reviews from both consoles.
• Keep active: Apple Developer membership (yearly), the demo company's plan, and the Firebase project.
• Tell customers: owners can share the store links with site staff; staff log in with their existing SiteCash email and password.

Troubleshooting

Developing and testing the app: Development setup. The technical API contract: docs/mobile-api.md in the code.