Answered

Intercom SDK attributed to high battery usage in Xcode

  • 29 November 2023
  • 17 replies
  • 242 views
D
Badge

When going through Xcode’s Organizer window you can see a breakdown of energy logs. In there Intercom-related calls and processes are listed as high impact.

Here are couple of examples:

48 seconds cpu time over 51 seconds (94% cpu average), exceeding limit of 80% cpu over 60 seconds

 

48 seconds cpu time over 59 seconds (81% cpu average), exceeding limit of 80% cpu over 60 seconds
48 seconds cpu time over 59 seconds (81% cpu average), exceeding limit of 80% cpu over 60 seconds

The rest of the reports is quite similar in the stack traces and impact.

Is there anything that Intercom could do to help with the battery impact? Maybe by exposing methods to stop listening for websocket messages? 

 

Some additional information:

  1. We’re utilizing bluetooth-central background execution mode to listen to BLE device, which means that the app in some circumstances may never go to terminated/suspended state
  2. App is built with Flutter
  3. Intercom SDK version used 16.3.0
icon

Best answer by Brian B11 13 December 2023, 14:00

View original

17 replies

Jacob Cox
Userlevel 4
Badge +5

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!

Jacob | Sr. Technical Support Engineer at Intercom
Brian B11
Userlevel 2
Badge +2

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

D
Badge

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?

Jacob Cox
Userlevel 4
Badge +5

Flagging this for @Brian B11 

Jacob | Sr. Technical Support Engineer at Intercom
Brian B11
Userlevel 2
Badge +2

@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.

 

D
Badge

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.

Brian B11
Userlevel 2
Badge +2

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

Brian

T

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. 

 

Brian B11
Userlevel 2
Badge +2

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

A

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

Brian B11
Userlevel 2
Badge +2

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

A

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?

A

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?

Brian B11
Userlevel 2
Badge +2

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!

Brian B11
Userlevel 2
Badge +2

@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

Brian B11
Userlevel 2
Badge +2

@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

A

Great work! Thank you for the quick response

Reply


Terms & ConditionsCookie settings