onesignal-expo-plugin 2.0.3 → 2.0.4

package/.github/ISSUE_TEMPLATE/bug-report.yml

@@ -1,71 +0,0 @@
-name: 🪳 Bug Report
-description: File a bug report
-title: "[Bug]: "
-labels: ["bug", "triage"]
-# assignees:
-#   - assign your sdk team e.g., onesignal/unity
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for taking the time to fill out this bug report!
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: What happened?
-      description: Provide a thorough description of whats going on.
-      placeholder: The latest version of the SDK causes my screen to go blank when I tap on the screen three times.
-    validations:
-      required: true
-  - type: textarea
-    id: reproduction-steps
-    attributes:
-      label: Steps to reproduce?
-      description: Provide as much detail as posible to reproduce the issue.
-      placeholder: |
-        1. Install vX.Y.Z of dependency
-        2. Launch the app on iOS device
-        3. Tap the screen three times
-        4. Note that the app crashes
-      render: Markdown
-    validations:
-      required: true
-  - type: textarea
-    id: what-are-expectations
-    attributes:
-      label: What did you expect to happen?
-      description: Also tell us, what did you expect to happen?
-      placeholder: I expected the app to continue running no matter how many times I tap the screen.
-    validations:
-      required: true
-  - type: textarea
-    id: expo-sdk-version
-    attributes:
-      label: OneSignal Expo SDK version
-      description: The version of the OneSignal Expo SDK used in your app.
-      placeholder: 1.0.0
-    validations:
-      required: true
-  - type: dropdown
-    id: platform
-    attributes:
-      label: Platform
-      description: Which platform are you having an issue with?
-      multiple: true
-      options:
-        - iOS
-        - Android
-  - type: textarea
-    id: logs
-    attributes:
-      label: Relevant log output
-      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
-      render: Shell
-  - type: checkboxes
-    id: terms
-    attributes:
-      label: Code of Conduct
-      description: By submitting this issue, you agree to follow our [Code of Conduct](#insert-project-code-of-conduct-here)
-      options:
-        - label: I agree to follow this project's Code of Conduct
-          required: true

package/.github/ISSUE_TEMPLATE/general-feedback.yml

@@ -1,27 +0,0 @@
-name: 📣 General feedback
-description: Tell us what's on your mind
-title: "[feedback]: "
-labels: ["triage"]
-# assignees:
-#   - assign your sdk team e.g., onesignal/unity
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for sharing your valuable feedback!
-  - type: textarea
-    id: feedback
-    attributes:
-      label: What's on your mind?
-      description: Feedback regarding this SDK.
-      placeholder: Share your feedback...
-    validations:
-      required: true
-  - type: checkboxes
-    id: terms
-    attributes:
-      label: Code of Conduct
-      description: By submitting this issue, you agree to follow our [Code of Conduct](#insert-project-code-of-conduct-here)
-      options:
-        - label: I agree to follow this project's Code of Conduct
-          required: true

package/.github/os_probot_metadata.js

@@ -1,58 +0,0 @@
-/**
- * Based on probot-metadata - https://github.com/probot/metadata
- */
-const regex = /\n\n<!-- probot = (.*) -->/
-
-const { Octokit } = require("@octokit/action")
-
-const octokit = new Octokit()
-
-module.exports = (context, issue = null) => {
-  console.log(context)
-  const prefix = "onesignal-probot"
-
-  if (!issue) issue = context.payload.issue
-
-  return {
-    async get (key = null) {
-      let body = issue.body
-
-      if (!body) {
-        body = (await octokit.issues.get(issue)).data.body || ''
-      }
-
-      const match = body.match(regex)
-
-      if (match) {
-        const data = JSON.parse(match[1])[prefix]
-        return key ? data && data[key] : data
-      }
-    },
-
-    async set (key, value) {
-      let body = issue.body
-      let data = {}
-
-      if (!body) body = (await octokit.issues.get(issue)).data.body || ''
-
-      body = body.replace(regex, (_, json) => {
-        data = JSON.parse(json)
-        return ''
-      })
-
-      if (!data[prefix]) data[prefix] = {}
-
-      if (typeof key === 'object') {
-        Object.assign(data[prefix], key)
-      } else {
-        data[prefix][key] = value
-      }
-
-      body = `${body}\n\n<!-- probot = ${JSON.stringify(data)} -->`
-
-      const [owner, repo] = process.env.GITHUB_REPOSITORY.split("/")
-      const issue_number = context.payload.issue.number
-      return octokit.issues.update({ owner, repo, issue_number, body })
-    }
-  }
-}

package/.github/pull_request_template.md

@@ -1,46 +0,0 @@
-<!-- START -->
-# READ AND DELETE THIS SECTION BEFORE SUBMITTING PR
-* **Fill out each _REQUIRED_ section**
-* **Fill out _OPTIONAL_ sections, remove section if it doesn't apply to your PR**
-* **Read and fill out each of the checklists below**
-* **Remove this section after reading**
-<!-- END -->
-
-# Description
-## One Line Summary
-**REQUIRED** - Very short description that summaries the changes in this PR.
-
-## Details
-
-### Motivation
-**REQUIRED -** Why is this code change being made? Or what is the goal of this PR? Examples: Fixes a specific bug, provides additional logging to debug future issues, feature to allow X.
-
-### Scope
-**RECOMMEND - OPTIONAL -** What is intended to be effected. What is known not to change. Example: Notifications are grouped when parameter X is set, not enabled by default.
-
-### OPTIONAL - Other
-**OPTIONAL -** Feel free to add any other sections or sub-sections that can explain your PR better.
-
-# Testing
-
-## Manual testing
-**REQUIRED -** Explain what scenarios were tested and the environment.
-
-
-# Checklist
-## Overview
-   - [ ] I have filled out all **REQUIRED** sections above
-   - [ ] PR does one thing
-     - If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
-   - [ ] Any Public API changes are explained in the PR details and conform to existing APIs
-
-## Testing
-   - [ ] I have personally tested this on my device, or explained why that is not possible
-   - [ ] I have tested this on the latest version of the plugin
-   - [ ] I have tested this on both Android and iOS, or explained why that is not possible
-
-## Final pass
-   - [ ] Code is as readable as possible.
-      - Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
-   - [ ] I have reviewed this PR myself, ensuring it meets each checklist item
-      - WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

package/.github/release-drafter.yml

@@ -1,27 +0,0 @@
-name-template: $RESOLVED_VERSION
-tag-template: $RESOLVED_VERSION
-categories:
-  - title: 🚀 Features
-    label: Enhancement / Feature
-  - title: 🐛 Bug Fixes
-    label: Bug
-  - title: 🧰 Improvements
-    label: Improvement  
-  - title: down arrow Dependency Updates
-    label: Dependencies 
-change-template: '- $TITLE (#$NUMBER)'
-version-resolver:
-  major:
-    labels:
-      - 'major'
-  minor:
-    labels:
-      - 'minor'
-  patch:
-    labels:
-      - 'patch'
-  default: patch
-template: |
-  ## Other Changes
-  
-  $CHANGES

package/.github/set_response_times.js

@@ -1,47 +0,0 @@
-function calcResponseTimeForIssueCreatedAt(createdAt) {
-    const issueOpenedDate = new Date(createdAt);
-    const issueTriagedDate = new Date();
-    const businessDaysResponseTime = calcBusinessDaysBetweenDates(issueOpenedDate, issueTriagedDate);
-    return businessDaysResponseTime;
-}
-
-function calcBusinessDaysBetweenDates(openedDate, triagedDate) {
-    let differenceInWeeks, responseTime;
-    if (triagedDate < openedDate)
-        return -1; // error code if dates transposed
-    let openedDay = openedDate.getDay(); // day of week
-    let triagedDay = triagedDate.getDay();
-    openedDay = (openedDay == 0) ? 7 : openedDay; // change Sunday from 0 to 7
-    triagedDay = (triagedDay == 0) ? 7 : triagedDay;
-    openedDay = (openedDay > 5) ? 5 : openedDay; // only count weekdays
-    triagedDay = (triagedDay > 5) ? 5 : triagedDay;
-    // calculate differnece in weeks (1000mS * 60sec * 60min * 24hrs * 7 days = 604800000)
-    differenceInWeeks = Math.floor((triagedDate.getTime() - openedDate.getTime()) / 604800000);
-    if (openedDay < triagedDay) { //Equal to makes it reduce 5 days
-        responseTime = (differenceInWeeks * 5) + (triagedDay - openedDay);
-    }
-    else if (openedDay == triagedDay) {
-        responseTime = differenceInWeeks * 5;
-    }
-    else {
-        responseTime = ((differenceInWeeks + 1) * 5) - (openedDay - triagedDay);
-    }
-    return (responseTime);
-}
-
-module.exports = async(context, osmetadata) => {
-    const foundResponseTime = await osmetadata(context).get('response_time_in_business_days');
-    if (foundResponseTime) {
-      const foundString = "already found response time in business days: " + foundResponseTime
-      console.log(foundString);
-      return foundString;
-    }
-    if (context.payload.comment && context.payload.comment.author_association != "MEMBER" &&  context.payload.comment.author_association != "OWNER" && context.payload.comment.author_association != "CONTRIBUTOR") {
-      return;
-    }
-    const businessDaysResponseTime = calcResponseTimeForIssueCreatedAt(context.payload.issue.created_at);
-    console.log("response time in business days: " + businessDaysResponseTime);
-    const result = osmetadata(context, context.payload.issue).set('response_time_in_business_days', businessDaysResponseTime)
-    console.log("osmetadata update result: " + result);
-    return "set response time in business days: " + businessDaysResponseTime;
-}

package/.github/workflows/Zapier.yml

@@ -1,34 +0,0 @@
-# This is an action to close asana tasks that were generated by Github issues
-
-name: Zapier web hook
-
-# Controls when the workflow will run
-on:
-  # Triggers the workflow on push or pull request events but only for the "main" branch
-  issues:
-    types: [closed]
-    
-permissions:
-  issues: read
-
-# A workflow run is made up of one or more jobs that can run sequentially or in parallel
-jobs:
-  # This workflow contains a single job called "build"
-  build:
-    # The type of runner that the job will run on
-    runs-on: ubuntu-latest
-
-    # Steps represent a sequence of tasks that will be executed as part of the job
-    steps:
-      # Runs a set of commands using the runners shell
-      - name: Call Zapier web hook to close Asana task
-        if: ${{ !github.event.issue.pull_request }}
-        env:
-          ISSUE_TITLE: ${{ github.event.issue.title }}
-        run: |
-          curl --location --request POST 'https://hooks.zapier.com/hooks/catch/12728683/b7009qc/' \
-          --header 'Content-Type: application/json' \
-          --header 'Accept: application/json' \
-          --data-raw '{
-            "task_name" : "$ISSUE_TITLE"
-          }'

package/.github/workflows/release-drafter.yml

@@ -1,42 +0,0 @@
-
-name: Release Drafter
-
-on:
-  push:
-    # branches to consider in the event; optional, defaults to all
-    branches:
-      - main
-  # pull_request event is required only for autolabeler
-  pull_request:
-    # Only following types are handled by the action, but one can default to all as well
-    types: [opened, reopened, synchronize]
-  # pull_request_target event is required for autolabeler to support PRs from forks
-  # pull_request_target:
-  #   types: [opened, reopened, synchronize]
-
-permissions:
-  contents: read
-
-jobs:
-  update_release_draft:
-    permissions:
-      # write permission is required to create a github release
-      contents: write
-      # write permission is required for autolabeler
-      # otherwise, read permission is required at least
-      pull-requests: write
-    runs-on: ubuntu-latest
-    steps:
-      # (Optional) GitHub Enterprise requires GHE_HOST variable set
-      #- name: Set GHE_HOST
-      #  run: |
-      #    echo "GHE_HOST=${GITHUB_SERVER_URL##https:\/\/}" >> $GITHUB_ENV
-
-      # Drafts your next Release notes as Pull Requests are merged into "master"
-      - uses: release-drafter/release-drafter@v5
-        # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml
-        # with:
-        #   config-name: my-config.yml
-        #   disable-autolabeler: true
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

package/.github/workflows/set_response_time.yml

@@ -1,32 +0,0 @@
-name: Set Response Time
-on: 
-  issue_comment:
-   types: 
-    - created
-  issues:
-    types:
-    - closed
-jobs:
-  calculate:
-    name: set reponse time for the issue
-    if: github.event.issue.pull_request == null
-    runs-on: ubuntu-latest
-    permissions:
-      issues: write
-    steps:
-      - uses: actions/checkout@v3
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-      - run: npm install @octokit/action@6.0.6
-      - uses: actions/github-script@v6
-        id: set-time 
-        with:
-          result-encoding: string
-          script: |
-            const os_probot_metadata = require('./.github/os_probot_metadata.js')
-            const set_response_time = require('./.github/set_response_times.js')
-            return await set_response_time(context, os_probot_metadata)
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Get result
-        run: echo "${{steps.set-time.outputs.result}}" >> $GITHUB_STEP_SUMMARY

package/CHANGELOG.md

@@ -1,83 +0,0 @@
-# Changelog
-All notable changes to this project will be documented in this file.
-
-## April 2023
-### `1.3.2` - 04/18/23
-#### Changes
-- Update iOS generation to write xcode project via expo mod rather than directly to file system.
-- Bump qs from 6.5.2 to 6.5.3
-- Bump decode-uri-component from 0.2.0 to 0.2.2 
-- Bump @xmldom/xmldom from 0.7.5 to 0.7.10
-- Bump multiple dependency versions in OneSignal Example App (ua-parser-js, decode-uri-component, @sideway/formula, @xmldom/xmldom)
-
-## March 2023
-### `1.3.1` - 03/03/23
-#### Changes
-- Update monorepo logic to rely on the more reliable `require.resolve` to find the `onesignal-expo-plugin` package.
-
-## November 2022
-### `1.3.0` - 11/30/22
-#### Changes
-- Add `iosNSEFilePath` configuration options to the plugin, which allows an app to specify a custom iOS Notification Service Extension.
-
-## October 2022
-### `1.2.0` - 10/25/22
-#### Changes
-- Add `smallIcons` and `largeIcons` configuration options to the plugin, which allows an app to specify large and small notification icons to package within the Android build.
-- Bump jpeg-js from 0.4.3 to 0.4.4
-- Bump simple-plist from 1.3.0 to 1.3.1
-
-### `1.1.2` - 10/04/22
-#### Fixes
-- Specify `use_frameworks` on `OneSignalNotificationServiceExtension` target in iOS Podfile when applicable (i.e. the app target also specifies `use_frameworks`).
-
-## September 2022
-### `1.1.1` - 09/06/22
-#### Fixes
-- Fix issue where EAS release builds were no longer successfully building due to log statement
-
-### `1.1.0` - 09/01/22
-#### Changes
-- No longer inject the OneSignal Gradle plugin on Android builds
-#### Fixes
-- Fix issue where plugin does not support monorepos
-
-## April 2022
-### `1.0.1` - 04/11/22
-
-#### Changes
-- Add more info regarding the `expo prebuild` command to README.
-#### Fixes
-- Upstream EAS workaround for "Missing Push Capability on iOS" issue. Adds `aps-environment` entitlement to NSE template. Although it is **not** required in normal builds, there is an upstream limitation from EAS that is resolved by including the push entitlement in both target entitlement files. As of 4/8/22, EAS builds will randomly pick an entitlement file if there are multiple in a project without differentiating among targets. This is resulting in flaky builds where half the time they work and half the time they don't. This can be seen as a temporary fix. Note it carries no side-effects / repercussions (i.e: the entitlement is superfluous but not critical to remove in the future).
-
-## March 2022
-### `1.0.0` - 03/28/22
-
-#### Fixes
-- Upgrade dependencies (via dependabot)
-#### Changes
-- Add credentials guide and update README
-- Advance to General Availability
-
-## February 2022
-### `1.0.0-beta11` - 02/18/2022
-#### Added
-- Linting
-- Instead of creating a "WriterManager", we repurpose the ReaderManager class by renaming it to FileManager and adding a synchronized write helper function (synchronous in the sense that it block further execution until complete).
-- iOS constants file
-
-#### Fixes
-- Import cleanups
-- Linting errors
-- Write safety issu. NSE updater helper functions were previously writing to the entitlements & plist files asynchronously. We should await on each to ensure we don't have multiple writes to the same file at once (which is unsafe).
-
-## January 2022
-
-### `1.0.0-beta10` - 01/24/2022
-#### Added
-- ability to configure version numbers used in the NSE target's plist file.
-- `OneSignalLog` class for better console logging.
-- this changelog file.
-
-#### Fixed
-- re-running `expo prebuild` will no longer result in duplicate entitlements and dependencies added to native files.

package/EAS.md

@@ -1,21 +0,0 @@
-# Expo Application Services
-EAS is Expo's cloud-build service.
-
-## [EAS Homepage](https://expo.dev/eas)
-
-## EAS + OneSignal Setup
-To get OneSignal push notifications working in an EAS-built app, see our guide on how to configure your [iOS credentials](IOS_CREDENTIALS_EAS.md).
-
-## How to run an iOS EAS-built app
-### Run in a production environment
-For production builds, your generated ipa file should to be distributed to the App Store or Testflight.
-
-
-### Run in custom development client
-For development/internal distribution builds, you will need to install a [development client](https://docs.expo.dev/development/getting-started/) on your iOS device.
-
-1. Scan the QR code shown in the terminal after EAS build success and install the development client application to your device.
-2. In the terminal, run `expo start --dev-client` to be able to serve the application to the client.
-3. Scan the generated QR code to open the dev client and fetch the app bundle from the running Expo process.
-4. You may be prompted to allow the app to find local area network devices. Approve.
-5. Rescan the QR code & open the app. At this point, you should see the metro bundler working. As soon as the bundle is complete, your working app should open!

package/IOS_CREDENTIALS_EAS.md

@@ -1,170 +0,0 @@
-# iOS Credentials Guide: OneSignal + EAS
-## Overview
-To distribute your iOS application, you must set up all the credentials required by Apple. The 3 primary iOS credentials are:
-* Distribution certificate
-* Provisioning profiles
-* Push notification certificate
-
-If you are using EAS, you may be letting Expo handle all your credentials. This is fine for your distribution and provisioning credentials. However, the push notification certificate *must* be set up separately since you are using OneSignal.
-
-### Push Notification Certificate
-To set up OneSignal on iOS, you will need a [push notification certificate](https://documentation.onesignal.com/docs/generate-an-ios-push-certificate). The push certificate is used to send notifications to devices and has nothing to do with the build process. After you have uploaded the certificate to OneSignal, it should just work.
-
-### Capabilities
-As of eas-cli `v0.52.0`, the previous capabilities issues should now be resolved. See the [release notes](https://github.com/expo/eas-cli/releases/tag/v0.52.0) for details.
-
-You can still view the old instructions by clicking below.
-
-<details>
-  <summary>Click to expand</summary>
-
----
-To receive notifications, you must add the `aps-environment` capability (Push Notifications) to your app at build time. The OneSignal plugin tries to facilitate this as much as possible but there could be complications if you added other capabilities/entitlements or another config plugin did. This is because EAS doesn't currently respect entitlement files on a per-target basis. If there are more than one entitlements files, it simply picks one and applies it to both targets.
-
-Due to this, there are two setup paths:
-1. A **simple setup** is one in which the only [capability](https://docs.expo.dev/build-reference/ios-capabilities/) on your main target is "Push Notifications."
-2. A more **complex setup** is one in which you have other capabilities.
-
-This also affects how you should set up your credentials. Use the following table to know whether to proceed with local or managed credentials:
-| Push Notification capability only |                                                                       |
-|-----------------------------------|-----------------------------------------------------------------------|
-| Local credentials                 | Works but unnecessary to go through extra effort to use local signing |
-| Managed credentials               | Works (simple setup)                                                                 |
-
-| Multiple capabilities |                                  |
-|-----------------------|----------------------------------|
-| Local credentials     | Works but requires complex setup |
-| Managed credentials   | Works unreliably                 |
-
-If you are unsure, run `expo prebuild` and look at the native entitlements file of your main target (in `ios` directory). Other config plugins may be adding capabilities here. Or check the full [capabilities](https://docs.expo.dev/build-reference/ios-capabilities/#supported-capabilities) list supported by Expo.
-
-
-#### Simple setup explanation
-Since there is only one capability (Push Notifications) required by your app, everything should just work. OneSignal will automatically add the capability to your app along with the necessary App Groups and EAS should sync them with your Apple Developer account. You can choose to use managed signing on EAS without a problem. This works because OneSignal will add the capability to both targets' entitlements files.
-
-#### Complex setup explanation
-Having additional capabilities on your app will result in a more complex setup, including having to use local credentials. The following is an explanation of why. It is not imperative to understand but we have included it for context.
-
-The OneSignal plugin will create an additional target: `OneSignalNotificationServiceExtension`. This target is the iOS service extension that adds support for Confirmed Deliveries, badges, media attachments, action buttons, and influenced opens (Firebase Analytics). Learn more [here](https://documentation.onesignal.com/docs/service-extensions). The plugin will automatically add app groups to both targets' entitlements files which are required if you want to make use of these features. They allow your app to execute code when a notification is received, even if your app is not active.
-
-Each target has an entitlement file. If there are multiple entitlements files per project, EAS will randomly pick one and apply it to both targets. To mitigate this, we have added the push capability entilement to both files (even though it's really only necessary in the main target). This can still pose a problem if it picks the NSE's entitlements file since it *could* break any other capabilities in your project, given that file will not have capabilities added to your main target by yourself or other plugins.
-
-The following section details how to mitigate these issues and not break your other capabilities.
-
-## Complex Setup
-
-### 1. Credentials setup
-To build successfully, you will need to create and use local credentials (one for production and development). Add `"credentialsSource": "local"` to your `eas.json` file.
-
-**Example:**
-```json
-{
-  "build": {
-    "release": {
-      "android": {
-        "gradleCommand": ":app:bundleRelease"
-      },
-      "ios": {
-        "credentialsSource": "local",
-        "buildConfiguration": "Release"
-      }
-    },
-    "development": {
-      "developmentClient": true,
-      "distribution": "internal",
-      "credentialsSource": "local"
-    }
-  }
-}
-```
-
-### 2. Identifiers
-In your [Apple developer console](https://developer.apple.com) create two identifiers with the following format:
-   - `<com.example.app>` <-- you likely already have this one
-   - `<com.example.app>.OneSignalNotificationServiceExtension`
-
-#### When modifying your existing main app identifier:
-   - add the App Groups capability like so: `group.<identifier>.onesignal`
-   - keep / add the "Push Notifications" capability
-
-#### When creating a new identifier for `OneSignalNotificationServiceExtension`:
-   - select AppId from the list of identifier types
-   - select App when choosing between App and App Clip
-   - add the App Groups capability like so: `group.<identifier>.onesignal`
-   - do not add the "Push Notifications" capability
-
-#### Note on App Groups at Build Time:
-Make sure to build with both identifiers containing the AppGroup simultaneously. To troubleshoot, remove them both and then rebuild with both identifiers' AppGroup capabilities enabled.
-
-### 3. Provisioning
-Create AdHoc (local development) and AppStore (production) provisioning profiles with both identifiers (four provisioning profiles total). Both provisioning profiles should use the same distribution certificate that is used by your app. Download the profiles.
-
-### 4. Add the profiles to your `credentials.json` file:
-Use the same distribution certificate for the `OneSignalNotificationServiceExtension` as is used for your app (no need to create a new cert).
-
-We recommend creating a `certs` directory in your project with subdirectories for each build type (e.g: `certs/adhoc` & `certs/appstore`). Doing so, you can more easily switch which provisioning profiles get used at build time.
-
-**Directory structure:**
-```
-/certs
-   - /adhoc
-   - /appstore
-```
-
-**Example `credentials.json`:**
-```json
-{
-    "ios": {
-        "<PROJECT>": {
-            "distributionCertificate": {
-                "path": "certs/ios_distribution_certificate.p12",
-                "password": "***"
-            },
-            "provisioningProfilePath": "certs/adhoc/***mobileappprofile.mobileprovision"
-        },
-        "OneSignalNotificationServiceExtension": {
-            "distributionCertificate": {
-                "path": "certs/ios_distribution_certificate.p12",
-                "password": "***"
-            },
-            "provisioningProfilePath": "certs/adhoc/***onesignalprofile.mobileprovision"
-        }
-    }
-}
-```
-
-**Note:** your push certificate (p12) file should not appear anywhere in the `credentials.json` file.
-
-## Build (complex setup continued)
-
-**IMPORTANT**: run the `eas build` command with `EXPO_NO_CAPABILITY_SYNC` if you want to prevent EAS from syncing capabilities (e.g: overwriting the steps you took in the complex setup).
-
-### Release
-If you are ready for a production build, you should use the AppStore provisioning profiles you created. Make sure your `credentials.json` file is using the correct profiles.
-
-### Development
-The development build will use the AdHoc provisioning profiles you created. Make sure your `credentials.json` file is using the correct profiles.
-
----
-</details>
-
-### Expo development client
-If you haven't already, add the expo development client to your project:
-
-```sh
-expo install expo-dev-client
-```
-
-Make sure `"developmentClient": true,` is set in your `eas.json` development build profile.
-
-### Run the EAS build command
-```sh
-eas build --profile <build profile> --platform ios
-```
-where `<build profile>` refers to the build profile in your `eas.json` file (e.g: "development" vs "release").
-
-### Build success
-At this point, your build should succeed. You can check its progress by opening the build link in the terminal.
-
-## How to run on your device
-See our [EAS guide](EAS.md) for instructions.