iCL native controls versus FireMonkey controls
In this article, we'll try to explain what TMS iCL is, what it isn't and why it can matter for your Delphi applications for iOS.
What is TMS iCL?
TMS iCL is a component library. It stands for iOS Component Library. It is a Delphi component library and as such, it is accessible as Delphi objects with properties, methods, events. The components are in fact wrappers around the iOS operating system level defined controls, for now mostly visual controls. In iOS Objective C terminology, UIView types. In this respect it is very similar to the Delphi VCL standard components like TEdit, TButton, TListbox ... etc. These VCL controls are tiny wrappers around the Windows operating system controls like EDIT, BUTTON, LISTBOX ... These standard Delphi controls do not do much more than present the Windows user interface controls as Delphi classes with properties, method and events. In the case of TMS iCL, these controls are usable from a FireMonkey form, just like VCL controls are usable from a standard VCL form.
How is an iCL control different from a FireMonkey control?
As iCL controls wrap iOS operating system controls, the entire look & feel as well as feature set of the iCL control is defined by what the iOS control offers. As such, TMS iCL controls are not style-able FireMonkey controls. In fact, an iCL control has very little in common with a FireMonkey control. Where a FireMonkey control look is defined by a (customizable) hierarchy of style elements (such as rectangles, labels, etc...) that are rendered in a Quartz or OpenGL canvas by the FireMonkey framework itself, an iCL control is rendered by the iOS operating system. Where a FireMonkey control's keyboard and mouse (touch) handling is in fact handled by redirected FireMonkey form level keyboard and mouse (touch) handling, the operating system itself handles all this for the iCL control, or better the underlying UIView or similar control. The main result is that an iCL control is not style-able or extensible in the same way as a FireMonkey control and you won't find the typical keyboard or mouse (touch) events as in a FireMonkey control.
iCL and FireMonkey coexist
What is nice is that iCL controls and FireMonkey controls coexist fine on the same FireMonkey form. In fact, we have even created a FireMonkey form wrapper that makes it possible to embed or use these FireMonkey forms with iCL controls (like a tableview detail or popover for example)
Why use iCL controls?
Two very important considerations might make you consider using iCL controls: performance and consistency. While a FireMonkey control always remains an emulation (by means of a style element hierarchy) of an operating system control, the iCL control is the real thing. The iCL control is not just pixel-perfect, whatever the real meaning of pixel-perfect might be, it is just 100% perfect as it is the real control. The same applies to the behavior. Interaction with touch is not just simulated by FireMonkey animations inside in the control, but is the exact Apple defined behavior. Think about the exact scroll bounce effect, the exact glow on touch, the exact slide animation. With this also comes performance. iCL exposes the performance of the operating system control that Apple has maximised and fine-tuned. The best example of this is the tableview that remains extremely fast and responsive, irrespective of the number of items or the complexity of what is displayed in tableview items. A final consideration is that an iCL control is by definition operating system version agnostic. It has by definition always the exact appearance of the operating system control and makes the application that uses them consistent with iOS. An example of this is the switch control where Apple modified the appearance slightly between iOS 5 and iOS 6. The iCL control will always have the right look. As iOS 7 is expected to have a different look again with Jonathan Ive now responsible for the Apple UI design, the iCL will effortless make your app look consistent with iOS 7.
Why use FireMonkey controls?
The standard operating system controls in iOS are quite limited. There is no grid, there is no syntax highlighting memo, there is no chart, ... etc... Much like we have thousands of VCL controls that offer functionality that is not in the operating system, FireMonkey controls exactly offer these extras. The good news is that you can mix both control types to take advantage of each where it fits.
The 'native' confusion
We get quite a number of emails from users asking what the difference is between what is called 'native' FireMonkey mobile applications and iCL native controls. The definition of the exact difference between 'native' and 'native' would take a few pages to explain when applied to the FireMonkey framework in XE4. We'd like to summarize this in a nutshell. iCL exposes the native iOS control where a Delphi FireMonkey application runs as a native, i.e. ARM CPU machine language app on the iOS device. So, a Delphi FireMonkey application using iCL controls is about as native as an Objective C X-Code iOS application.
Limitations
Of course, the first important limitation is that an iCL control is only usable for iOS device applications. So, iCL is like VCL not cross-platform. As we make the iCL controls accessible from the Delphi IDE form designer, running directly on Windows, this means we are forced to show a sort of emulation of the control in the IDE form designer. In the first version, we have chosen to implement only a very rough and basic emulation of the control. As the code to do this being part of the control normally sits in the app and doesn't do anything, we wanted to minimize this bloat. For future versions, we consider to implement the design-time emulation this way that this code won't get linked with the app. Finally, there is currently an RTL limitation that limits the number of different iOS control classes usable in a form.
We have notified Embarcadero about this bug and hope Embarcadero will solve this as soon as possible. The limitation right now is such that for a typical application using some mix of iCL controls won't be affected, but when building something like an iPad form where you intend to use every single iOS control that we offer on the same form, it is likely that you'll bump into this limitation and the application will simply crash when the form opens on the iOS device.
Freedom of choice
After all, it is all about offering Delphi developers freedom of choice to use the technology that fits best their needs and using iCL is just one more such choice. If you struggle with a performance issue, if iOS consistency and 100% UI compliance is a major concern for you, you can now use iCL controls and where some functionality is missing in the standard controls, just add existing, your own or TMS FireMonkey controls. These are exciting times for Delphi developers, so, happy coding!