[CIS-1900] Push Notifications - multi bundle support

[bielikb]

🔗 Issue Links

CIS-1900

🎯 Goal

Allow integrator to leverage multi-bundle feature via exposing new parameter to addDevice API called provider name.
Provider name represents the name of the push configuration created in Stream dashboard.
Push configurations are located under Push Notifications tab in the dashboard.

Multi-bundle support allows the integrator to list multiple client apps under one Stream app in the dashboard. (eg. when leveraging Staging vs. Production setup).
The default configuration will be used if no provider name is specified.

Available API:
APN:

client?.currentUserController().addDevice(.apn(token: deviceToken, providerName: "Name of the push configuration listed in Stream's Dashboard"))

Firebase:

client?.currentUserController().addDevice(.firebase(token: deviceToken, providerName: "Name of the push configuration listed in Stream's Dashboard"))

📝 Changes

• New optional providerName parameter can be specified for both apn and firebase integrations.

• Existing provider parameter in the PushDevice struct was renamed to pushProvider to gain API alignment with Android.

• In order to have a way to test the to multi-bundle support, new DemoApp target was added to the integration apps repo with bundle identifier io.getstream.iOS.ChatDemoAppTwo.
  

• Additionally, a new Info section was added to our DemoApp to clarify which push configuration is used by our default develop app.
  

• client property inside StreamChatWrapper is no longer forced-cast.

Important Note 📜

Docs will be added in separate PR, this PR contains only the implementation part.

🧪 Manual Testing Notes

1. Build multi bundle app on multi-bundle branch in integration apps repo
2. Send a message to Luke from a different app/web
3. Verify the push notification is received.
   

☑️ Contributor Checklist

• I have signed the Stream CLA (required)
• Changelog is updated with client-facing changes
• New code is covered by unit tests
• This change follows zero ⚠️ policy (required)
• Comparison screenshots added for visual changes
• Affected documentation updated (docusaurus, tutorial, CMS)

🎁 Meme

Provide a funny gif or image that relates to your work on this pull request. (Optional)

[Stream-SDK-Bot]

	2 Errors
🚫	Please start subject with capital letter. eaa8369
🚫	Please use more than one word. ca2f82d

Generated by 🚫 Danger

[evsaev]

What if we just have another configuration (e.g. alpha) instead of 2nd target? Because that's the approach enterprise usually follows: they ship 1 app version for internal testing purposes via TestFlight and another app is a production app available in AppStore for end users. They have single target but multiple configurations which bundle identifier depends on

[bielikb]

Usually you have separate targets per each type of app (staging, production). The separation of concerns via another app target for multi bundle app makes it easy to configure the build settings/phases the way they make sense for you. eg adding support for Firebase in MB target won't interfere with our main DemoApp target.

What if we just have another configuration (e.g. alpha) instead of 2nd target? Because that's the approach enterprise usually follows: they ship 1 app version for internal testing purposes via TestFlight and another app is a production app available in AppStore for end users. They have single target but multiple configurations which bundle identifier depends on

[evsaev]

LGTM

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication