@radhya/mach 2.1.2 → 2.1.4

package/README.md

@@ -16,15 +16,15 @@ Install and wire provider-direct APNs/FCM push in the current linked project:
 
 ```bash
 mach push setup
-mach push credentials apns --file AuthKey.p8 --team-id TEAMID1234 --key-id KEYID12345
-mach push credentials fcm --file firebase-service-account.json
+mach credentials
 mach push send --user user_123 --title "Hello" --body "Your update is ready."
 mach push status --days 30
 ```
 
 MACH Push supports Expo development builds and bare React Native. It
 adds a working default permission, registration, receive, and tap flow while
-leaving an editable callback file in the application. It stores encrypted
+leaving an editable callback file in the application. The app config only marks
+push as enabled; MACH stores encrypted
 device/provider credentials and aggregate delivery counters,
 but not notification content or per-message history. See
 [MACH Push](docs/push.md).
@@ -56,7 +56,7 @@ mach build --platform android
 | `mach maestro`             | Queue managed Maestro tests for a build or artifact                |
 | `mach ota`                 | Setup, publish, list, rollback, and promote OTA updates            |
 | `mach submit`              | Submit to App Store or Google Play                                 |
-| `mach credentials`         | Manage iOS certificates, provisioning profiles & Android keystores |
+| `mach credentials`         | Manage build, service, and push notification credentials           |
 | `mach credentials:service` | Upload App Store Connect or Google Play service credentials        |
 | `mach env`                 | Manage, list, and download environment variables and secrets        |
 | `mach version`             | Show and seed DB-owned native version counters                     |
@@ -319,7 +319,9 @@ Mach handles the managed macOS submission environment internally. No provider-sp
 
 ## Credential Management
 
-Manage iOS certificates, provisioning profiles, Android keystores, and App Store Connect API keys — all stored securely in the Dashboard.
+Manage iOS certificates, provisioning profiles, Android keystores, store
+automation keys, and push notification credentials — all stored securely in the
+Dashboard.
 
 ```bash
 # Interactive credential manager
@@ -373,6 +375,25 @@ App Store Connect keys are used for iOS TestFlight submission. Mach stores the k
 
 Google Play service keys are only needed for Android store submission. They are not signing credentials. A dev package such as `com.example.app.dev` needs its own Google Play service key only if that exact package exists in Google Play and you submit that package.
 
+### Push Notification Credentials
+
+Provider-direct APNs and FCM credentials use the same credentials flow:
+
+```bash
+mach credentials
+```
+
+Choose **Push Notifications**. On iOS, Mach can generate one APNs auth key
+with Apple or upload an existing `.p8` key. On Android, upload the Firebase
+service-account JSON once for the selected Android package; the same FCM
+credential serves development, preview, and production. APNs can be saved for
+all environments or only one environment. On Apple's APNs key-limit error,
+Mach can list existing APNs keys, revoke one after confirmation, and retry
+creation in the same session. The Dashboard shows these under **Credentials →
+Service credentials** for the selected bundle identifier or package name. See the
+[MACH Push guide](docs/push.md#generate-the-firebase-service-account-json) for
+the exact Firebase JSON generation steps.
+
 ## Configuration
 
 Create a `mach.config.json` in your project root:
@@ -435,9 +456,9 @@ Create a `mach.config.json` in your project root:
 | `ios.bundleIdentifier` | iOS bundle ID used for signing, version counter scoping, and submit                                                            |
 | `ios.appleTeamId`      | Optional global Apple Developer Team ID used for iOS signing. Profile-specific `submit.<profile>.ios.appleTeamId` overrides it |
 | `ios.ascAppId`         | App Store Connect app id used for iOS submission                                                                                |
-| `ios.buildNumber`      | Set to `"auto"` to let Mach assign the next iOS CFBundleVersion from its Dashboard counter                                     |
+| `ios.buildNumber`      | Use `"auto"` for the next Dashboard counter value, or set an explicit CFBundleVersion such as `"68"` or `"1.2.3"`              |
 | `android.package`      | Android package name used for signing, version counter scoping, and submit                                                     |
-| `android.versionCode`  | Set to `"auto"` to let Mach assign the next Android versionCode from its Dashboard counter                                     |
+| `android.versionCode`  | Use `"auto"` for the next Dashboard counter value, or set an explicit positive integer                                          |
 
 ### Profile Properties
 
@@ -536,6 +557,8 @@ When `android.versionCode` is set to `"auto"`, Mach assigns an Android versionCo
 
 When `ios.buildNumber` is set to `"auto"`, Mach assigns the next iOS CFBundleVersion from the scoped Dashboard counter. Concurrent builds are safe because the Dashboard API increments the counter atomically.
 
+When either field contains an explicit value, Mach uses that exact value without incrementing the counter. Profile-level `build.<profile>.ios.buildNumber` and `build.<profile>.android.versionCode` values override the root platform values. The resolved Mach value is authoritative: runners reuse the saved assignment, native projects receive it after Expo prebuild, and Mach rejects an artifact whose packaged value differs.
+
 This only changes iOS `CFBundleVersion` / build number. It does not bump the public App Store version (`CFBundleShortVersionString`, usually `expo.version` in `app.json`). After a version like `1.17.0` is approved/released, Apple closes that train for new uploads; bump the app version, for example to `1.17.1`, rebuild, then submit.
 
 Regular iOS development builds should set `distribution: "development"` and resolve Apple Development certificates/profiles. For custom profile names, Mach follows the profile fields, not the profile name: `environment` chooses Dashboard secrets, and `distribution` / `iosExportMethod` chooses signing. Dev-client builds can keep `distribution: "internal"` and set `developmentClient: true`; Mach will still use development signing credentials while producing an internal installable artifact.