@David<div><br></div><div>I don't have specific technical issues with FireMonkey as such, just a general feeling that it's too niche in an already niche area.</div><div><br></div><div>When I am developing code for OS X I am going to run into problems that I need to solve and areas of the Cocoa framework that I need to learn about. The bast majority of samples and other sources of assistance out there will be assuming "native" Cocoa development, and access to native facilities in the framework. There will be precious few such sources of assistance that can be directly applied to FireMonkey code that aren't written specifically with FireMonkey in mind.</div>
<div><br></div><div>Things like "Synchronise" in multi-threaded code for example.</div><div><br></div><div>FireMonkey incorporates the same complicated and potentially fragile Synchronise mechanism that the VCL is hobbled by, but both Windows and OS X have native mechanisms for ensuring that code is performed on the main application thread. FireMonkey doesn't use either of those mechanisms on Windows or OS X.</div>
<div><br></div><div>On Windows, I have my own "native" Synchronise implementation (create a form in the main thread and send it messages to be processed simply as part of the message queue - much simpler, more lightweight and more reliable than the VCL "Synchronise"mechanism).</div>
<div><br></div><div>On OS X the equivalent would be even more simple: just invoke "performSelectorOnMainThread", but as far as I have been able to tell, there is quite simply no way to get at or utilise this mechanism from Delphi.<br>
</div><div><br></div><div><br></div><div>To an extent this is a separate question from whether or not a generic, non-platform specific GUI layer was the preferable/more correct choice rather than creating a visual controls framework specific for each platform, but equally a non-platform bound approach intrinsically favours that generic solution since platform binding in the GUI Controls typically necessitates a much closer affinity to the underlying platform. In the case of the likes of OS X that means the Cocoa runtime.</div>
<div><br></div><div>Compare and contrast the two approaches to OS X support undertaken in FPC</div><div><br></div><div>First, a runtime "bridge" between the FPC runtime and the underlying platform runtime:</div>
<div> </div><div><a href="http://wiki.freepascal.org/PasCocoa#The_information_on_this_page_is_legacy_and_only_available_for_historical_purposes._Please_see_FPC_PasCocoa_for_current_information">http://wiki.freepascal.org/PasCocoa#The_information_on_this_page_is_legacy_and_only_available_for_historical_purposes._Please_see_FPC_PasCocoa_for_current_information</a>.</div>
<div><br></div><div>This first approach will be very familiar to anyone who has done any OS X coding in Delphi, with or without FireMonkey.</div><div><br></div><div>Now look at what replaced that approach:</div><div><br></div>
<div><a href="http://wiki.freepascal.org/FPC_PasCocoa">http://wiki.freepascal.org/FPC_PasCocoa</a></div><div><br></div><div>i.e. Language extensions that bring the platform runtime and concepts right into the language, in exactly the same way that the "message" and "automated" keywords do/did so successfully on Windows (and in fact, in FPC they managed to re-purpose that "message" keyword itself!).</div>
<div><br></div><div><br></div><div>Android ... ?</div><div><br></div><div>From the little that I have experimented with Android so far, I simply cannot see how they can extend the FireMonkey and platform bridge approach to Android at all successfully, never mind emitting the write code from the compiler back end.</div>