Each strong abstraction can easily become a golden cage for its user. This also applies to software development and frameworks where you may obviously like the fact the framework is hiding the complexity underneath and providing a simple, clean, and comfortable place where the developer can live with fewer worries with respect to a more raw approach where everything is the developer's responsibility (embracing the subsequent complexity as much as they can afford).
At the same time, this kind of safe playground (always) has some boundaries and the developer can sometimes reach one of these boundaries and will go (or need to go) further.
Delphi always shined in this, letting you stay warm and safe with your VCL components wrapping Windows controls but, at the same time, letting you directly call whatever external function was available, including, of course, all WinAPI functions. When coming to FMX, as I said, I considered it to be more than a visual framework but rather an application framework; this is still true because, even if you can’t handle FMX controls using APIs designed for native controls, you can still have your FMX (and RTL) Delphi code with platform-specific calls to the underlying APIs of the currently running OS.
This means you (from your Delphi code) can call any iOS library functions (as you would do in Objective-C or Swift). The same applies to Android where you can wrap (there is the Java2OP tool available for Embarcadero’s registered users) the Java code you want to reach into Delphi classes and functions and have it available for your application developer. Even though this may seem like a kind of last refuge for the developer, it also represents a guarantee that your framework (FMX) is not closed and you are actually able to get back to the metal as much as you like or need.
For example, it is not unusual, when writing Android apps on custom devices (that is, those including industrial-level optical or NFC/RFID readers) to have the manufacturer of the device provide it with a standard Android OS image with the addition of some external JAR files with the libraries needed to properly interface with some device-specific features. Also, it guarantees that if Embarcadero is not providing you this or that API wrapper, you may proceed and generate it (manually or with a tool such as Java2OP) without having to wait for official support for that functionality.
In the next section, we'll try to consider the good and the bad coming from the peculiarities of the FMX approach.
