I guess I should have been more specific in my use of the term "platform". In my world, "platform" necessarily implies hardware architecture unless otherwise specified (with the term "environment" referring the the OS/toolset unless otherwise specified). In the case of existing symbian devices (such as the E71) and the N900 (the comparison for which the demonstration was made), these cases would be different platforms even if they were both running the same OS or not, and thus would need a re-compile in order to fully take advantage to the respective cpu instruction sets (is there a performance-hindered, but compatibility-maximized least common denominator for the ARM series like there is in the intel world by compiling to "target=386"?). That was the point I was trying to make in reference to Cap'nCorrupt's questions/musings regarding an emulation layer to make the applications work cross-platform: They will either work because they can run natively (ie identical binary) due to the same platform or compiled to some least-common-denominator platform, or they will need to be recompiled. There is no vm/bytecode equivalent in the QT world as there is in Java, nor is QT a "just-in-time" language like python...and there's no emulation layer that's acting as glue to create the cross-platform capability. QT is basically a macro-ing engine for C++ if you want to get down to brass tacks...with the SDK handling all the "IFDEF" stuff for you behind the scenes. All the other usual restrictions regaring re-compilation remain the same as they would for a C++ application.