MS Teams....very depressing.

[Xiao_Xi]

They want to switch to WebView2

How could WebView2 get more performance than Electron if both are based on Chromium?

 

[maxsquared]

I don't know much about WebView2, but I think Electron is essentially a browser wrap, and each app needs to embed Chromium, that's why the installation file is so large, and uses so much ram...

WebView2 could be similar to React Native that translates a lot of components into native macOS components without depend on browser. Or it sits between React Native and Electron has some native elements but less so of React Native.

I don't understand why Microsoft don't utilise their own React Native and build more apps with it.

Again I am not too sure about WebView2, so ....

 

[tommiy]

teams github ring releases including webview2+electron here. No idea if they are better or worse as I moved to edge as a web app.

 

[KPOM]

Teams is pretty bad. It's a total memory hog too. That said, its still quite early in the Apple Silicon transition. There is still a lot of software without native support.

But Microsoft moved Office to Apple Silicon early on. Plus, there is a version of Teams for iPadOS and iOS, so it isn’t as though they are starting from scratch (or at least they ought not be starting from scratch).

 

[Krevnik]

Electron does not support iOS and Apple has banned several Electron apps from the Mac Appstore.

I stand corrected. There's a whole mess of different technologies in the Teams app bundle. Wow. RN, Native, and something that looks a lot like a custom JS environment of some kind. I just assumed that the code that's likely running in the custom JS environment was using Electron instead of rolling their own.

I don't know much about WebView2, but I think Electron is essentially a browser wrap, and each app needs to embed Chromium, that's why the installation file is so large, and uses so much ram...

WebView2 could be similar to React Native that translates a lot of components into native macOS components without depend on browser. Or it sits between React Native and Electron has some native elements but less so of React Native.

I don't understand why Microsoft don't utilise their own React Native and build more apps with it.

Again I am not too sure about WebView2, so ....

My understanding is that WebView2 is not a replacement for RN. RN gives you access to native (as much as I am not a fan of the quality of many of the community components) but is a JavaScript-only environment, while WebView2 is more like using a WKWebView to host some form of PWA, something Windows doesn't really have a good equivalent to. So WebView2 makes sense in the lens of having a web view for Microsoft and for their platform.

 

[Arctic Moose]

My work is very dependent on Team.
Yes Teams runs, it's only written for Intel. You Tube TV will stop playing and I've had other problems when the Teams app is running.

I've now moved to run Team as an edge app....not perfect, but a lot better.

Anyone have other work arounds?

But seriously, why has MS provided Team as a universal already?

I run Microsoft Teams pretty much all day every day on my 14" M1 Max. It's fine, as far as Teams goes, at least compared to Intel (or even Windows) versions.

Besides YouTube (which is an issue I haven't come across, but then again I don't watch much YouTube) what are the issues you are having?

 

[MrGunny94]

Perhaps we need a thread on critical corporate work apps that don't yet support Apple Silicon. Eventually, Citrix will have to support Apple Silcon but their corporate IT customers are always slow to adopt new tech.

Yeah I’m sure they are just waiting for the last week available to release something native.. It’s such a frustrating experience to deal with slow enterprise companies.

 

[Lord of the Pies]

I'm so glad my current employer uses Google Workspace, Notion and Slack. God I used to hate MS 365 and especially Teams.

 

[VitoBotta]

Scroll down to "workaround"

“Native” Microsoft Teams performance on M1 Macs

Disclaimer: Near-native on top of Chromium engine

luiyongsheng.medium.com

Thanks! How do I join a meeting I have been invited to if I have the link? I can't see an option for this.

 

[MrGunny94]

It is quite depressing look at this :

 

[Apple Knowledge Navigator]

I think MS will retire the native app. It's clear that they want to go cloud/web-based for a lot of their services now, much in the same vein as Google.

 

[spiderman0616]

Sometimes I think Microsoft is moving in the right direction and sometimes I don't. I actually think whoever is in charge of their Apple software design has the right idea. Office for Mac/iOS/iPadOS continues to improve yearly. But I do agree with the OP about Teams. I avoid it if possible. It just doesn't function consistently the way I need it to, and I've noticed a lot of places moving toward Cisco instead, not that their software is a ton better.

 

