Change Details

There will be a few phases of development for iOS push notifications. For the first phase, when the iOS engineers are developing and debugging on their test devices, we would like to have a flow for triggering push notifications that goes through batching logic in the push notifications service and the APNS sandbox environment, to our test devices. Ideally this flow would mimic what a live flow would be like. For example, would we be able to add to a talk page via desktop, and have the notification pushed and appear on a test device via the sandbox environment without any extra steps? Also, would we be able to trigger these notifications from multiple different Wikis? Note we would also need this to work along with [[ https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bnotifications | the notifications API ]] (either prod or a beta flavor) since we will need to fetch this to determine the push notification content. Related to this, we have a few app identifiers that we need to test with this flow. Currently [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications/+/HEAD/src/outgoing/apns/readme.md | I believe ]] the push notifications service is configured with a `debug_topic` of `org.wikimedia.Notifications-Utility`. To be able to test in the main app and not this side prototype app, we would need to add one (or more) of these: 1. `org.wikimedia.wikipedia` - This is the identifier for the main Wikipedia app, whose endpoints point to production servers. My hope is that this would be safe, if a beta version of the push notifications service can only send through the sandbox apns environment, there would be no chance of pushes from it showing up in TestFlight or App Store builds. 2. `org.wikimedia.wikipedia.tfbeta` - This is our staging version off the app. It's the same as the main app, but has a different icon and currently points to the mobileapps staging endpoints for PCS. We use it rarely for testing staged PCS changes, but we could lean on it for this testing flow. 3. `org.wikimedia.wikipedia.tfalpha` - This is our experimental version of the app. We use it to push one-off experimental builds when we are early in development on a feature. It can be configured to point to any endpoint environment. For the second phase, we will want QA to test against a TestFlight deployment of the `org.wikimedia.wikipedia` app identifier, which is all production. As a last phase we will also want external beta testers to test against these TestFlight builds as well. Is it possible to spin up the production flow for push notifications in these phases before we release to the App Store?

There will be a few phases of development for iOS push notifications. For the first phase, when the iOS engineers are developing and debugging on their test devices, we would like to have a flow for triggering push notifications that goes through batching logic in the push notifications service and the APNS sandbox environment, to our test devices. Ideally this flow would mimic what a live flow would be like, like an end-to-end sandbox path. For example, would we be able to add to a talk page via desktop, and have the notification pushed and appear on a test device via the sandbox environment without any extra steps? Also, would we be able to trigger these notifications from multiple different Wikis? Note we would also need this to work along with [[ https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bnotifications | the notifications API ]] (either prod or a beta flavor) since we will need to fetch this to determine the push notification content. Related to this, we have a few app identifiers that we need to test with this flow. Currently [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications/+/HEAD/src/outgoing/apns/readme.md | I believe ]] the push notifications service is configured with a `debug_topic` of `org.wikimedia.Notifications-Utility`. To be able to test in the main app and not this side prototype app, we would need to add one (or more) of these: 1. `org.wikimedia.wikipedia` - This is the identifier for the main Wikipedia app, whose endpoints point to production servers. My hope is that this would be safe, if a beta version of the push notifications service can only send through the sandbox apns environment, there would be no chance of pushes from it showing up in TestFlight or App Store builds. 2. `org.wikimedia.wikipedia.tfbeta` - This is our staging version off the app. It's the same as the main app, but has a different icon and currently points to the mobileapps staging endpoints for PCS. We use it rarely for testing staged PCS changes, but we could lean on it for this testing flow. 3. `org.wikimedia.wikipedia.tfalpha` - This is our experimental version of the app. We use it to push one-off experimental builds when we are early in development on a feature. It can be configured to point to any endpoint environment. For the second phase, we will want QA to test against a TestFlight deployment of the `org.wikimedia.wikipedia` app identifier, which is all production. As a last phase we will also want external beta testers to test against these TestFlight builds as well. Is it possible to spin up the production flow for push notifications in these phases before we release to the App Store?

There will be a few phases of development for iOS push notifications. For the first phase, when the iOS engineers are developing and debugging on their test devices, we would like to have a flow for triggering push notifications that goes through batching logic in the push notifications service and the APNS sandbox environment, to our test devices. Ideally this flow would mimic what a live flow would be like, like an end-to-end sandbox path. For example, would we be able to add to a talk page via desktop, and have the notification pushed and appear on a test device via the sandbox environment without any extra steps? Also, would we be able to trigger these notifications from multiple different Wikis? Note we would also need this to work along with [[ https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bnotifications | the notifications API ]] (either prod or a beta flavor) since we will need to fetch this to determine the push notification content. Related to this, we have a few app identifiers that we need to test with this flow. Currently [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/push-notifications/+/HEAD/src/outgoing/apns/readme.md | I believe ]] the push notifications service is configured with a `debug_topic` of `org.wikimedia.Notifications-Utility`. To be able to test in the main app and not this side prototype app, we would need to add one (or more) of these: 1. `org.wikimedia.wikipedia` - This is the identifier for the main Wikipedia app, whose endpoints point to production servers. My hope is that this would be safe, if a beta version of the push notifications service can only send through the sandbox apns environment, there would be no chance of pushes from it showing up in TestFlight or App Store builds. 2. `org.wikimedia.wikipedia.tfbeta` - This is our staging version off the app. It's the same as the main app, but has a different icon and currently points to the mobileapps staging endpoints for PCS. We use it rarely for testing staged PCS changes, but we could lean on it for this testing flow. 3. `org.wikimedia.wikipedia.tfalpha` - This is our experimental version of the app. We use it to push one-off experimental builds when we are early in development on a feature. It can be configured to point to any endpoint environment. For the second phase, we will want QA to test against a TestFlight deployment of the `org.wikimedia.wikipedia` app identifier, which is all production. As a last phase we will also want external beta testers to test against these TestFlight builds as well. Is it possible to spin up the production flow for push notifications in these phases before we release to the App Store?