feat: whyrating - initial project from turbostarter boilerplate
This commit is contained in:
Alejandro Gutiérrez
@@ -0,0 +1,164 @@
|
||||
---
|
||||
title: Google Play (Android)
|
||||
description: Learn how to publish your mobile app to the Google Play Store.
|
||||
url: /docs/mobile/publishing/android
|
||||
---
|
||||
|
||||
# Google Play (Android)
|
||||
|
||||
[Google Play](https://play.google.com/) is the primary platform for distributing Android apps to billions of users worldwide. It's a powerful marketplace that allows you to reach a large audience and monetize your app.
|
||||
|
||||
To submit your app to the Play Store, you'll need to follow a series of steps. We'll walk through those steps here.
|
||||
|
||||
<Callout title="Prerequisite" type="warn">
|
||||
Before you submit, review the publishing [guidelines](/docs/mobile/marketing) and confirm that your app meets Google's policies to avoid common rejections.
|
||||
</Callout>
|
||||
|
||||
## Developer account
|
||||
|
||||
A Google Play Developer account is required to submit your app to the Google Play Store. You can sign up on the [Google Play Console](https://play.google.com/console/) and pay the one-time registration fee.
|
||||
|
||||
|
||||
|
||||
To publish apps to Google Play, you must verify your identity. See the [official guide](https://support.google.com/googleplay/android-developer/answer/14177239) for more information. Next, you'll need to create a new app in the [Google Play Console](https://play.google.com/apps/publish/) by clicking the *Create app* button.
|
||||
|
||||
## Submission
|
||||
|
||||
After registering your developer account, setting it up, and preparing your app, you're ready to publish it to the Play Store.
|
||||
|
||||
There are multiple ways to submit your app:
|
||||
|
||||
* **Manual submission:** Upload your app bundle directly to the Play Store via the Play Console.
|
||||
* **Local submission:** Use [EAS CLI](https://github.com/expo/eas-cli) to submit your app.
|
||||
* **CI/CD submission:** Use ready-to-use GitHub Actions workflow to automatically submit your app.
|
||||
|
||||
**The first submission must be done manually, while subsequent updates can be submitted automatically.** We'll go through each approach in detail below.
|
||||
|
||||
### Manual submission
|
||||
|
||||
This approach is not recommended, as it is more error-prone and time-consuming due to manual steps. However, it's still the **only way to submit your app for the first time**. You can also use this route if you need to upload a build without EAS Submit (for example, during service maintenance) or if you prefer a fully manual flow.
|
||||
|
||||
**Create the app entry in Google Play Console**
|
||||
|
||||
1. Visit [Google Play Console](https://play.google.com/console/) and sign in. Accept any pending agreements if prompted.
|
||||
2. Click *Create app*, then enter your app name, default language, app type, and pricing (free/paid). Confirm policy declarations.
|
||||
3. Finish initial setup tasks (App access, Ads, Content rating, Target audience, Data safety, Privacy policy URL).
|
||||
|
||||
**Upload the `.aab` file to a track (internal/closed/open/production)**
|
||||
|
||||
1. The fastest route for a first upload is often *Internal testing*. Go to *Internal testing* → *Releases* (or choose *Closed/Open/Production*), then click *Create new release*.
|
||||
2. Upload the `.aab` file, add release notes, and review any warnings.
|
||||
3. Save and continue through the checks until you're ready to submit for review or roll out to [testers](https://play.google.com/console/about/internal-testing/).
|
||||
|
||||
**Verify and submit for review**
|
||||
|
||||
1. Complete Store listing assets and metadata if not already done.
|
||||
2. Resolve any policy warnings. When ready, start the rollout to request a [review](/docs/mobile/publishing/android#review).
|
||||
|
||||
After your first manual upload is accepted, you can use [Local submission](/docs/mobile/publishing/android#local-submission) or [CI/CD submission](/docs/mobile/publishing/android#cicd-submission-recommended) for subsequent releases.
|
||||
|
||||
For more information, please refer to the guides listed below.
|
||||
|
||||
<Cards>
|
||||
<Card title="First Android submission" url="https://github.com/expo/fyi/blob/main/first-android-submission.md" description="expo.fyi" />
|
||||
|
||||
<Card title="Create and set up your app" url="https://support.google.com/googleplay/android-developer/answer/9859152" description="google.com" />
|
||||
</Cards>
|
||||
|
||||
### Local submission
|
||||
|
||||
<Callout title="First submission must be done manually" type="warn">
|
||||
Due to Google Play API limitations, you must upload your app to Google Play **manually at least once** (to any track: internal, closed, open, or production) before automated submissions will work. See the detailed walkthrough in the ["First Android submission" guide](https://github.com/expo/fyi/blob/main/first-android-submission.md).
|
||||
</Callout>
|
||||
|
||||
First, you need to **upload and configure a Google Service Account Key with EAS**. This is the required first step to submit your Android app to the Google Play Store. Follow the [guide on uploading a Google Service Account Key for Play Store submissions with EAS](https://github.com/expo/fyi/blob/main/creating-google-service-account.md) for detailed instructions.
|
||||
|
||||
Next, you have to get your app bundle — if you followed the [checklist](/docs/mobile/publishing/checklist), you should have the `.aab` file in your app folder from the [build step](/docs/mobile/publishing/checklist#build-your-app). If you used GitHub Actions to build your app, you can find the results in the `Builds` tab of your [EAS project](https://expo.dev). Download the artifacts and save them on your local machine.
|
||||
|
||||
Then, navigate to your app folder and run the following command to submit your app to the Play Store:
|
||||
|
||||
```bash
|
||||
eas submit --platform android
|
||||
```
|
||||
|
||||
The command will guide you through the submission process. You can also configure the steps of the submission process by adding a submission profile in `eas.json`.
|
||||
|
||||
<Callout>
|
||||
If you upload your Google Service Account key to EAS credentials, you do not need to reference a local file path anywhere.
|
||||
</Callout>
|
||||
|
||||
To speed up the submission process, you can use the `--auto-submit` flag to automatically submit a build after it is built:
|
||||
|
||||
```bash
|
||||
eas build --platform android --auto-submit
|
||||
```
|
||||
|
||||
This will automatically submit the build with all the required credentials to the Play Store right after it is built.
|
||||
|
||||
<Cards>
|
||||
<Card title="Automate submissions" description="docs.expo.dev" href="https://docs.expo.dev/build/automate-submissions/" />
|
||||
|
||||
<Card title="Creating a Google Service Account" description="expo.fyi" href="https://github.com/expo/fyi/blob/main/creating-google-service-account.md" />
|
||||
|
||||
<Card title="eas.json reference" description="docs.expo.dev" href="https://docs.expo.dev/eas/json/#android-specific-options-1" />
|
||||
</Cards>
|
||||
|
||||
### CI/CD submission (recommended)
|
||||
|
||||
<Callout title="First submission must be done manually" type="warn">
|
||||
Due to Google Play API limitations, you must upload your app to Google Play **manually at least once** (to any track: internal, closed, open, or production) before automated submissions will work. See the detailed walkthrough in the ["First Android submission" guide](https://github.com/expo/fyi/blob/main/first-android-submission.md).
|
||||
</Callout>
|
||||
|
||||
TurboStarter comes with a pre-configured GitHub Actions workflow to automatically submit your mobile app to the Play Store. You'll find the workflow in the `.github/workflows/publish-mobile.yml` file.
|
||||
|
||||
To use this workflow, [upload your Google Play Service Account key to EAS](https://github.com/expo/fyi/blob/main/creating-google-service-account.md) and check your Android credentials setup by running:
|
||||
|
||||
```bash
|
||||
eas credentials --platform android
|
||||
```
|
||||
|
||||
This way, you avoid storing the JSON key in your repository or CI/CD provider.
|
||||
|
||||
<Callout title="Don't forget to set EXPO_TOKEN">
|
||||
This workflow also requires a [personal access token](https://docs.expo.dev/accounts/programmatic-access/#personal-access-tokens) for your Expo account. Add it as `EXPO_TOKEN` in your [GitHub repository secrets](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions), which will allow the `eas submit` command to run.
|
||||
</Callout>
|
||||
|
||||
That's it! After completing these steps, [trigger the workflow](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow) to submit your new build to the Play Store automatically 🎉
|
||||
|
||||
<Cards>
|
||||
<Card title="Automate submissions" description="docs.expo.dev" href="https://docs.expo.dev/build/automate-submissions/" />
|
||||
|
||||
<Card title="Creating a Google Service Account" description="expo.fyi" href="https://github.com/expo/fyi/blob/main/creating-google-service-account.md" />
|
||||
|
||||
<Card title="eas.json reference" description="docs.expo.dev" href="https://docs.expo.dev/eas/json/#android-specific-options-1" />
|
||||
</Cards>
|
||||
|
||||
## Review
|
||||
|
||||
After filling out the information about your item, you're ready to submit it for review. Click on the *Send for review* button and confirm that you want to proceed with the submission:
|
||||
|
||||
|
||||
|
||||
To control **when** your app is released after review, you can configure [Managed publishing](https://support.google.com/googleplay/android-developer/answer/9859654) in the Google Play Console.
|
||||
|
||||
After submitting your app for review, it will enter Google's review process. The review time may vary depending on your app, and you'll receive a notification when the status updates. For more details, check out the [Google Play Review Process](https://developers.google.com/workspace/marketplace/about-app-review) documentation.
|
||||
|
||||
<Callout title="Your submission might be rejected" type="error">
|
||||
If your submission is rejected, you'll receive an email from Google with the rejection reason. You'll need to fix the issues and upload a new version of your app.
|
||||
|
||||
|
||||
|
||||
Make sure to follow the [guidelines](/docs/mobile/marketing) or check [publishing troubleshooting](/docs/mobile/troubleshooting/publishing) for more info.
|
||||
</Callout>
|
||||
|
||||
When your app is approved by Google, you'll be able to publish it on the Play Store.
|
||||
|
||||
|
||||
|
||||
You can learn more about the review process in the official guides listed below.
|
||||
|
||||
<Cards>
|
||||
<Card title="App review process" description="google.com" href="https://developers.google.com/workspace/marketplace/about-app-review" />
|
||||
|
||||
<Card title="Google Play branding guidelines" description="google.com" href="https://developers.google.com/workspace/marketplace/terms/branding" />
|
||||
</Cards>
|
||||
@@ -0,0 +1,212 @@
|
||||
---
|
||||
title: Checklist
|
||||
description: Let's publish your TurboStarter app to stores!
|
||||
url: /docs/mobile/publishing/checklist
|
||||
---
|
||||
|
||||
# Checklist
|
||||
|
||||
When you're ready to publish your TurboStarter app to stores, follow this checklist.
|
||||
|
||||
This process may take a few hours and some trial and error, so buckle up - you're almost there!
|
||||
|
||||
<Steps>
|
||||
<Step>
|
||||
## Create database instance
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
A production-ready database instance is essential for storing your application's data securely and reliably in the cloud. [PostgreSQL](https://www.postgresql.org/) is the recommended database for TurboStarter due to its robustness, features, and wide support.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
You have several options for hosting your PostgreSQL database:
|
||||
|
||||
* [Supabase](/docs/mobile/recipes/supabase) - Provides a fully managed Postgres database with additional features
|
||||
* [Vercel Postgres](https://vercel.com/storage/postgres) - Serverless SQL database optimized for Vercel deployments
|
||||
* [Neon](https://neon.tech/) - Serverless Postgres with automatic scaling
|
||||
* [Turso](https://turso.tech/) - Edge database built on libSQL with global replication
|
||||
* [DigitalOcean](https://www.digitalocean.com/products/managed-databases) - Managed database clusters with automated failover
|
||||
|
||||
Choose a provider based on your needs for:
|
||||
|
||||
* Pricing and budget
|
||||
* Geographic region availability
|
||||
* Scaling requirements
|
||||
* Additional features (backups, monitoring, etc.)
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## Migrate database
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Pushing database migrations ensures that your database schema in the remote database instance is configured to match TurboStarter's requirements. This step is crucial for the application to function correctly.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
You basically have two possibilities of doing a migration:
|
||||
|
||||
<Tabs items={["Using Github Actions (recommended)", "Running locally"]}>
|
||||
<Tab value="Using Github Actions (recommended)">
|
||||
TurboStarter comes with predefined Github Action to handle database migrations. You can find its definition in the `.github/workflows/publish-db.yml` file.
|
||||
|
||||
What you need to do is to set your `DATABASE_URL` as a [secret for your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).
|
||||
|
||||
Then, you can run the workflow which will publish the database schema to your remote database instance.
|
||||
|
||||
[Check how to run Github Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
|
||||
</Tab>
|
||||
|
||||
<Tab value="Running locally">
|
||||
You can also run your migrations locally, although this is not recommended for production.
|
||||
|
||||
To do so, set the `DATABASE_URL` environment variable to your database URL (that comes from your database provider) in `.env.local` file and run the following command:
|
||||
|
||||
```bash
|
||||
pnpm with-env pnpm --filter @turbostarter/db db:migrate
|
||||
```
|
||||
|
||||
This command will run the migrations and apply them to your remote database.
|
||||
|
||||
[Learn more about database migrations.](/docs/web/database/migrations)
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## (Optional) Set up Firebase project
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Setting up a Firebase project is optional, and depends on which features your app is using. For example, if you want to use [Analytics](/docs/mobile/analytics/overview) with [Google Analytics](/docs/mobile/analytics/configuration#google-analytics), setting up a Firebase project is required.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
Please refer to the [Firebase project](/docs/mobile/installation/firebase) section on how to set up and configure your Firebase project.
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## Set up web backend API
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Setting up the backend is necessary to have a place to store your data and to have other features work properly (e.g. authentication, billing or storage).
|
||||
|
||||
**How to do it?**
|
||||
|
||||
Please refer to the [web deployment checklist](/docs/web/deployment/checklist) on how to set up and deploy the web app backend to production.
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## Environment variables
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Setting the correct environment variables is essential for the application to function correctly. These variables include API keys, database URLs, and other configuration details required for your app to connect to various services.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
Use our `.env.example` files to get the correct environment variables for your project. Then add them to your project on the [EAS platform](https://docs.expo.dev/eas/environment-variables/) for correct profile and environment:
|
||||
|
||||
|
||||
|
||||
Alternatively, you can add them to your `eas.json` file under correct profile.
|
||||
|
||||
```json title="eas.json"
|
||||
{
|
||||
"profiles": {
|
||||
"base": {
|
||||
"env": {
|
||||
"EXPO_PUBLIC_DEFAULT_LOCALE": "en",
|
||||
"EXPO_PUBLIC_AUTH_PASSWORD": "true",
|
||||
"EXPO_PUBLIC_AUTH_MAGIC_LINK": "false",
|
||||
"EXPO_PUBLIC_THEME_MODE": "system",
|
||||
"EXPO_PUBLIC_THEME_COLOR": "orange"
|
||||
}
|
||||
},
|
||||
"production": {
|
||||
"extends": "base",
|
||||
"autoIncrement": true,
|
||||
"env": {
|
||||
"APP_ENV": "production",
|
||||
"EXPO_PUBLIC_SITE_URL": "https://www.turbostarter.dev",
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## Build your app
|
||||
|
||||
<Callout title="Prerequisite: EAS account">
|
||||
Building your app requires an EAS account and project. If you don't have one, you can create it by following the steps [here](https://expo.dev/eas).
|
||||
</Callout>
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Building your app is necessary to create a standalone application bundle that can be published to the stores.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
You basically have two possibilities to build a bundle for your app:
|
||||
|
||||
<Tabs items={["Using Github Actions (recommended)", "Running locally"]}>
|
||||
<Tab value="Using Github Actions (recommended)">
|
||||
TurboStarter comes with predefined Github Action to handle building your app on EAS. You can find its definition in the `.github/workflows/publish-mobile.yml` file.
|
||||
|
||||
What you need to do is to set your `EXPO_TOKEN` as a [secret for your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). You can obtain it from your EAS account, in the [Access Tokens](https://expo.dev/settings/access-tokens) section.
|
||||
|
||||
Then, you can run the workflow which will build the app on [EAS platform](https://expo.dev/eas).
|
||||
|
||||
[Check how to run Github Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
|
||||
</Tab>
|
||||
|
||||
<Tab value="Running locally">
|
||||
You can also run your build locally, although this is not recommended for production.
|
||||
|
||||
To do it, you'll need to have [EAS CLI](https://github.com/expo/eas-cli) installed on your machine. You can install it by running the following command:
|
||||
|
||||
```bash
|
||||
npm install -g eas-cli
|
||||
```
|
||||
|
||||
Then, run the following command to build your app with the `production` profile:
|
||||
|
||||
```bash
|
||||
eas build --profile production --platform all
|
||||
```
|
||||
|
||||
This will build the app for both platforms (iOS and Android) and output the results in your app folder.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
## Submit to stores
|
||||
|
||||
**Why it's necessary?**
|
||||
|
||||
Releasing your app to the stores is essential for making it accessible and discoverable by your users. This allows users to find, install, and trust your application through official channels.
|
||||
|
||||
**How to do it?**
|
||||
|
||||
We've prepared dedicated guides for each store that TurboStarter supports out-of-the-box, please refer to the following pages:
|
||||
|
||||
<Cards>
|
||||
<Card title="App Store" href="/docs/mobile/publishing/ios" description="Publish your app to the Apple App Store." />
|
||||
|
||||
<Card title="Google Play" href="/docs/mobile/publishing/android" description="Publish your app to the Google Play Store." />
|
||||
</Cards>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
That's it! Your app is now live and accessible to your users, good job! 🎉
|
||||
|
||||
<Callout title="Other things to consider">
|
||||
* Optimize your store listings with compelling descriptions, keywords, screenshots and preview videos
|
||||
* Remove placeholder content and replace with your final production content
|
||||
* Update all visual branding including favicon, scheme, splash screen and app icons
|
||||
</Callout>
|
||||
@@ -0,0 +1,215 @@
|
||||
---
|
||||
title: App Store (iOS)
|
||||
description: Learn how to publish your mobile app to the Apple App Store.
|
||||
url: /docs/mobile/publishing/ios
|
||||
---
|
||||
|
||||
# App Store (iOS)
|
||||
|
||||
[Apple App Store](https://www.apple.com/app-store/) is the primary platform for distributing iOS apps, making them available on iPhones, iPads, and other Apple devices to millions of users worldwide.
|
||||
|
||||
To submit your app to the App Store, you'll need to follow a series of steps. We'll walk through those steps here.
|
||||
|
||||
<Callout title="Prerequisite" type="warn">
|
||||
Before you submit, review the publishing [guidelines](/docs/mobile/marketing) and confirm that your app meets Apple's policies to avoid common rejections.
|
||||
</Callout>
|
||||
|
||||
## Developer account
|
||||
|
||||
An Apple Developer account is required to submit your app to the Apple App Store. You can sign up for an Apple Developer account on the [Apple Developer Portal](https://developer.apple.com/account/).
|
||||
|
||||
|
||||
|
||||
To submit apps to the App Store, you must also be a member of the Apple Developer Program. You can join the program by paying the annual fee.
|
||||
|
||||
## Submission
|
||||
|
||||
There are two primary ways to submit your iOS app to the App Store:
|
||||
|
||||
* **Manual:** Uploading the build yourself through Apple's tools, such as [Transporter](https://apps.apple.com/app/transporter/id1450874784) or [Xcode](https://developer.apple.com/xcode/).
|
||||
* **Automatic (recommended):** Using [EAS Submit](/docs/mobile/publishing/ios#local-submission) or [CI/CD](/docs/mobile/publishing/ios#cicd-submission-recommended), which simplifies the process, ensures consistency, and reduces manual error.
|
||||
|
||||
Below, you'll find guidance for both submission methods—choose the one that fits your workflow and project needs.
|
||||
|
||||
### Manual submission
|
||||
|
||||
This approach is not recommended, as it is more error-prone and time-consuming due to manual steps. Use this route if you need to upload a build without EAS Submit (for example, during service maintenance) or prefer a fully manual flow from macOS.
|
||||
|
||||
**Create the app entry in App Store Connect**
|
||||
|
||||
1. Visit [App Store Connect](https://appstoreconnect.apple.com/) and sign in. Accept any pending agreements if prompted.
|
||||
2. From Apps, click the + button and select *New App*.
|
||||
3. Enter the app name, primary language, bundle identifier, and a unique SKU (for example, your bundle ID, such as `com.company.myapp`).
|
||||
4. Press Create to finish setting up the app record.
|
||||
|
||||
**Upload the IPA with Transporter**
|
||||
|
||||
1. Install [Apple's Transporter](https://apps.apple.com/app/transporter/id1450874784) from the Mac App Store.
|
||||
2. Open Transporter and sign in with your Apple ID.
|
||||
3. Drag the `.ipa` into Transporter (or click *Add App* to choose the file).
|
||||
4. Press *Deliver* to upload. Transfer time varies by file size and network.
|
||||
|
||||
**Verify processing and select the build**
|
||||
|
||||
1. Once uploaded, Apple processes the binary (often 10-20 minutes).
|
||||
2. Back in [App Store Connect](https://appstoreconnect.apple.com/), open My Apps and select your app.
|
||||
3. Under the *App Store* tab, select the new build in the *Build* section. If it's missing, wait and refresh.
|
||||
4. Proceed with the usual App Store steps (screenshots, metadata, compliance, then submit for review).
|
||||
|
||||
For more information about the required metadata, refer to the official guides.
|
||||
|
||||
<Cards>
|
||||
<Card title="Submitting" url="https://developer.apple.com/app-store/submitting/" description="developer.apple.com" />
|
||||
|
||||
<Card title="App Information" url="https://developer.apple.com/help/app-store-connect/reference/app-information/" description="developer.apple.com" />
|
||||
</Cards>
|
||||
|
||||
### Local submission
|
||||
|
||||
If you followed the [checklist](/docs/mobile/publishing/checklist), you should have the `.ipa` file in your app folder from the [build step](/docs/mobile/publishing/checklist#build-your-app). If you used GitHub Actions to build your app, you can find the results in the `Builds` tab of your [EAS project](https://expo.dev). Download the artifacts and save them on your local machine.
|
||||
|
||||
Then, navigate to your app folder and run the following command to submit your app to the App Store:
|
||||
|
||||
```bash
|
||||
eas submit --platform ios
|
||||
```
|
||||
|
||||
The command will guide you through the submission process. You can configure the submission process by adding a submission profile in `eas.json`:
|
||||
|
||||
```json title="eas.json"
|
||||
{
|
||||
"submit": {
|
||||
"production": {
|
||||
"ios": {
|
||||
"ascAppId": "your-app-store-connect-app-id"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Accordions>
|
||||
<Accordion title="How to find ascAppId?">
|
||||
1. Sign in to [App Store Connect](https://appstoreconnect.apple.com/) and choose your team.
|
||||
2. Open the [Apps](https://appstoreconnect.apple.com/apps) area.
|
||||
3. Select your app from the list.
|
||||
4. Switch to the *App Store* tab.
|
||||
5. Go to *General* → *App Information*.
|
||||
6. In *General Information*, the value labeled *Apple ID* is your `ascAppId`.
|
||||
|
||||
|
||||
</Accordion>
|
||||
</Accordions>
|
||||
|
||||
To speed up the submission process, you can use the `--auto-submit` flag to automatically submit a build after it is built:
|
||||
|
||||
```bash
|
||||
eas build --platform ios --auto-submit
|
||||
```
|
||||
|
||||
This will automatically submit the build with all the required credentials to the App Store right after it is built.
|
||||
|
||||
<Cards>
|
||||
<Card title="eas.json reference" description="docs.expo.dev" href="https://docs.expo.dev/eas/json/#ios-specific-options-1" />
|
||||
|
||||
<Card title="Automate submissions" description="docs.expo.dev" href="https://docs.expo.dev/build/automate-submissions/" />
|
||||
</Cards>
|
||||
|
||||
### CI/CD submission (recommended)
|
||||
|
||||
TurboStarter comes with a pre-configured GitHub Actions workflow to submit your mobile app to the App Store automatically. It's located in the `.github/workflows/publish-mobile.yml` file.
|
||||
|
||||
To be able to use this workflow, you'd need to fulfill the following prerequisites:
|
||||
|
||||
1. **Configure your App Store Connect API Key**
|
||||
|
||||
Run the following command to configure your App Store Connect API Key:
|
||||
|
||||
```bash
|
||||
eas credentials --platform ios
|
||||
```
|
||||
|
||||
The command will prompt you to configure credentials:
|
||||
|
||||
1. Choose the `production` build profile.
|
||||
2. Authenticate with your Apple Developer account and proceed through the prompts.
|
||||
3. Pick **App Store Connect → Manage your API Key**.
|
||||
4. Enable **Use an API Key for EAS Submit** for the project.
|
||||
|
||||
2. **Provide a submission profile in `eas.json`**
|
||||
|
||||
Next, add a submission profile in `eas.json` with the following:
|
||||
|
||||
```json title="eas.json"
|
||||
{
|
||||
"submit": {
|
||||
"production": {
|
||||
"ios": {
|
||||
"ascAppId": "your-app-store-connect-app-id"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Accordions>
|
||||
<Accordion title="How to find ascAppId?">
|
||||
1) Log into [App Store Connect](https://appstoreconnect.apple.com/) under the correct team.
|
||||
2) Go to [Apps](https://appstoreconnect.apple.com/apps) and open your app.
|
||||
3) Ensure the *App Store* tab is selected.
|
||||
4) Navigate to *General* → *App Information*.
|
||||
5) Copy the value shown as *Apple ID* — that is the `ascAppId`.
|
||||
|
||||
|
||||
</Accordion>
|
||||
</Accordions>
|
||||
|
||||
<Callout title="Don't forget to set EXPO_TOKEN">
|
||||
This workflow also requires a [personal access token](https://docs.expo.dev/accounts/programmatic-access/#personal-access-tokens) for your Expo account. Add it as `EXPO_TOKEN` in your [GitHub repository secrets](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions), which will allow the `eas submit` command to run.
|
||||
</Callout>
|
||||
|
||||
That's it! After completing these steps, [trigger the workflow](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow) to submit your new build to the App Store automatically 🎉
|
||||
|
||||
<Cards>
|
||||
<Card title="eas.json reference" description="docs.expo.dev" href="https://docs.expo.dev/eas/json/#ios-specific-options-1" />
|
||||
|
||||
<Card title="Automate submissions" description="docs.expo.dev" href="https://docs.expo.dev/build/automate-submissions/" />
|
||||
</Cards>
|
||||
|
||||
## Review
|
||||
|
||||
After completing your app information, you're ready to submit it for review. Click the *Add for review* button and confirm that you want to proceed with the submission:
|
||||
|
||||
|
||||
|
||||
On the *Distribution* tab, you can configure the release process after the review is complete — whether you want to release the app automatically after review, later, or manually.
|
||||
|
||||
|
||||
|
||||
Once you've submitted your app for review, it will go through Apple's review process. The duration can vary based on the specifics of your app and you'll be notified when the status changes. For more information, refer to the [App Review](https://developer.apple.com/distribute/app-review/) docs.
|
||||
|
||||
<Callout title="Your submission might be rejected" type="error">
|
||||
If your submission is rejected, you'll receive an email from Apple with the rejection reason. You'll need to fix the issues and upload a new version of your app.
|
||||
|
||||
|
||||
|
||||
Make sure to follow the [guidelines](/docs/mobile/marketing) or check [publishing troubleshooting](/docs/mobile/troubleshooting/publishing) for more information.
|
||||
|
||||
If you need to clarify anything with Apple, you can reply to the app review request in App Store Connect:
|
||||
|
||||
|
||||
|
||||
This helps you understand the rejection and what you need to change to make your app eligible for distribution.
|
||||
</Callout>
|
||||
|
||||
When your app is approved by Apple (by email or push notification), you'll be able to publish it on the App Store.
|
||||
|
||||
|
||||
|
||||
You can learn more about the review process in the official guides listed below.
|
||||
|
||||
<Cards>
|
||||
<Card title="App Review Process" url="https://developer.apple.com/distribute/app-review/" description="developer.apple.com" />
|
||||
|
||||
<Card title="App Review Guidelines" url="https://developer.apple.com/app-store/review/guidelines/" description="developer.apple.com" />
|
||||
</Cards>
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Updates
|
||||
description: Learn how to update your published app.
|
||||
url: /docs/mobile/publishing/updates
|
||||
---
|
||||
|
||||
# Updates
|
||||
|
||||
After you publish your app to the stores, you can release updates to provide your users with new features and bug fixes.
|
||||
|
||||
TurboStarter offers two ready-to-use methods for updating your apps; we'll walk through both of them below.
|
||||
|
||||
## Over-the-air (OTA) updates
|
||||
|
||||
[Over-the-air (OTA) updates](https://en.wikipedia.org/wiki/Over-the-air_update) allow you to push updates to your app without requiring users to download a new version from the app store. This powerful feature enables rapid iteration and quick fixes.
|
||||
|
||||
|
||||
|
||||
TurboStarter integrates with [EAS Update](https://docs.expo.dev/eas-updates/overview/) to provide you with a seamless experience for managing your app updates. We also shipped a native notification that you can use to notify your users about the new updates available.
|
||||
|
||||
Then, to push your update straight to your users, you'll just need to run single command:
|
||||
|
||||
```bash
|
||||
eas update --channel [channel-name] --message "[message]"
|
||||
```
|
||||
|
||||
The app will automatically download the update in the background and install it when your users are ready. You can also configure the update channel and message to be displayed to your users.
|
||||
|
||||
Feel free to check the [official documentation](https://docs.expo.dev/eas-update/getting-started/) for more information.
|
||||
|
||||
<Callout title="Working only for non-native changes" type="warn">
|
||||
OTA updates are **only supported for non-native changes**. If you need to update your app with a new native feature (or add a package that uses native dependencies), you'll need to submit a new version to the stores - see below for more details.
|
||||
</Callout>
|
||||
|
||||
## Submitting a new version
|
||||
|
||||
The most traditional way to update your app is to submit a new version to the stores. This is the most reliable approach, but it can take some time for the new version to be approved and made available to users.
|
||||
|
||||
To submit a new version, update the version number in both your `package.json` file and your `app.config.ts` file.
|
||||
|
||||
```json
|
||||
{
|
||||
...
|
||||
"version": "1.0.0", // [!code --]
|
||||
"version": "1.0.1", // [!code ++]
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Next, follow the exact same steps as [when you initially published your app](/docs/mobile/publishing/checklist). When you submit your app for review, be sure to include release notes for the new version.
|
||||
Reference in New Issue
Block a user