Slow iOS Companion App

Mobile Apps Home Assistant Companion for Apple
1

The iOS companion app has become painfully slow for me all of a sudden. Takes about 30s to load the app. Backgrounding the app dosnt work anymore, meaning there’s an “ui error” every time I switch back and need to reload.

I’m in the most recent HA and it was an issue already before installing. First few launches after the update it was responsive again but quickly went back to being slow.

Any ideas on what might have caused that or what I can do to debug/improve?

I can’t see anything in logs. Memory is about 60%, CPU around 2%. Perhaps I’ve reached the limitation of my hardware?

2

Have you gone into the companion app settings > debug > reset frontend cache?

3

Good idea. Just tried that. No change. App is so bad now it’s unusable for me. So slow to load a page and plenty of non configured entities.

4

Hmm… if you go to your Settings app > General > iPhone Storage, do you have any free space left? If you’re getting close to maxing out your space, that’ll slow the phone down significantly in-general.

5

Same experience.
Very slow iOS Companion app on after HA 2026.4 update. 2026.4.1 didnt fix.

I am maintaining 7-8 Home Assistant installations for friends/family, and many of them complain about very slow performance on iOS companion app after 2026.4 update.

Performance in PC browser seems unaffected.

7

Good idea, but all good ok that front. Regularly delete media on the phone due to auto backup.

8

I’m actually happy I’m not alone on this one. Hopefully a fix comes along soon enough.

9

really short update: I’m back home now and the app is behaving fine again. I did nothing. Fast on local network and fast when out and about on 5G. I’ll keep an eye on it the next time I’m abroad…

10

I’m experiencing the same issue, but it seems to only be an issue on my (wall mounted) iPad. Other devices do not seem to have any observable issues.
When pressing a light button on my dashboard it takes approx. 2sec before the light turns on and the icon changes color. This only happens on 1 view.

Recently upgraded the iPad to IOS 18.7.7
HomeAssistant CORE running 2026.4.1 on a RaspberyPi-4Gb, CPU ~25% / MEM ~ 65%

The problem seems to have started before IOS 18.7.7 / HomeAssistant 2026.4.1

before these upgrades the iPad, and all other devices, responded swiftly. No noteworthy changes have been made to the dashboard the iPad is using.

What I already have done:

  1. cleared front-end cache on the iPad
  2. rebooted the iPad
  3. rebooted HomeAssistant

Any tips on where to look or how to troubleshoot this issue?

11

Mine is slow in showing my (complex) dashboard. It's the latest M5 iPad Pro, so no slouch but it's simply unusable now. To be fair, so is the Safari browser but both must be using the webkit engine anyway. Pulling my hairs on this. Reverted all dashboard changes, optimized whatever I could nothing helped.

Google Chrome (on Windows 11 Pro) is fine (though I did find a terrible memory leak and reported it 'on a silver plate' 2 weeks ago on Github but it's not even assigned yet. For now regular Chrome restarts is the only way to workaround this)

To be fair. I'm not even sure if it's related to home assistant; this could have started with one of the latest iPadOS/iOS updates. I did read something about a possible regression bug and Apple did make changes to WebGPU/rendering engine.

12

Its similar to a firetablet. Slow and a huge change after last update. Almost unusable on both Tailscale and Nabucasa. Something changed.... It's Awful! I finally had my wife on board loving the app. FML

13

Seeing this same issue on my wife's iphone and noticed using safari its also laggy.

My Android device works perfectly fine super snappy UI.

14

Same problem on iPhone 14 Pro and iPad air

15

I need to retract my previous message in this topic; after pulling my hairs out for weeks I finally found the issue. For some reason I had a grid of custom:button-card's in a vertical stack, in a vertical stack, in a vertical stack, in a vertical stack. :blush: For some other reason this slows Webkit down so much the entire dashboard (to be more correct: the one view this grid was on) became unusable.

This case may be so 'rare' (who wants to pull off something this stupid like I did haha :rofl:) it's probably of no use to anyone but I'll 'report' it anyway.

image
image2554×1494 256 KB

image

16

similar experience here, gotten worse in latest HA release in my config slowing down all Safari browsers on the Mac, and iOS app a bit less but still very noticeably .

My final finding was it being caused by a combination of horizontal-stack of 7 custom:button-cards, which was contained in a vertical-stack together with another button-card.

type: vertical-stack
cards:
  - type: custom:button-card
  - type: horizontal-stack
    cards:
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card

Since I have this as a menu bar on each and every view, my whole Frontend was slowed down upon changing dashboards / reloading. Making it practically unusable and made me go to Firefox or Chrome, which dont suffer the same (any really) delay.
DuckDuckGo suffers the same, as its the same browser in the backend...

for now I have changed the horizontal-stack with the button cards to use grid of column: 7 and that seems to do a much better job.

type: vertical-stack
cards:
  - type: custom:button-card
  - type: grid
    columns: 7
    square: false
    cards:
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card
      - type: custom:button-card

or with an additional visibilty condition

type: vertical-stack
cards:

  - !include /config/dashboard/includes/include_show_view_header_title.yaml

  - type: vertical-stack
    visibility:
      - condition: state
        entity: input_boolean.menu_in_footer
        state: 'off'
    cards:
      - !include /config/dashboard/buttons/buttons_dashboards.yaml

Apparently, the stacks are lazily loaded, while the grid card is not.

Its still not perfect, but its much better.

taking the button-card out completely solves the issue, so its 100% a combination of the 2 horizontal-stack using custom:button-card. Underlying button-card configurations dont really matter.

fwiw, the same menubar stack card as a footer in the view does Not cause the issue.

17

I removed button card as I was not using it anymore. And it seems it solved my issue

18

Similar experience, I actually rolled back to HA 2026.5 because the latest stable 2026.6 broke the ios experience completely.

I'm on an iPad Air 2 at it's last updated OS version of 15.8.8
HA in a container running on an N100 + 16gb ram
CPU at 12%, mem at 30%

Response to card/button presses take about 3-4 seconds. Cleared cache, rebooted and restarted the iPad and HA. Have 3 GBs of storage on the iPad good to go...

Not to muddy the waters further, but when going into Settings > iOS companion app, it loads a blank dialog window, selecting the 'settings' option to go back then reveals the options available.

Testing the same dashboard on my iPhone 16 running iOS 26.5 did not exhibit any of the same behaviour. Instant response to inputs.

19

When updating to 2026.6.x it completely kills connectivity to iOS 15.8.8 altogether, a fix was apparently promoted in 2026.6.3, but I see no difference in behaviour. Can't connect the iPad mini 2 at all now. Going to roll back a few versions to get it working again.

20

Three rollbacks, a whole lot of scouring logs and I just had to a ios reset to get it accessible again through HA 2026.3.4. I'll take it.