On MacOS, emClient, only one Google Mail account configured.
Using a little flaky internet connection via my phone, scrolling in the inbox, opening the menu, changing windows becomes very slow / unresponsive. This is reproducible. It seems that you need to decouple the process that accesses the GMail inbox from your main process that renders the UI. Go do it. This feels really broken for people that have to work on a train.
Best
Jan
Using a little flaky internet connection via my phone, scrolling in the inbox, opening the menu, changing windows becomes very slow / unresponsive.
This feels really broken for people that have to work on a train.
Thats not a fault of eM Client. Mail clients need good fast stable connections to work properly.
Ask if the train has free wifi available as alot of passenger trains now do. If not maybe suggest you look at an alternate carrier sim card which has better mobile coverage to get better speed.
I agree that the flaky network is not a problem of emClient. But if the emClient UI blocks because of a flaky network that is a problem of emClient. Your app should not block just because latency is high.
I do not know where you are or the train service you use, but I
frequently travel by TGV in France between Avignon & Paris and
return and can either use on board WiFi or 5G on my iPhone with
eM Client or eM Client on my laptop with WiFi
I have never had any issues so as @cyberzork suggests speak to
the train company and or your cell provider
If it is of any help to you I have two sims in my phone and switch
between Deutsche Telekom & Telefonica.
I do not think like @cyberzork that your issue is with eM Client.
Bonne chance!
Lucy_C
2 Likes
The train was an example. My point is: the emClient UI blocks on network access. That is not how it should be as the UI experience degrades with speed of network. Instead, any network activity that could potentially be slow should be run in the background.
jueves 28 mayo 2026 :: 0920hrs (UTC +0100)
Hey@jank
Maybe it is me but I do not see logic in your post, also no matter how I try
I cannot replicate what I think you say is your issue whether using Ethernet,
WiFi, Mobile, internationally and recently Starlink Internet when in remote
areas of Senegal West Africa.
eMC performed perfectly everywhere.
From this I have to conclude the issue is primarily with your device and or
a combination of factors though not eMC or as you say a flaky internet.
eMC has no influence over and can not compensate for any outside factors.
skybat
¡Buena suerte!
¡Saludos desde Sevilla la soleada en España!
¡Mis mejores deseos y mantente a salvo!
Hablo español, luego portugués, inglés, francés y alemán
con conocimiento de varios otros idiomas.
I even have the situation now on proper Wifi. emClient is busy and does not respond for 2-6 seconds when clicking (e.g. on ‘other’ in the inbox). No spinning beach ball of death on Mac. All other apps are running fine. It is just emClient.
Monday 01 June
Hi @ jank
I think it is reasonable to assume that you have an issue with your
Internet connection or perhaps your router and outside influences.
Bonne chance!
Lucy_C
1 Like
I have it tested in various setups now. I initially thought it was the internet connection, but that was just a correlation. Even on a fiber with 500 MB/s or in the office with 2 GB/s I get really sloppy UI behavior of the client.
What I observe is: if I have emClient in the background for some time (minutes) or my laptop was got waken up from hibernate, the emClient is very slow to respond on first interaction. once a UI functionality was touched it is back to normal again or after some iteration.
I am on a very beefy MacBook M4 with 48 GB of RAM - so do not blame it on my hardware. Every other application is working fine. MacOS 26.5 (25F71).
In Activity Monitor I can see that emClient sucks up a whopping 37 GB of RAM. Real Mem size is 4GB, Virtual Mem size is 450GB. I have never seen any app sucking up so much memory. But could it be that we are looking at a swapping issue? If a lot of data is stored in virtual mem and the app is always swapping, it would explain the really sluggish UI performance (and also the behavior that once some interaction happened that performance increases again).
May I ask if emClient is a MacOS native app or if it got implemented on some kind of virtualization?
FYI. Given the excessive memory use, I decided to restart emClient. after a fresh restart it consumes:
700 MB real memory, 450 GB virtual memory.
Checking other apps on Mac, the virtual mem does not seem out of the ordinary. It seems that half a TB is what every app gets.
App feels more responsive after restart. Maybe it is with Windows: just schedule a restart every 2nd day?
urgh - is it true that emClient is build on top of Mono as Gemin suggests? That would explain why I am not experiencing native macOS app behavior. Whatever it is, there is something fishy that needs to get addressed. Otherwise I will have to stop using emClient and shed some tears about the license costs I sank, which would be sad.
I am on a very beefy MacBook M4
I can see that emClient sucks up a whopping 37 GB of RAM
Make sure you are “not closing eM Client via the red dot” and then reopening it, as “that appears to add more memory usage every-time its reopened” if you are doing it that way due to some unknown reason with Mac OS 26.x . So either completely close / exit it or minimize it.
1 Like
for other users and my future self: I never close apps, and I also never restart my macOS. The OS is quite stable and I often only restart when security patches are available (so 1-2 months of uptime are no exception).
I will now put closing and restarting emClient to my regular weekly routines. After my restart the app is behaving mostly normal. If excessive RAM usage is the root cause of sloppy performance I am at least glad to have found a work-around. But the restart workaround feels quite ‘microsofty’.
Regarding the memory usage on macOS (Tahoe) this is a known problem. See:
1 Like