[Krevnik]

Sometimes I think Microsoft is moving in the right direction and sometimes I don't. I actually think whoever is in charge of their Apple software design has the right idea. Office for Mac/iOS/iPadOS continues to improve yearly. But I do agree with the OP about Teams. I avoid it if possible. It just doesn't function consistently the way I need it to, and I've noticed a lot of places moving toward Cisco instead, not that their software is a ton better.

Office still has a dedicated team that is focused on the Apple user experience, in an app that is native code that dates back to the 80s. So the MacBU team is still alive in some form and in charge of driving things like Office on Apple platforms, and it shows. That’s less true of many other teams that are newer and likely follow a “single team” approach where your developers are expected to have their fingers in web, mobile, and desktop all at once. I’m seeing a trend across the industry of “Web first” where even if the mobile app comes out at the same time, the mobile app is also web-based, and any desktop release if it exists at all is a Web wrapper. Partly because if you are paying a single team or org of engineers to do everything, they’re likely to be web developers in this environment.

 

[grmlin]

One essential feature that Teams never gets right for me is the online state of my colleagues. It’s hilarious as I always ask them on Slack if they are really busy as Teams says or not.

 

[Tagbert]

Yes because Apple won't be supporting Rosetta forever. I think I read they were supporting it for only 3 years.

No one within Apple has said that. It is pure speculation. Apple would get a lot of pushback from its customers if it dropped Rosetta so soon while legacy apps were still not migrated. No reason not to keep it going for longer than that. Especially for their Intel Mac Pro customers.

 

[Tagbert]

I'm so glad my current employer uses Google Workspace, Notion and Slack. God I used to hate MS 365 and especially Teams.

Office 365 has been good on Apple Silicon but Teams is embarrassing.

 

[KPOM]

I think MS will retire the native app. It's clear that they want to go cloud/web-based for a lot of their services now, much in the same vein as Google.

Why can’t they just port their iOS app to the Mac?

 

[MrGunny94]

Why can’t they just port their iOS app to the Mac?

Yeah at this point I'd take this over the existing app.

 

[Tagbert]

Since Teams is Electron-based, how much effort is needed to port to AS? The Chromium Electron base is already ported. Isn't the rest Javascript running against that Electron VM? What else is still Intel-based? The whole point of Electron is to code an app in a platform independent way.

 

[Krevnik]

Since Teams is Electron-based, how much effort is needed to port to AS? The Chromium Electron base is already ported. Isn't the rest Javascript running against that Electron VM? What else is still Intel-based? The whole point of Electron is to code an app in a platform independent way.

The main thing that comes to mind as someone who's worked on React Native projects, it's that updating the middleware you sit on isn't always free and can generate work that needs to be chased down, new full test passes, and the like.

Ironically, strong Rosetta performance makes it easier for teams to deprioritize the ARM transition on the Mac. Especially if there's not a lot of dependence on anything the new architecture provides. It's easy to get caught up in prioritization based on urgency: numbers of folks work impacts, what the current thing on fire is, and so on. So if given the choice between updating Electron and fixing breaks for the subset of Mac users on Apple Silicon, or going after the rumored WebView2, or fixing some bad bug with calling, Apple Silicon tends to wind up at the bottom of the pile.

If the WebView2 rumors are true, I wouldn't be surprised if Apple Silicon support gets rolled up into that feature, but that's 100% a guess on my part.

Not all teams operate like this. Not keeping up with the platform (or your middleware) is a form of technical debt, and waiting to address it just makes it more expensive. So some teams trade off handling that debt early by delivering less feature work, and baking the overhead into their schedules. They also tend to be a bit more sane to work on in my experience, as they are more honest about how much they can actually get done with the resources they have.

 

[MrGunny94]

The main thing that comes to mind as someone who's worked on React Native projects, it's that updating the middleware you sit on isn't always free and can generate work that needs to be chased down, new full test passes, and the like.

