Mobile Chat channel - Web Messenger vs Native App Integration

Hi All,

We just migrated our web from onPrem chat channel to Cloud web messenger successfully. Looking Ahead We are planning to add chat option on Mobile App and I am looking for Pros / cons between Native App integration vs JS based Web messenger integration with mobile app (same as website). Some of the factors we are comparing between 2 options are:

  • User experience difference
  • Session management
  • Mobile compatibility
  • Development effort
  • Administration Differences
  • and other limitations

If someone can share their integration experience would be appreciated.

Thanks in advance

@learngen I have had this conversation with a LOT of customers..... to the point I have a whole PPT preso on it as well as 2x GitHub repos on the topic. In short personally Id take the bit more effort up front to built it nativly into your app. While it is more effort up front it will actually save you time in the long run. Also technically the Web Messenger Widget is not support is a "WebView" only a FULL Browser.... I have seen others try this and while you will get it working you will miss out on many great features like push notification when the app is closed (as WSS will be closed to the widget when app is closed). Most enterprise customers that run an app already use a BaaS like for example "Firebase" this is actually what i built my design around. The App I built out was in "Flutter" so i can deploy it to Android & iOS.

@Matt_McPhee This is great information and I see you are going in the same direction where we were thinking as well.

I assume authenticated chat option is available and custom participant Data can also be passed with native app integration ?

Are you able to share that presentation or Github link? Also do you have sample visual / images how native chat UI looks like.

thanks again for helping us pick the right approach.

@learngen I have put the 2x links below to the examples I built out. One is for the "Server Side" in Firebase and the other is the "Client side" in Fultter. These should not be used as a best practice guide for Dart or firebase but just an example that i put together for me to talk to locally in Australia and use in my demos. These are based on "Open Messaging API" I did this for 2x reasons the first being that at the time the native Mobile SDK "https://developer.genesys.cloud/commdigital/digital/webmessaging/messenger-transport-mobile-sdk/" was NOT GA at the time (but it is now). The second reason was with Open Messaging I had more control over things like the message cached and threaded without just the 15day history through the API. It also meant that I could more easily use the OOTB Authentication with Firebase instead of just the OpenID messaging in Web Messenger, control history threading and push notifications.

Like any design there are pros and cons. One of the tings I personally really liked about have the Open Messaging architecture was that it took a LOT of the heavy lifting out of the mobile client side and moved it to a NodeJS server side function. This made security easier as I never jsut trust a client as well as the Firebase SDK covered all the sync of data at scale well. Also i could update the server components without having to deploy a new "version" of the app. As well as the firebase crash reports and analytics. If your not currently using a BaaS product then this might not excite you but it definitely has with other customers I have talked to.

Server Side: https://github.com/mcphee11/firebase-openMessaging
Client Side: https://github.com/mcphee11/flutter-openMessaging

I would be keen to hear your thoughts as well as the direction you go on this topic.

Cheers.

Great discussion! In terms of what is being productized for Mobile Messenger:

  1. We have recently release a "headless" Messenger Transport Mobile SDK which can be used to build your own UI: this is essentially a wrapper around our Guest APIs, and natively resolves all low-level transport & connectivity. Support for Custom Attributes is included and Typing Indicators are being released. This is available on GitHub here. Authenticated Web Messaging support is also planned, and we aim at functional parity with all features included in the Guest APIs.
  2. We are in process of GA releasing a full Messenger UI SDK, which encapsulates the above, that will provide a native and centrally-configurable messaging client UI, to mimic the same approach we have with Web Messenger. This is now available as Beta as React-Native SDK, and we plan to release native iOS & Android versions soon. If you're interested in Beta access for React-Native, please apply here.

Thank you @Angelo_Cicchitto @Matt_McPhee. We are in the process of reviewing above details and will share updates soon.

@Matt_McPhee Whilst I too do like the look of the "Open Messaging API" it lacks support for some features such as buttons and carousel if I am not mistaken.
@Angelo_Cicchitto I have previously signed up for this Beta but had no response. Have just tried again.
:slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.