September 12, 2026
13 min read
By Kokil Thapa | Last reviewed: September 2026
Your product works in staging, but users still ask for an installable app. To publish to the App Store and Play Store, you need more than code—you need developer accounts, signed builds, store listings, privacy disclosures, and a backend that survives real traffic. On client projects I often handle the REST API and Laravel backend while a mobile partner ships the native shell. That split is common for Nepal SMBs with limited budgets. This guide covers both stores end to end, plus when a PWA or hybrid wrapper is the smarter first move.
Quick answer: To publish to the App Store and Play Store, enroll in Apple Developer Program and Google Play Console, build signed release binaries, complete store listings and privacy forms, then submit for review—typically 24–48 hours on Google Play and 1–3 days on Apple.
What do you need before you publish to the App Store and Play Store?
Store submission starts with decisions, not Xcode or Android Studio. Pick your delivery model first. A fully native app gives the best device access. A hybrid app wraps a WebView around your web UI. A PWA skips the stores entirely but loses some discovery and OS integration.
I've seen teams burn weeks on store paperwork while the API still returns 500 errors on slow networks. Fix the backend before you polish screenshots. Your mobile client will call the same endpoints under worse conditions than your browser tests.
Developer accounts and fees
Apple requires an active Apple Developer Program membership. It costs USD 99 per year. Google Play uses a one-time USD 25 registration fee via Google Play Console. For Nepal-based businesses, pay with an international card. Budget roughly Rs 13,000/year for Apple alone.
Apple needs a D-U-N-S number for organisation accounts. Individual accounts are faster for solo founders. Google accepts personal or business accounts with fewer upfront hurdles.
Backend and API readiness
Most apps I support are thin clients over a Laravel or WordPress API. Before store submission, confirm:
- HTTPS everywhere with valid TLS certificates
- Token auth (Sanctum, OAuth, or JWT) with refresh flows
- Pagination and rate limits on list endpoints
- Versioned API paths such as
/api/v1/orders - Push notification endpoints if you plan remote alerts
On booking systems like Adventure Third Pole Trek, mobile users expect offline-tolerant forms and fast search. Your API must handle spotty mobile networks. Test with load testing on staging before reviewers and early users hit production.
Legal and privacy assets
Both stores require a public privacy policy URL. Nepal-facing apps should also respect local data rules covered in our data privacy guide for web apps. List every third party that receives user data—analytics, crash reporting, payment gateways like eSewa or Khalti.
How do you submit an app to the Apple App Store?
Apple review is stricter than Google. Plan for rejections on metadata, permissions, or incomplete login flows. Treat review feedback as a checklist, not a surprise.
Build and sign your iOS release
Create an App ID, provisioning profile, and distribution certificate in Apple Developer portal. In Xcode, set the bundle identifier to match. Bump CFBundleShortVersionString (marketing version) and CFBundleVersion (build number) for every upload.
# Example: increment build in Info.plist via agvtool
agvtool next-version -all
agvtool new-marketing-version 2.1.0
# Archive from Xcode: Product → Archive
# Or xcodebuild for CI:
xcodebuild -workspace MyApp.xcworkspace \
-scheme MyApp \
-configuration Release \
-archivePath build/MyApp.xcarchive archiveUpload through Xcode Organizer or xcrun altool. CI pipelines often use Fastlane deliver to push builds and metadata together.
Complete App Store Connect listing
In App Store Connect, create the app record with name, primary language, bundle ID, and SKU. Fill in:
- App Privacy questionnaire—declare data collected and linked to the user
- Screenshots for required device sizes (6.7", 6.5", iPad if universal)
- Description, keywords, support URL, marketing URL
- App Review Information with a working demo login if your app gates content
- Export compliance answers for encryption
Apple rejects apps that hide features behind logins without test credentials. Provide a read-only demo account. Mention server dependencies in the notes field.
TestFlight then production review
Upload builds appear in TestFlight within 15–30 minutes. Internal testers see builds immediately. External testers need a brief beta review. Run one external beta cycle before your first production submission.
When ready, select the build under App Store → iOS App → Version, answer the content-rights questions, and submit for review. Most first submissions take one to three business days.
How do you publish an app on Google Play Store?
Google Play uses a staged rollout model. You can ship internal tests in hours. Production review is usually faster than Apple, but policy strikes are cumulative.
Create the app and signing key
In Play Console, create an app, choose free or paid, and accept declarations. Generate an upload key and register it. Google Play App Signing is mandatory for new apps—Google holds the app signing key; you keep the upload key.
# Generate upload keystore (store securely — loss blocks updates)
keytool -genkey -v -keystore upload-keystore.jks \
-keyalg RSA -keysize 2048 -validity 10000 \
-alias upload
# Build Android App Bundle (required for new apps)
./gradlew bundleRelease
# Output: app/build/outputs/bundle/release/app-release.aabNever commit keystores to Git. Store passwords in your CI secret manager. On client projects I document keystore location in an encrypted vault—not in Slack.
Store listing and content rating
Complete the main store listing: short description (80 chars), full description (4000 chars), icon (512×512), feature graphic (1024×500), and phone screenshots. Add a privacy policy link matching your iOS policy.
Complete the content rating questionnaire via IARC. Select target countries. For Nepal, include NP unless you have licensing reasons to exclude it.
Release tracks and review
Google offers internal, closed, open, and production tracks. A sensible first launch path:
- Internal testing with up to 100 testers
- Closed testing with real users or client staff
- Production at 5–10% staged rollout
- Increase to 100% after crash-free sessions look stable
First production submissions often pass within 24–48 hours. Updates to the same app are usually quicker unless you change permissions or target API level.
Native app vs PWA vs hybrid: which path fits your project?
Not every product needs store presence on day one. I regularly recommend a progressive web app first when the client needs mobile reach without Rs 500,000+ native budgets. Stores add discovery, push on iOS (with limits), and payment rails—but also 30% fees on digital goods and ongoing review cycles.
| Criteria | Native (Swift/Kotlin) | Hybrid (Capacitor, Flutter WebView) | PWA |
|---|---|---|---|
| Time to first release | 3–6 months typical | 4–10 weeks | 1–4 weeks |
| Store submission required | Yes | Yes | No |
| Offline support | Excellent | Moderate | Good with service workers |
| Push notifications (iOS) | Full APNs | Full via plugins | Limited until installed to home screen |
| Backend fit for Laravel shops | Sanctum/Passport API | Same API + deep links | Same origin or API + CORS |
| Annual store cost | ~USD 124 both stores | ~USD 124 both stores | Rs 0 store fees |
For WooCommerce storefronts, read the WooCommerce REST API guide before wrapping the shop in a hybrid shell. Product images, cart state, and checkout redirects need careful handling. Payment gateways often require WebView or SFSafariViewController flows that store reviewers scrutinise.
Custom software projects I scope usually start with API contracts and auth. Mobile UI comes second. That order prevents rework when Apple asks for account deletion or Google flags missing Data safety declarations.
What backend work must finish before store launch?
Store approval means nothing if login fails under load. Treat mobile as a hostile client—slow networks, old OS versions, and aggressive battery savers.
API design for mobile clients
Mobile apps cache aggressively. Design idempotent writes and clear error codes. Return structured JSON errors, not HTML stack traces.
// Laravel 13 API route example — versioned, paginated
Route::prefix('api/v1')->middleware('auth:sanctum')->group(function () {
Route::get('/bookings', [BookingController::class, 'index']);
Route::post('/bookings', [BookingController::class, 'store'])
->middleware('throttle:60,1');
});
// Response shape mobile clients expect
{
"data": [...],
"meta": { "current_page": 1, "last_page": 5 },
"links": { "next": "https://api.example.com/api/v1/bookings?page=2" }
}Validate payloads with Form Requests. Never trust client-side validation alone. Use JSON formatting tools during contract reviews with your mobile developer.
Security, auth, and compliance
Follow mobile app security basics: certificate pinning where appropriate, secure token storage on device, and short-lived access tokens. Implement account deletion if you allow registration—Apple requires it for apps that support account creation.
Nepali-language apps need proper Unicode handling on API responses. Test with our Nepali Unicode converter samples to catch encoding bugs before review.
Push notifications and deep links
If your product depends on alerts—booking confirmations, order updates—plan APNs and Firebase Cloud Messaging early. Backend jobs should queue notification payloads, not send synchronously during HTTP requests. See the push notifications guide for Laravel queue patterns.
Deep links (Universal Links on iOS, App Links on Android) need hosted apple-app-site-association and assetlinks.json files on your domain. Configure them on the same server that hosts your API docs.
What causes App Store and Play Store rejections?
Rejections delay launches and burn stakeholder trust. Most are preventable with a pre-submission checklist.
Apple-specific rejection patterns
- Guideline 2.1 — App Completeness: Crashes, broken links, or empty screens during review
- Guideline 4.2 — Minimum Functionality: Apps that are mostly repackaged websites without native value
- Guideline 5.1.1 — Privacy: Missing purpose strings in Info.plist for camera, location, or photos
- Guideline 3.1.1 — In-App Purchase: Digital goods sold outside Apple's IAP system
Hybrid apps face 4.2 scrutiny often. Add meaningful native features—biometric login, offline cache, or widgets—before submission.
Google Play policy hits
- Data safety form does not match actual SDK behaviour
- Target API level below current Play requirements
- Misleading store listing versus in-app experience
- Background location without clear user benefit
Run QA and optimisation passes on real devices, not only emulators. Budget Android fragmentation is worse in Nepal's used-phone market than in Western test labs.
Launch checklist both stores share
- Privacy policy live at a stable HTTPS URL
- Terms of service linked from app settings
- Working customer support email or form
- Analytics and crash reporting disclosed in privacy forms
- Version numbering scheme documented for the team
- Rollback plan if a bad build reaches production
- Post-launch monitoring for API 5xx spikes
Plan research upfront with planning and research services if stakeholders disagree on native versus PWA. Changing direction after store assets are built wastes design and copy work.
Key Takeaways
- Enroll in Apple Developer Program (USD 99/year) and Google Play Console (USD 25 one-time) before you publish to the App Store and Play Store.
- Ship a stable, versioned API with auth, pagination, and privacy-compliant data handling before you submit store builds.
- Use TestFlight and Play internal tracks for at least one beta cycle—reviewers and users should not find your first crash.
- Provide demo credentials, a live privacy policy, and accurate Data safety or App Privacy answers to avoid preventable rejections.
- Consider a PWA or hybrid path first if budget is tight; native store apps earn their cost through UX and device integration.
- Stage Google Play rollouts at 5–10% and watch crash-free rates before full release.
People Also Ask
How long does it take to publish to the App Store and Play Store?
Account setup takes one to three days if Apple organisation verification is required. First Google Play production review often completes within 24–48 hours. Apple App Store review typically takes one to three business days. Subsequent updates are usually faster unless you change permissions, pricing, or encryption declarations.
Do I need separate apps for iOS and Android?
Yes for fully native apps—you maintain Swift or Objective-C for iOS and Kotlin or Java for Android. Cross-platform frameworks like Flutter or React Native produce one codebase with two store binaries. Hybrid tools like Capacitor wrap a single web UI. Your Laravel or WordPress API stays shared across all approaches.
Can I publish a web app without the app stores?
Yes. A progressive web app installs from the browser and skips store review entirely. You lose store search discovery and face iOS push limitations. Many Nepal SMBs start with a PWA, then add store apps once revenue justifies USD 124 in annual fees plus development cost.
What happens if my app gets rejected?
Both stores send a reason code and reviewer notes. Fix the issue, increment the build number, and resubmit. Apple allows replying in App Store Connect Resolution Center if you disagree. Google Play offers an appeal form for policy disputes. Document each rejection—patterns repeat across updates.
Ship your mobile product with the backend done right
Store submission is the last mile, not the whole journey. The teams that launch cleanly align mobile builds with a tested API, honest privacy disclosures, and realistic beta feedback. Whether you go native, hybrid, or PWA first, the backend patterns are the same ones I use on production Laravel and eCommerce systems. If you need help scoping the API, auth, and deployment side before you publish to the App Store and Play Store, review our enterprise application development and mobile-ready eCommerce work, then contact us to talk through your release plan.
Frequently Asked Questions
Start with delivery model choice—native, hybrid, or PWA—not Xcode or Android Studio. Enroll in Apple Developer Program and Google Play Console, then confirm your backend is stable. Most apps I support are thin clients over a Laravel or WordPress API with HTTPS, token auth, pagination, and versioned paths. Both stores require a public privacy policy URL listing every third party receiving user data. Fix API errors on slow networks before you polish screenshots; mobile clients hit the same endpoints under worse conditions than browser tests.
Apple costs USD 99 per year (~Rs 13,000). Google Play charges USD 25 once. Combined annual store fees are roughly USD 124, paid via international card in Nepal.
Google Play first review: 24–48 hours. Apple App Store: one to three business days. Apple organisation account setup may add one to three extra days.
Create an App ID, provisioning profile, and distribution certificate in Apple Developer portal, then match the bundle identifier in Xcode. Bump CFBundleShortVersionString and CFBundleVersion for every upload, archive the release build, and upload via Xcode Organizer or CI tools like Fastlane deliver. Complete App Store Connect with screenshots, description, App Privacy questionnaire, and export compliance answers. Provide demo login credentials if content is gated. Upload to TestFlight first—builds appear in 15–30 minutes—run at least one external beta cycle, then submit the build for production review.
Create the app in Play Console, generate an upload keystore with keytool, and register it—Google Play App Signing is mandatory for new apps. Build a signed Android App Bundle with gradlew bundleRelease, never committing the keystore to Git. Complete the store listing with icon, feature graphic, screenshots, privacy policy link, and IARC content rating. Release through internal testing first, then closed testing, then production with a 5–10% staged rollout. Increase to 100% only after crash-free sessions look stable. First production submissions often pass within 24–48 hours.
Yes for fully native apps—you maintain Swift or Objective-C for iOS and Kotlin or Java for Android as separate codebases producing two store binaries. Cross-platform frameworks like Flutter or React Native compile one codebase into two binaries. Hybrid tools like Capacitor wrap a single web UI in a native shell for both stores. Your Laravel or WordPress REST API stays shared across all three approaches, which is why I scope API contracts and auth before mobile UI on most client projects.
Yes—a progressive web app installs from the browser and skips store review, listing paperwork, and the USD 99 Apple plus USD 25 Google fees entirely. The trade-off is weaker store discovery and limited iOS push until users add the PWA to their home screen. On client projects with tight budgets, I often recommend PWA first when Rs 500,000-plus native development is not yet justified. Your Laravel or WordPress API stays the same; only the client shell changes.
Native Swift or Kotlin delivers the best device access but typically needs three to six months. Hybrid tools like Capacitor or Flutter WebView ship in four to ten weeks by wrapping your web UI. A PWA reaches users in one to four weeks with no store fees but loses store discovery and full iOS push. All three call the same versioned API with Sanctum or Passport auth. Stores also add roughly 30% fees on digital goods and ongoing review cycles. Compare paths before committing design and copy work you may discard if direction changes.
Store approval means nothing if login fails under load. Confirm HTTPS everywhere, token auth with refresh flows, pagination and rate limits on list endpoints, and versioned API paths such as /api/v1/orders. Return structured JSON errors, not HTML stack traces, and validate payloads with Laravel Form Requests. Implement account deletion if registration is supported—Apple requires it. Plan push notification queue jobs rather than sending synchronously during HTTP requests. Configure deep link files—apple-app-site-association and assetlinks.json—on the same domain hosting your API. Load-test staging before reviewers and early users hit production.
Most rejections are preventable metadata, privacy, or demo-access failures—not code quality alone. Apple commonly rejects under Guideline 2.1 for crashes or broken links, 4.2 for repackaged websites without native value, 5.1.1 for missing Info.plist purpose strings, and 3.1.1 for digital goods sold outside In-App Purchase. Google flags Data safety forms that do not match SDK behaviour, target API levels below current Play requirements, misleading store listings, and background location without clear user benefit. Hybrid apps face Apple 4.2 scrutiny often—add biometric login, offline cache, or widgets before submission.
Both stores send a reason code and reviewer notes explaining the failure. Treat Apple feedback as a checklist, not a surprise—fix the cited issue, increment the build number, and resubmit. Common fixes include adding demo credentials for gated content, correcting App Privacy or Data safety answers, and filling missing purpose strings for camera or location permissions. Subsequent resubmissions are usually faster unless you change permissions, pricing, or encryption declarations. Budget stakeholder time for at least one rejection cycle on first Apple submissions.
Both Apple and Google require a public privacy policy at a stable HTTPS URL before submission. List every third party receiving user data—analytics, crash reporting, and payment gateways like eSewa or Khalti. Complete Apple's App Privacy questionnaire declaring data collected and linked to the user. Complete Google's Data safety form so it accurately matches actual SDK behaviour—mismatches trigger policy strikes. Nepal-facing apps should also respect local data rules. Link terms of service from app settings and provide a working customer support email or form reviewers can verify.
TestFlight is Apple's beta distribution channel inside App Store Connect. Uploaded builds appear within 15–30 minutes. Internal testers see builds immediately; external testers require a brief beta review before access. Run at least one external beta cycle before your first production submission so reviewers and early users do not discover your first crash. TestFlight catches broken login flows, empty screens, and server dependency issues that trigger Guideline 2.1 rejections. It is not optional polish—it is cheap insurance against a one-to-three-day review delay.
Google Play lets you release to internal, closed, open, or production tracks. A sensible first launch path starts with internal testing up to 100 testers, moves to closed testing with real users or client staff, then promotes to production at 5–10% staged rollout. Monitor crash-free session rates before increasing to 100%. This limits damage if a bad build reaches real users. Updates to the same app pass faster unless you change permissions or target API level. First production submissions often clear within 24–48 hours.
Before submitting either store build, confirm a live privacy policy URL, terms of service linked from app settings, and a working support email or form. Disclose analytics and crash reporting accurately in privacy forms. Document your version numbering scheme for the team and define a rollback plan if a bad build reaches production. Provide demo credentials for any gated content on Apple. Run QA on real devices—not only emulators—because budget Android fragmentation in Nepal's used-phone market exceeds what Western test labs typically cover. Monitor API 5xx spikes immediately after release.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
