TeamViewer, e.g.; their official Linux version is simply the Windows build with a bundled WinE. As a result, it has a horrible UX, making me even less likely to pay their outrageous license fees.

It's a lose-lose situation in cases like this.

It's not quite the case that using Wine is an alternative to porting. Sometimes the port itself simply bundles Wine. Some say that this "doesn't count", but when Wine works well users can't tell the difference between this and a port that required rewriting things.

I doubt any game developer decides not to release a Linux version purely because "oh, Wine exists".

Mac game "developers" do. :(

Thanks to TransGaming and Cider, a lot of Mac "ports" are just a Windows executable running in their proprietary fork of Wine. To predictably awful result.

Game developers no idea, application developers yes. TeamViewer and Softmaker Office are programs I ditched in frustration because their official Linux "ports" are the Windows versions bundled with a bugged WinE wrapper around them.

I think game developers are a bit of a unique case, because a large chunk of the linux gaming community is pretty hostile towards wine ports. There is no linux proprietary application community

> There is no linux proprietary application community

Except in CAD, academic tools, analytics, mod/sim, graphics, industrial automation... basically anything that used to run on Unix or might use a fortran library somewhere.

The problem here is that Wine is buggy, not that application developers aren't all rewriting everything.

It's not a game, but LTSpice from Linear doesn't have a Linux release because it runs on wine; though, they do try to make sure it works on wine.

Out of curiousity, do you use wine-staging and the CSMT patches?

I use wine-staging yes.