vybekiit 0.7.25 → 0.7.27

package/dist/global-skills/better-auth-best-practices/SKILL.md

@@ -5,7 +5,17 @@ description: Configure Better Auth server and client, set up database adapters,
 
 # Better Auth Integration Guide
 
-**Always consult [better-auth.com/docs](https://better-auth.com/docs) for code examples and latest API.**
+## Documentation Version
+
+Use documentation that matches the Better Auth version installed in the project. APIs and plugin names can differ across maintained release lines.
+
+1. Prefer a version explicitly named by the user.
+2. Otherwise, inspect the resolved `better-auth` version in the lockfile, falling back to the package manifest when no lockfile is available.
+3. When the Better Auth MCP is available, call `get_doc` with `/llms.txt` to resolve that package version to a documentation identifier. Pass the identifier to every `search_docs` call and pass result paths to `get_doc` unchanged.
+4. Without MCP, start at [better-auth.com/llms.txt](https://better-auth.com/llms.txt) and follow the matching version index.
+5. Use the latest documentation only when the project version cannot be determined or the user explicitly asks about the latest release or an upgrade.
+
+When planning an upgrade, separate guidance for the currently installed version from guidance for the target version.
 
 ---
 
@@ -16,9 +26,9 @@ description: Configure Better Auth server and client, set up database adapters,
 3. Create `auth.ts` with database + config
 4. Create route handler for your framework
 5. Run migrations:
-   - **Built-in adapter:** `npx @better-auth/cli@latest migrate`
-   - **Drizzle:** `npx @better-auth/cli@latest generate --output src/db/auth-schema.ts` then `npx drizzle-kit push` (dev) or `npx drizzle-kit generate && npx drizzle-kit migrate` (prod)
-   - **Prisma:** `npx @better-auth/cli@latest generate --output prisma/schema.prisma` then `npx prisma migrate dev`
+   - **Built-in adapter:** `npx auth@latest migrate`
+   - **Drizzle:** `npx auth@latest generate --output src/db/auth-schema.ts` then `npx drizzle-kit push` (dev) or `npx drizzle-kit generate && npx drizzle-kit migrate` (prod)
+   - **Prisma:** `npx auth@latest generate --output prisma/schema.prisma` then `npx prisma migrate dev`
 6. Verify: call `GET /api/auth/ok` — should return `{ status: "ok" }`
 
 ---
@@ -35,9 +45,9 @@ Only define `baseURL`/`secret` in config if env vars are NOT set.
 CLI looks for `auth.ts` in: `./`, `./lib`, `./utils`, or under `./src`. Use `--config` for custom path.
 
 ### CLI Commands
-- `npx @better-auth/cli@latest migrate` - Apply schema (built-in adapter)
-- `npx @better-auth/cli@latest generate` - Generate schema for Prisma/Drizzle
-- `npx @better-auth/cli mcp --cursor` - Add MCP to AI tools
+- `npx auth@latest migrate` - Apply schema (built-in adapter)
+- `npx auth@latest generate` - Generate schema for Prisma/Drizzle
+- `npx auth@latest mcp --cursor` - Add MCP to AI tools
 
 **Re-run after adding/changing plugins.**
 
@@ -179,4 +189,4 @@ For separate client/server projects: `createAuthClient<typeof auth>()`.
 - [Options Reference](https://better-auth.com/docs/reference/options)
 - [LLMs.txt](https://better-auth.com/llms.txt)
 - [GitHub](https://github.com/better-auth/better-auth)
-- [Init Options Source](https://github.com/better-auth/better-auth/blob/main/packages/core/src/types/init-options.ts)
+- [Init Options Source](https://github.com/better-auth/better-auth/blob/main/packages/core/src/types/init-options.ts)

package/dist/global-skills/eas-app-stores/SKILL.md

@@ -1,15 +1,24 @@
 ---
 name: eas-app-stores
-description: EAS service (paid). Deploy Expo apps to the app stores with EAS - build and submit to the iOS App Store, Google Play Store, and TestFlight, configure eas.json build and submit profiles, manage app versions and build numbers, and publish App Store metadata and ASO. Use whenever the user wants to deploy, release, or ship an app to production or the app stores, is preparing a production build, running eas build or eas submit, shipping to TestFlight, bumping version or build numbers, or setting up store listing metadata. For deploying an Expo website or API routes, use the eas-hosting skill.
-version: 1.0.0
+description: EAS service (paid). Build and submit iOS and Android apps with EAS to TestFlight, the App Store, or Google Play. Supports Expo and other React Native projects, plus existing native apps. Use for eas.json setup, release pipelines, signing, app versions and build numbers, store submissions, and listing metadata. For Expo websites and API routes, use eas-hosting; for adding React Native screens to a native app, use expo-brownfield.
+version: 1.1.0
 license: MIT
 ---
 
 # App Store Deployment
 
-> **EAS service - costs apply.** This skill uses Expo Application Services (EAS), a paid product with free-tier limits. `eas build` and `eas submit` consume your plan's build minutes, and store submission requires paid Apple Developer and Google Play accounts. Review https://expo.dev/pricing before running cloud commands.
+> **EAS service - costs apply.** Cloud builds use EAS plan resources, and EAS services have free-tier and paid-plan limits. Apple Developer and Google Play memberships are separate. Check https://expo.dev/pricing for the requested service.
 
-This skill covers building and releasing Expo apps to the iOS App Store, Google Play Store, and TestFlight using EAS (Expo Application Services). For deploying an Expo website or API routes to EAS Hosting, use the `eas-hosting` skill.
+This skill covers building and releasing iOS and Android apps with EAS: Expo and other React Native projects, plus existing native apps. EAS is a delivery service; native apps can use it without adding Expo or React Native to their runtime. The native setup walkthrough currently covers SwiftUI/UIKit on iOS.
+
+## Choose the project path
+
+- **SwiftUI/UIKit app with no React Native runtime:** read [references/native-ios.md](references/native-ios.md) before changing its build configuration. Keep the Xcode project and Swift code as the app's source of truth. The Expo/React Native quick-start and development-client examples below do not apply to this path.
+- **Native Android app with no React Native runtime:** preserve its existing native build setup. See [references/play-store.md](references/play-store.md) for submission; the Swift/iOS setup instructions do not apply. A dedicated native Android setup walkthrough is not yet included.
+- **Expo/React Native app:** use the quick-start below, then the relevant store reference.
+- **Adding React Native screens to an existing native app:** use `expo-brownfield` for that integration; return here for distribution.
+
+Use the archive and icon checks in [references/native-ios.md](references/native-ios.md) during initial native iOS setup, after changing versioning, bundle IDs, or icons, or when diagnosing a rejected upload. Routine releases follow the EAS build/submit flow and the processing and availability checks in [references/testflight.md](references/testflight.md). A successful EAS build or a queued submission does not establish Apple acceptance, tester access, or an App Store release.
 
 ## References
 
@@ -20,8 +29,9 @@ Consult these resources as needed:
 - ./references/app-store-metadata.md -- Managing App Store metadata and ASO optimization
 - ./references/play-store.md -- Submitting Android builds to Google Play Store
 - ./references/ios-app-store.md -- iOS App Store submission and review process
+- ./references/native-ios.md -- Native Swift/SwiftUI/UIKit setup, versioning, and archive verification without an Expo runtime
 
-## Quick Start
+## Expo / React Native Quick Start
 
 ### Install EAS CLI
 
@@ -36,7 +46,7 @@ eas login
 npx eas-cli@latest init
 ```
 
-This creates `eas.json` with build profiles.
+`eas init` links or creates the EAS project. Run `eas build:configure` to create build profiles in `eas.json`; preserve existing project and store identifiers when a release setup already exists.
 
 ## Build Commands
 
@@ -57,12 +67,12 @@ npx eas-cli@latest build --profile production
 
 ```bash
 # iOS: Build and submit to App Store Connect
-npx eas-cli@latest build -p ios --profile production --submit
+npx eas-cli@latest build -p ios --profile production --auto-submit
 
 # Android: Build and submit to Play Store
-npx eas-cli@latest build -p android --profile production --submit
+npx eas-cli@latest build -p android --profile production --auto-submit
 
-# Shortcut for iOS TestFlight
+# Expo / React Native shortcut for iOS TestFlight
 npx testflight
 ```
 
@@ -72,7 +82,7 @@ Deploying an Expo website or Expo Router API routes to EAS Hosting (`npx expo ex
 
 ## EAS Configuration
 
-Standard `eas.json` for production deployments:
+Example for an Expo / React Native project (native Swift profiles are in `references/native-ios.md`):
 
 ```json
 {
@@ -111,7 +121,8 @@ Standard `eas.json` for production deployments:
 
 ### iOS
 
-- Use `npx testflight` for quick TestFlight submissions
+- For native Swift apps, use the explicit build/submit flow in `references/native-ios.md`
+- For Expo / React Native apps, `npx testflight` provides a quick TestFlight flow
 - Configure Apple credentials via `eas credentials`
 - See ./references/testflight.md for credential setup
 - See ./references/ios-app-store.md for App Store submission
@@ -135,9 +146,11 @@ EAS manages version numbers automatically with `appVersionSource: "remote"`:
 eas build:version:get
 
 # Manually set version
-eas build:version:set -p ios --build-number 42
+eas build:version:set -p ios
 ```
 
+The version-set command prompts for the value. When setting up or changing native iOS versioning, or diagnosing a duplicate build number, inspect the archived `CFBundleVersion`: the remote counter alone does not prove that Xcode used it.
+
 ## Monitoring
 
 ```bash
@@ -145,12 +158,15 @@ eas build:version:set -p ios --build-number 42
 eas build:list
 
 # Check build status
-eas build:view
+eas build:view BUILD_ID
 
-# View submission status
-eas submit:list
+# Inspect submissions (verified with EAS CLI 23.2.0)
+eas submit:list -p ios --json
+eas submit:view SUBMISSION_ID --json
 ```
 
+Check the CLI version before interpreting a missing command: these submission commands are available in 23.2.0 but not in the tested 18.6.0 installation. A pinned `npx eas-cli@23.2.0` invocation can use them without changing the global installation. See `references/testflight.md` for live Apple status and retry guidance. Follow the returned log URLs when the JSON result omits the underlying failure. Report the exact build ID/version and the furthest verified release state.
+
 ## Submitting Feedback
 If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
 ```bash

package/dist/global-skills/eas-app-stores/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "EAS App Stores"
-  short_description: "Paid EAS service. Build and submit Expo apps to the iOS App Store, Google Play Store, and TestFlight, with eas.json profiles, versioning, and store metadata"
-  default_prompt: "Use $eas-app-stores when preparing production EAS builds, store submissions, TestFlight distribution, app-store metadata and ASO, or version and build-number management for an Expo app. For web or API route hosting, use eas-hosting instead."
+  short_description: "Paid EAS service. Build and submit iOS and Android apps."
+  default_prompt: "Use $eas-app-stores to set up or verify EAS builds, TestFlight and store submissions, signing, versioning, and store metadata for iOS and Android apps: Expo and other React Native projects, plus existing native apps."

package/dist/global-skills/eas-app-stores/references/ios-app-store.md

@@ -1,5 +1,7 @@
 # Submitting to iOS App Store
 
+For native SwiftUI/UIKit apps without a React Native runtime, configure the Xcode/EAS path in [native-ios.md](native-ios.md) first. The signing, App Store Connect, and review stages below apply to both native Swift and Expo/React Native apps.
+
 ## Contents
 
 - [Prerequisites](#prerequisites)
@@ -7,6 +9,7 @@
 - [Submission Commands](#submission-commands)
 - [App Store Connect Configuration](#app-store-connect-configuration)
 - [TestFlight vs App Store](#testflight-vs-app-store)
+- [Complete the Public Release](#complete-the-public-release)
 - [App Review Process](#app-review-process)
 - [Version and Build Numbers](#version-and-build-numbers)
 - [Release Options](#release-options)
@@ -39,10 +42,7 @@ This interactive flow helps you:
 
 API keys avoid 2FA prompts in CI/CD:
 
-1. Go to App Store Connect → Users and Access → Keys
-2. Click "+" to create a new key
-3. Select "App Manager" role (minimum for submissions)
-4. Download the `.p8` key file
+Use `eas credentials -p ios` to select the build profile and configure its App Store Connect API key. Reuse a working managed key when one already exists. For an existing local team API key, configure the submit profile explicitly:
 
 Configure in `eas.json`:
 
@@ -60,13 +60,7 @@ Configure in `eas.json`:
 }
 ```
 
-Or use environment variables:
-
-```bash
-EXPO_ASC_API_KEY_PATH=./AuthKey.p8
-EXPO_ASC_API_KEY_ISSUER_ID=xxxxx-xxxx-xxxx-xxxx-xxxxx
-EXPO_ASC_API_KEY_ID=XXXXXXXXXX
-```
+Keep private key material outside version control. Use the installed CLI's credential flow and current documentation when setting up a different key type.
 
 ### Apple ID Authentication (Alternative)
 
@@ -75,23 +69,21 @@ For manual submissions, you can use Apple ID:
 ```bash
 EXPO_APPLE_ID=your@email.com
 EXPO_APPLE_TEAM_ID=XXXXXXXXXX
+EXPO_APPLE_APP_SPECIFIC_PASSWORD=xxxx-xxxx-xxxx-xxxx
 ```
 
-Note: Requires app-specific password for accounts with 2FA.
+The app-specific password is for the upload flow. Interactive Apple Developer signing setup has a separate authentication flow.
 
 ## Submission Commands
 
 ```bash
 # Build and submit to App Store Connect
-eas build -p ios --profile production --submit
+eas build -p ios --profile production --auto-submit
 
-# Submit latest build
-eas submit -p ios --latest
+# Submit the verified build
+eas submit -p ios --profile production --id BUILD_ID
 
-# Submit specific build
-eas submit -p ios --id BUILD_ID
-
-# Quick TestFlight submission
+# Expo / React Native TestFlight shortcut
 npx testflight
 ```
 
@@ -103,7 +95,7 @@ Before submitting, complete in App Store Connect:
 
 1. **App Information**
    - Primary language
-   - Bundle ID (must match `app.json`)
+   - Bundle ID (must match the archive; Xcode is authoritative for checked-in native projects)
    - SKU (unique identifier)
 
 2. **Pricing and Availability**
@@ -153,8 +145,8 @@ Find `ascAppId` in App Store Connect → App Information → Apple ID.
 
 ### TestFlight (Beta Testing)
 
-- Builds go to TestFlight automatically after submission
-- Internal testers (up to 100) - immediate access
+- Builds appear after Apple processing; compliance and group assignment may still need attention
+- Internal testers (up to 100) - verify the build is available to the intended group
 - External testers (up to 10,000) - requires beta review
 - Builds expire after 90 days
 
@@ -164,6 +156,18 @@ Find `ascAppId` in App Store Connect → App Information → Apple ID.
 - Submit for review from App Store Connect
 - Choose release timing (immediate, scheduled, manual)
 
+## Complete the Public Release
+
+EAS Submit uploads the binary to App Store Connect. Public distribution continues through the app version's App Review and release flow, as described in the [EAS Submit guide](https://docs.expo.dev/submit/ios/).
+
+1. Open the correct app and iOS version in App Store Connect. In its Build section, select the exact processed version/build you verified. Reuse an eligible TestFlight build when its code, icon, and configuration are ready for production; build again when those must change. Confirm the build is selectable for the App Store version. See [Apple's build-selection guide](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit/).
+2. Complete the required listing and review information: screenshots, description, support/privacy URLs, age rating, privacy declarations, export compliance, reviewer contact/login, and pricing/availability as applicable. Resolve the version's outstanding requirements before submission.
+3. Choose the requested release timing: manual release, automatic release after approval, or automatic release no earlier than a chosen date. Approval is still required for the date-based option.
+4. Click **Add for Review**, inspect the draft submission, then **Submit for Review**. Adding to a draft alone does not send it to Apple. Handle review messages and verify the resulting status. See [Apple's submission steps](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-app/).
+5. After approval, follow the selected release timing. For manual release, the version waits in **Pending Developer Release** until **Release This Version** is completed. Verify availability in the intended storefronts before reporting it live. See [Apple's release options](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option/).
+
+Perform these publication steps only within the requested release scope. Preparing documentation or uploading a TestFlight beta does not itself request a public launch. Report the exact version/build and distinguish uploaded, submitted for review, approved, and publicly available.
+
 ## App Review Process
 
 ### What Reviewers Check
@@ -201,7 +205,7 @@ iOS uses two version identifiers:
 - **Version** (`CFBundleShortVersionString`): User-facing, e.g., "1.2.3"
 - **Build Number** (`CFBundleVersion`): Internal, must increment for each upload
 
-Configure in `app.json`:
+For Expo projects whose native files are generated from app config, configure in `app.json`:
 
 ```json
 {
@@ -214,10 +218,12 @@ Configure in `app.json`:
 }
 ```
 
-With `autoIncrement: true`, EAS handles build numbers automatically.
+With `autoIncrement: true` and remote versioning, EAS increments its counter and writes native version metadata during the build. When setting up or changing native Swift versioning, or diagnosing a duplicate build number, verify the archive's `CFBundleVersion` as described in [native-ios.md](native-ios.md). A changing remote counter does not prove Xcode used it.
 
 ## Release Options
 
+These JSON examples are fragments of `store.config.json` for EAS Metadata. They configure release timing; uploading with EAS Submit still requires selecting the processed build and completing App Review before a public release.
+
 ### Automatic Release
 
 Release immediately when approved:
@@ -279,9 +285,6 @@ Rollout: Day 1 (1%) → Day 2 (2%) → Day 3 (5%) → Day 4 (10%) → Day 5 (20%
 
 ```bash
 eas credentials -p ios
-
-# Sync with Apple Developer Portal
-eas credentials -p ios --sync
 ```
 
 ## App Store Metadata
@@ -306,11 +309,11 @@ Create the app in App Store Connect first with matching bundle ID.
 
 ### "The bundle version must be higher"
 
-Increment build number. With `autoIncrement: true`, this is automatic.
+Compare the number inside the rejected archive with EAS's remote counter. For native Swift, check the plist/build-setting ownership described in [native-ios.md](native-ios.md), then rebuild and submit the corrected artifact.
 
 ### "Missing compliance information"
 
-Add export compliance to `app.json`:
+Review the app's actual encryption use and complete Apple's export-compliance requirements. For an Expo app generated from app config, an exempt app can declare:
 
 ```json
 {
@@ -324,10 +327,12 @@ Add export compliance to `app.json`:
 }
 ```
 
+For a checked-in Swift app, the equivalent declaration belongs in its native Info.plist as `ITSAppUsesNonExemptEncryption`. Use the value appropriate to the app; changing app.json alone does not update its native plist.
+
 ### "Invalid provisioning profile"
 
 ```bash
-eas credentials -p ios --sync
+eas credentials -p ios
 ```
 
 ### Build stuck in "Processing"
@@ -340,7 +345,7 @@ For automated submissions in CI/CD:
 
 ```yaml
 # .eas/workflows/release.yml
-name: Release to App Store
+name: Upload production iOS build
 
 on:
   push:
@@ -357,7 +362,7 @@ jobs:
     type: submit
     needs: [build]
     params:
-      platform: ios
+      build_id: ${{ needs.build.outputs.build_id }}
       profile: production
 ```
 

package/dist/global-skills/eas-app-stores/references/native-ios.md

@@ -0,0 +1,167 @@
+# Native Swift iOS apps on EAS
+
+Use this path when the app runs SwiftUI or UIKit and the task is to build or distribute it with EAS. Adding React Native screens is a different task. [EAS Build supports native projects without Expo or React Native](https://docs.expo.dev/build/introduction/), but the main setup tutorials assume a React Native project.
+
+## Keep the delivery wrapper small
+
+Inspect the Xcode project, shared scheme, Swift entry point, dependencies, signing settings, and current release configuration first. Keep hand-maintained native code checked in. Running `expo prebuild --clean` would regenerate native directories; it is not a setup step for this path.
+
+The default EAS iOS pipeline expects a project beneath `ios/`. A typical layout is:
+
+```text
+app.json
+eas.json
+package.json
+package-lock.json
+ios/
+  Podfile
+  MyApp.xcodeproj/
+  MyApp/
+    MyApp.swift
+    Info.plist
+```
+
+The package file is tooling metadata, not a JavaScript app. A project with no Node dependencies can use:
+
+```json
+{
+  "name": "my-app",
+  "version": "1.0.0",
+  "private": true
+}
+```
+
+Keep a matching lockfile for the chosen package manager. Do not add `expo`, `react`, `react-native`, an `index.js`, Metro, or `expo-dev-client` merely to use EAS. Preserve those dependencies if the app actually uses them. EAS CLI can read a minimal `app.json` without an installed Expo SDK:
+
+```json
+{
+  "expo": {
+    "name": "My App",
+    "slug": "my-app",
+    "ios": { "bundleIdentifier": "com.example.myapp" }
+  }
+}
+```
+
+`eas init` links the project and writes `extra.eas.projectId`. Reuse the existing ID when one exists. The `expo` JSON key is EAS configuration here, not evidence of an Expo runtime. Xcode's bundle identifier is authoritative for a checked-in native project; keep any duplicate app-config identifier consistent, particularly for GitHub-triggered builds.
+
+The [default iOS worker](https://github.com/expo/eas-cli/blob/main/packages/build-tools/src/builders/ios.ts) skips prebuild for checked-in native projects but still runs `pod install`. For an app with no pods, a minimal `Podfile` can serve as an adapter:
+
+```ruby
+platform :ios, '17.0'
+
+target 'MyApp' do
+end
+```
+
+Use the app's real deployment target and target name. This does not add React Native pods. If the project must avoid CocoaPods or has a different layout, use a [custom EAS build](https://docs.expo.dev/custom-builds/get-started/) or archive/export with Xcode and submit the resulting IPA. Do not relocate an established native project just to match this example.
+
+## Build and submit profiles
+
+Select the actual shared scheme. Set `ios.image` from the [current build-image list](https://docs.expo.dev/build-reference/infrastructure/) when a particular Xcode/SDK is required. Use explicit build configurations; `developmentClient: true` configures Expo's development client, not generic Swift debugging.
+
+```json
+{
+  "cli": { "appVersionSource": "remote" },
+  "build": {
+    "base": { "ios": { "scheme": "MyApp" } },
+    "simulator": {
+      "extends": "base",
+      "ios": { "simulator": true, "buildConfiguration": "Debug" }
+    },
+    "testflight": {
+      "extends": "base",
+      "distribution": "store",
+      "autoIncrement": true,
+      "ios": { "buildConfiguration": "Release" }
+    },
+    "production": {
+      "extends": "base",
+      "distribution": "store",
+      "autoIncrement": true,
+      "ios": { "buildConfiguration": "Release" }
+    }
+  },
+  "submit": {
+    "testflight": { "ios": { "ascAppId": "1234567890" } },
+    "production": { "ios": { "ascAppId": "1234567890" } }
+  }
+}
+```
+
+The IDs and target names above are examples. `ascAppId` is the numeric App Store Connect app ID, not the EAS project UUID, bundle ID, or Apple team ID. Verify the selected Apple team, the native bundle ID, and the app record together; one Apple login may belong to multiple organizations.
+
+A pure Swift wrapper with neither Expo dependencies nor Expo SDK metadata needs no Expo Doctor or JavaScript-bundling skip flags. Existing native build phases and actual dependency integrations still need inspection. Avoid carrying unexplained environment overrides from a React Native template; keep native compiler settings in the Xcode project or xcconfig and retain Release debug symbols for crash reports.
+
+For icon selection or other native build preparation, use an EAS lifecycle hook such as `eas-build-post-install` when necessary. An Expo config/prebuild plugin will not run on this native path. Preserve an existing hook rather than replacing its other work.
+
+## Versioning and icon troubleshooting
+
+These checks address two failures encountered while testing a SwiftUI release: a stale archive build number and a default icon with an alpha channel. Use the relevant check during initial setup, after changing versioning, bundle IDs, or icons, or to diagnose a rejected upload. Routine releases use the EAS build/submit flow below.
+
+EAS remote versioning increments a counter. The [native version updater](https://github.com/expo/eas-cli/blob/main/packages/eas-cli/src/build/ios/version.ts) writes `CFBundleVersion` to the target's explicit `INFOPLIST_FILE`. A generated plist with a fixed `CURRENT_PROJECT_VERSION` can leave every archive reporting build 1 even while the EAS dashboard reports increasing numbers.
+
+For the default pipeline, an explicit app plist is a tested approach:
+
+```text
+GENERATE_INFOPLIST_FILE = NO
+INFOPLIST_FILE = MyApp/Info.plist
+MARKETING_VERSION = 1.0.0
+```
+
+Include these entries in the complete app plist:
+
+```xml
+<key>CFBundleShortVersionString</key>
+<string>$(MARKETING_VERSION)</string>
+<key>CFBundleVersion</key>
+<string>1</string>
+```
+
+That local build number is a starting value; EAS writes the remote value during the store build. Apply the settings to the app's relevant configurations and preserve the rest of its metadata: identity, privacy usage descriptions, scene/launch configuration, orientations and supported devices. Do not replace a full plist with this excerpt or change test targets indiscriminately. Review extension targets' version synchronization separately.
+
+An existing generated-plist setup can also work if its build process explicitly sets `CURRENT_PROJECT_VERSION` before archiving. Keep it when verified; do not migrate every native project automatically. Changing only `app.json` or observing an incremented remote counter is insufficient evidence.
+
+When setting up or changing versioning or the bundle ID, or diagnosing a rejected upload, inspect the built app's plist with macOS's built-in tools:
+
+```bash
+plutil -p "/path/to/MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist"
+```
+
+For a downloaded `.ipa`, unzip it into a temporary directory and inspect `Payload/MyApp.app/Info.plist`; for a built `.app`, inspect its `Info.plist` directly. Compare `CFBundleIdentifier`, `CFBundleShortVersionString`, and `CFBundleVersion` with the intended release. Values must be resolved strings, and `CFBundleSupportedPlatforms` must contain `iPhoneOS`, not `iPhoneSimulator`. `eas build:view BUILD_ID --json` provides build details and the artifact URL; its reported version is not a substitute for checking the archive.
+
+When adding or changing a default (Any/light) 1024px AppIcon PNG, or diagnosing an icon rejection, inspect the source selected by that build profile:
+
+```bash
+sips -g pixelWidth -g pixelHeight -g hasAlpha "/path/to/AppIcon.appiconset/icon.png"
+```
+
+The default icon should be 1024×1024 with no alpha channel, even if every pixel looks opaque. Preserve transparency in dark variants and Icon Composer layers; follow [Apple's guidance for each appearance](https://developer.apple.com/documentation/xcode/configuring-your-app-icon). These local checks help diagnose the artifact; use the EAS submission logs and Apple processing status to verify acceptance.
+
+Check privacy usage descriptions against the features used by the app. Set the encryption declaration according to the app's actual encryption use; do not copy `false` solely to suppress an export-compliance prompt.
+
+## Ship the exact build
+
+Reuse established EAS/Apple credentials. For a new setup, configure signing with `eas credentials -p ios` and select the correct team. An App Store Connect API key supports unattended submission without changing the app's owner or bundle ID.
+
+```bash
+eas build --platform ios --profile testflight --no-wait --non-interactive
+# Record the returned build ID; verify its result and source revision.
+eas submit --platform ios --profile testflight --id BUILD_ID --non-interactive
+```
+
+For an IPA exported elsewhere:
+
+```bash
+eas submit --platform ios --profile testflight --path /path/to/MyApp.ipa
+```
+
+Use the explicit ID when multiple builds exist. Keep the distribution scope the user requested. Follow the submission's worker logs through Apple processing, then check tester availability in App Store Connect. A successful upload does not create tester access or release the app publicly.
+
+For production, reuse an eligible uploaded build when it already has the intended release code, icon, configuration, and version. If the beta build uses a preview icon or different configuration, create and verify a production-profile build, then upload that exact archive. A second upload is not required solely to move an eligible tested build into App Review.
+
+Complete the [public release steps in App Store Connect](ios-app-store.md#complete-the-public-release): select the processed build, finish the listing/privacy/review information, submit for App Review, and apply the requested release timing. The [official EAS Submit guide](https://docs.expo.dev/submit/ios/) describes this handoff. TestFlight distribution alone does not authorize publishing an App Store release.
+
+## Verification scope
+
+This approach was exercised with a SwiftUI app on EAS CLI 18.6.0 and Xcode 26.2: an isolated default-pipeline simulator build succeeded without Expo/React/React Native dependencies or skip flags. The explicit-plist and opaque-icon fixes were also verified by a signed device build accepted by Apple. Recheck worker/CLI behavior when updating tooling; project layout, custom hooks, extensions and signing requirements can differ.

package/dist/global-skills/eas-app-stores/references/play-store.md

@@ -133,7 +133,7 @@ This releases to 10% of users. Increase via Play Console or subsequent submissio
 
 ```bash
 # Build and submit to internal track
-eas build -p android --profile production --submit
+eas build -p android --profile production --auto-submit
 
 # Submit existing build to Play Store
 eas submit -p android --latest
@@ -231,13 +231,9 @@ Or use EAS Update for OTA updates to existing installs.
 
 ## Monitoring Submissions
 
-```bash
-# Check submission status
-eas submit:list -p android
+Follow the submission URL returned by `eas submit` for status and logs. Check Play Console for the resulting track and release state.
 
-# View specific submission
-eas submit:view SUBMISSION_ID
-```
+With EAS CLI 23.2.0, `eas submit:list -p android --json` and `eas submit:view SUBMISSION_ID --json` report EAS submission jobs. `submit:status` currently reads Apple status only; do not treat an EAS job's success as confirmation of Play Console rollout.
 
 ## Tips