Interesting perspective - we deploy our QT app on Linux, osx and Windows, but I find that the best experience has been on Windows. (we statically link QT and boost, which may cause more headaches than the default dynamic linking).
Specifically, maintaining backwards compatibility on OSX while marching forward with newer versions of the os has been a very big pain. We recently dropped support for OSX 10.6 because we simply could not get QT to statically compile on Yosemite, even after extracting the 10.6 SDK from a legacy xcode download. We did manage to keep 10.7 support though, thankfully, using the same SDK extraction method.
On Linux, the upgrade from QT 4.8 to 5.4 was the roughest. the number of dependencies dramatically increased, complicating the compilation of QT and breaking compatibility with older distros (specifically CentOS 6.x, where we hear the most complaints)
Windows & visual studio has always been our preferred developer environment, with the latest version of both. Maintaining support back to Windows XP has been particularly easy and painless. Where on Linux, it seems like the glibc requirements march forward with every release of gcc, and on osx it becomes dramatically more difficult to support older versions of the os with each new release.
A side note about QT on Windows - compiling QT and your application on the newest version of Windows helps a lot for customers on that platform - for instance, before we compiled on Windows 8, the application UI would default back to the legacy battleship grey theme, and simply rebuilding on Windows 8 with no source modifications fixed it.
on linux a couple of compiler flags (FORTIFY_SOURCE, etc) and providing a memcpy wrapper would get you compatibility back to about 2006. To go back further the glibc you compile against can have an earlier version of the linux kernel specified. I only bothered with 2.6.16 (or was that 18) at the time.
Specifically, maintaining backwards compatibility on OSX while marching forward with newer versions of the os has been a very big pain. We recently dropped support for OSX 10.6 because we simply could not get QT to statically compile on Yosemite, even after extracting the 10.6 SDK from a legacy xcode download. We did manage to keep 10.7 support though, thankfully, using the same SDK extraction method.
On Linux, the upgrade from QT 4.8 to 5.4 was the roughest. the number of dependencies dramatically increased, complicating the compilation of QT and breaking compatibility with older distros (specifically CentOS 6.x, where we hear the most complaints)
Windows & visual studio has always been our preferred developer environment, with the latest version of both. Maintaining support back to Windows XP has been particularly easy and painless. Where on Linux, it seems like the glibc requirements march forward with every release of gcc, and on osx it becomes dramatically more difficult to support older versions of the os with each new release.
A side note about QT on Windows - compiling QT and your application on the newest version of Windows helps a lot for customers on that platform - for instance, before we compiled on Windows 8, the application UI would default back to the legacy battleship grey theme, and simply rebuilding on Windows 8 with no source modifications fixed it.