Ironically, strong Rosetta performance makes it easier for teams to deprioritize the ARM transition on the Mac. Especially if there's not a lot of dependence on anything the new architecture provides. It's easy to get caught up in prioritization based on urgency: numbers of folks work impacts, what the current thing on fire is, and so on. So if given the choice between updating Electron and fixing breaks for the subset of Mac users on Apple Silicon, or going after the rumored WebView2, or fixing some bad bug with calling, Apple Silicon tends to wind up at the bottom of the pile.

If the WebView2 rumors are true, I wouldn't be surprised if Apple Silicon support gets rolled up into that feature, but that's 100% a guess on my part.

Not all teams operate like this. Not keeping up with the platform (or your middleware) is a form of technical debt, and waiting to address it just makes it more expensive. So some teams trade off handling that debt early by delivering less feature work, and baking the overhead into their schedules. They also tend to be a bit more sane to work on in my experience, as they are more honest about how much they can actually get done with the resources they have.

I think WebView2 for Mac is later this year from their roadmap.. Sounds like we are in for a good waiting game.

Just don't understand why they don't do a preview or port the iOS App for the Mac for the time being.. Boggles my mind.

 

[Krevnik]

I think WebView2 for Mac is later this year from their roadmap.. Sounds like we are in for a good waiting game.

I’ll be honest, my guesses here aren’t rooted in any real knowledge of what’s going on with Teams. I’m just bringing up ideas based on what I’ve seen engineering teams do during my career which has mostly been at larger companies. It’s not uncommon to see something kicked down the road because some other work will make it redundant out of a desire for efficiency due to being lean on platform expertise.

Just don't understand why they don't do a preview or port the iOS App for the Mac for the time being.. Boggles my mind.

Do we know how staffed they are for such an effort? Are we talking about Catalyst (which means making sure any frameworks they use also work for x64), or iOS-on-Mac? In the case of iOS-on-Mac, how well does it work today?

A couple things I can add from my experience:

- Porting is pretty much guaranteed to be more work than upgrading your existing middleware. And if you are kicking the middleware upgrade can down the road, is there going to be appetite for something even more ambitious?
- iOS-on-Mac realistically isn’t going to work with all iOS apps, despite Apple’s sales pitch on the feature. I’ve been working on a SwiftUI app on iOS/Mac/Apple TV. I tried running the iOS app on my M1 MBP. Not only did it nearly instantly crash, what I saw before it crashed was ugly and needed a lot of work to be acceptable. It is going to be cheaper to just go whole hog on a dedicated Mac build, ironically, because SwiftUI is helping cut down on how much I need to customize for each platform.
- I’ve been on teams that own iOS apps but don’t have much if any platform expertise. I’ve been the only one on the team that knew how Obj-C/Swift worked and been depended on for 101-level stuff. So engineering expertise on a team does tend to dictate what you can do, and what approaches your engineers will think of. Diverse teams will tend to do better here.

Don’t get me wrong... I would actually support a Catalyst-based Mac app. The issues I’ve seen with Teams that are fundamental to the tech they decided to build on (context menus that get clipped and made unusable by the window border for example) would be addressed with a Catalyst app and let them benefit from the shared code. But I’ve seen how these sort of debates play out.

 

[MrGunny94]

There is an upcoming performance event coming on the 26th though, let's hope we can get some feedback from there so if any of you can please log in and comment that you want to know the status of the macOS upcoming updates or if a Beta is coming soon to the Preview Channels

Re: AMA: Microsoft Teams Performance and Overview - Microsoft Tech Community

I’ll be honest, my guesses here aren’t rooted in any real knowledge of what’s going on with Teams. I’m just bringing up ideas based on what I’ve seen engineering teams do during my career which has mostly been at larger companies. It’s not uncommon to see something kicked down the road because some other work will make it redundant out of a desire for efficiency due to being lean on platform expertise.



Do we know how staffed they are for such an effort? Are we talking about Catalyst (which means making sure any frameworks they use also work for x64), or iOS-on-Mac? In the case of iOS-on-Mac, how well does it work today?

