Hey there @Dominik R !

This is interesting! I’ve never come across this before. I’ll need to reach out to our Product Team and chat with them about this. I’ll reach back out when I have more information to share here!

Hi @Dominik R 

Thanks for getting in touch.

Our websocket connection stays alive while you’re app is in the foreground/active and your user is logged in to Intercom.

If you’re app rarely goes into a suspended state, this would keep Intercom’s realtime connection open continuously.

One way you can mitigate this is to call `Intercom.logout()` when you’re app moves into the background. This will stop all websockets and thus reduce any battery impact Intercom may be having for your app. You can then call `login` once you’re apps becomes active again or when a customer opens Intercom in your app.

Hope this helps

Brian

Thank you for the response. Isn’t there any other way to close the websocket connection than logging out? If I understand correctly, logging out would prevent our users from receiving push notifications, which are vital in communication with them.

> If you’re app rarely goes into a suspended state, this would keep Intercom’s realtime connection open continuously.

I think that may be the case with iOS BT central background execution mode. It keeps entire app awake as there’s no real concept of background processing on iOS. 

Isn’t there option to tie the Intercom websocket connection to particular View Controller? Or maybe passing custom http/ws client to control the connection?

Flagging this for @Brian B11 

@Dominik R Unfortunately we don’t offer a way to disable websockets except via logout.

Realtime messaging is the core of the Messenger, so we don’t offer a way to disable it.

Thanks, I understand this limitation! However, can I put a feature request for ability to stop websocket connections without logging out? One other use case for that could be a user journey during which we would like to avoid showing Intercom messenger until it’s done (e.g. subscription purchase or onboarding). In our case though we would love to use it whenever app stays in the background (but not suspended) for longer than few minutes.

Thanks for the feedback. Will take your suggestion on board.

Brian

Hello @Brian B11 
Is there an update on this issue? Is this something that is being prioritised?
Similar to @Dominik R we are experiencing this issue with iOS users reporting high battery usage. 

Hi @Tolu_ 

This is on our radar. No firm date on when we’ll have a release that will resolve this, but we are investigating it.

Thanks

High cpu usage will also result in the crash of the app when it’s over the limit of 50% over 180 seconds. or 20 seconds hang time at the app launch.

Our app was recently rejected by the app store review because app didn’t starting in time, and was killed by the system after 20 seconds hang time.

It looks like the issue is not present in the 15.2.1 version, so we have downgraded the version to 15.2.1 and hope that it will fix the issue for now.

Here is the stack trace of the event that is causing the most hang time by the Intercom SDK in our app:

Please, prioritise the issue so we can update to the latest version

Thanks @armat 

Can you tell me whether you are able to consistently re-create this issue?

If you are, are there steps you can share with me please? I’m not able to re-create it myself.

Thanks

Hi Brian,

We also couldn’t reproduce it locally so far, but we can see more than 2000 logs in the last 2 weeks from Xcode’s Organizer with cpu usage issue related to Intercom.

From the logs it looks like something to do with connection timeout. Perhaps the SDK has some retry logic when the socket connection is failed, which get’s stuck in an infinite loop in some edge cases?

We do not see the issue on Intercom SDK 15.2.1 version, so maybe you can investigate if there were some changes to the socket connection logic since that version?

Thanks @armat 

Yep, we did change some of the logic for our websockets last year. 

We will take a closer look to see if we can identify anything based on your info above.

Thanks!

@armat We did make some improvements to this code in our last release 16.5.2

We’re currently trying to test if this fixes this problem, but if you wanted to have a look at the latest release and see if it solves it for you.

Brian

@armat @Dominik R @Tolu_ 

This has been fixed in Release 16.5.4. Please update to this version.

The issue occurred when a device had network connection issues. We were able to identify the root cause and fix it.

Thanks for reporting it.

Brian

Great work! Thank you for the quick response