I have chosen several standard practices in those packages I now happen to use Qt and qmake for, to facilitate development, to better support distributed releases, and to provide better testability of my software.
In standardizing and documenting my own practices, I believe it is important not just for the code to be free, but also how to build a given project and manage the software lifecycle as well. There is no reason why one cannot produce high quality enterprise ready free as in freedom software, and many reasons why free software can and should produce better results.
Generally I assume qmake debug builds are to be primarily used for local development and testing. On debug builds I may short-circuit normal application behavior to improve testability, whether executed from qtcreator or stand-alone. I may for example disable external config files and give the application a default config and set of fixed data to easily test with, or add api's to facilitate testing automation. These features and behaviors are then stripped from release builds.
I generally produce binary installers out of release builds by using an alternative make target. Installers and release packaging are typically created with deploy. This may include access to internal deployment resources, ssh keys, etc, and so they are hooked thru an optional Deploy.pri. Stand-alone source tarballs that can be redistributed are always producible.
Coding and Resources
My desktop apps often use Qt ui forms. To better support cross-platform desktops, I make use of per-platform style sheets to do small adjustments in spacing and style where needed. The default cross-platform icon set and artwork are my own locally produced, and were designed and adjusted specifically to also render sharply when scaled at 16 and 24 pt sizes, as well as providing matching hidpi icons. I chose glyph style icons for use on windows and mac, largely because they were the easiest to make, and use themed icons on GNU/Linux and other platforms where supported.
I have also standardized multi-language localization for my desktop applications. A .ts file for each language will be kept in the extras/ directory, and .qm files will be auto-generated by qmake on the build host using lrelease. Along with ui elements, translations will be auto-embedded in the executables.
I may use of Qt pri's to better segment the codebase when used from QtCreator. This makes it easier to gather common functionality together and provide structure to the overall project without having to segment the package into static libraries or lots of subdirectories. It also makes for easy isolation and re-use of source components directly.
I try to use Qt 5.x style signal-slots exclusively, and I have chosen to generally standardize around c++11 in all my newer c++ applications. I also make use of Qt style naming conventions in my code.
Platform Specific Issues
For both Windows and MacOS platforms I presume the Digia online installer will be used to install Qt itself, rather than working with ports (such as macports) or self-built configurations. I will then bundle the Digia Qt runtimes for application deployment (using windeplyqt & macdeplyqt). If I need to create additional frameworks, plugins, and other dependencies for those platforms, they will be initially installed in the Digia Qt installation directories first. This seemed simpler for managing Qt development on those platforms.
On MacOS I will produce desktop applications as application bundles, and any additional libraries I may provide for use with Qt will be distributed as frameworks as well. On GNU/Linux I use the distro version (for BSD, the ports collection version) of Qt, with both applications and any additional libraries installed in standard /usr paths by default. On GNU/Linux and BSD I also use XDG standards for setting desktop menus. On GNU/Linux I will use standard distro packaging (debian, rpm, etc) to make installable applications, and on both GNU/Linux and BSD the original source tarballs may also be directly used to produce and install my applications. In the case of Windows, I will typically provide applications with an INNO Setup generated installer.
On MacOS one should also be able to directly use homebrew, and the versions of Qt included with those. I auto-detect such uses based on the Qt prefix directory. When using homebrew or similar, I do not create application bundles and instead the build follows normal unix conventions.