A couple things I can add from my experience:

- Porting is pretty much guaranteed to be more work than upgrading your existing middleware. And if you are kicking the middleware upgrade can down the road, is there going to be appetite for something even more ambitious?
- iOS-on-Mac realistically isn’t going to work with all iOS apps, despite Apple’s sales pitch on the feature. I’ve been working on a SwiftUI app on iOS/Mac/Apple TV. I tried running the iOS app on my M1 MBP. Not only did it nearly instantly crash, what I saw before it crashed was ugly and needed a lot of work to be acceptable. It is going to be cheaper to just go whole hog on a dedicated Mac build, ironically, because SwiftUI is helping cut down on how much I need to customize for each platform.
- I’ve been on teams that own iOS apps but don’t have much if any platform expertise. I’ve been the only one on the team that knew how Obj-C/Swift worked and been depended on for 101-level stuff. So engineering expertise on a team does tend to dictate what you can do, and what approaches your engineers will think of. Diverse teams will tend to do better here.

Don’t get me wrong... I would actually support a Catalyst-based Mac app. The issues I’ve seen with Teams that are fundamental to the tech they decided to build on (context menus that get clipped and made unusable by the window border for example) would be addressed with a Catalyst app and let them benefit from the shared code. But I’ve seen how these sort of debates play out.

I understand what you mean, but i'll give you a quick example Cisco AnyConnect iOS app works great despite some scaling issues on macOS despite being a native iOS app. I asked the Cisco team to allow it to be downloaded on the Mac App Store and they did so and that's what I use every single day instead of the Rosetta 2 Intel variant app.

We don't know what the MS Teams development team is doing because they haven't shared any details other than the "Universal App is coming and "We keep on improving the performance on the macOS client version".

 

[ADGrant]

Do we know how staffed they are for such an effort? Are we talking about Catalyst (which means making sure any frameworks they use also work for x64), or iOS-on-Mac? In the case of iOS-on-Mac, how well does it work today?

A couple things I can add from my experience:

- Porting is pretty much guaranteed to be more work than upgrading your existing middleware. And if you are kicking the middleware upgrade can down the road, is there going to be appetite for something even more ambitious?
- iOS-on-Mac realistically isn’t going to work with all iOS apps, despite Apple’s sales pitch on the feature. I’ve been working on a SwiftUI app on iOS/Mac/Apple TV. I tried running the iOS app on my M1 MBP. Not only did it nearly instantly crash, what I saw before it crashed was ugly and needed a lot of work to be acceptable. It is going to be cheaper to just go whole hog on a dedicated Mac build, ironically, because SwiftUI is helping cut down on how much I need to customize for each platform.
- I’ve been on teams that own iOS apps but don’t have much if any platform expertise. I’ve been the only one on the team that knew how Obj-C/Swift worked and been depended on for 101-level stuff. So engineering expertise on a team does tend to dictate what you can do, and what approaches your engineers will think of. Diverse teams will tend to do better here.

Don’t get me wrong... I would actually support a Catalyst-based Mac app. The issues I’ve seen with Teams that are fundamental to the tech they decided to build on (context menus that get clipped and made unusable by the window border for example) would be addressed with a Catalyst app and let them benefit from the shared code. But I’ve seen how these sort of debates play out.

SwiftUI and Catalyst are completely different. Catalyst is UIKit on MacOS, I have converted UIKit apps to Catalyst and have found the development effort to be trivial. SwiftUI was intended to support cross platform development (provided those platforms are Apple platforms). If a SwiftUI app is difficult to convert to MacOS, that is an issue with the specific app. There is no good reason (IMHO) for an iOS app not to target iPadOS and MacOS too.

Electron apps are an abomination, so is Javascript.

 

[Sheepish-Lord]

I have to use Teams via O365 (web) so this requires me to enable 3rd party cookies so I can bounced between Office, Teams, etc. I use it on Chrome and it seems fine.

I did see that for Safari it’s in beta so Microsoft tells you to disable cross-site tracking in Safari until they figure it out. I haven’t tried it but I would assume it works.