When developing applications for iOS using Delphi XE2, it uses a smart but convoluted FPC detour.
That results in a few things you should take into account when developing iOS applications:
- Do not use Unit scope identifiers (that’s why for instance the FireMonkey unit FMX.Dialogs is called FMX_Dialogs when building an iOS application)
So don’t do a “uses System.SysUtils”, but “uses SysUtils” and don’t name your units using Unit scope identifiers for now.
It would be so nice if Embarcadero shipped the tool that made all the FMX_* units out of the FMX.* units; that alone would make code sharing between non-iOS and iOS applications in Delphi a lot easier.
- Do not use Generics (though FPC supports them, the FPC mode that Delphi XE2 uses for iOS compatibility does not)
- Do not use new style RTTI or TValue (they are not supported by FPC)
- Do not use any other dataset than the ones directly descending from TDataSet (so anything TClientDataSet or IBX like is out) mostly because those depend on external C obj files, Unit scope identifiers or new style RTTI
- Do not spread your application sources over multiple directories
- Do not use the TMyDynamicArray.Create shortcut of initializing dynamic arrays, but use a wrapper function that uses Open Array parameters as Rob Kennedy explains on StackOverflow.
- Do not run dpr2xcode after you have changed any files it generated (believe me, you will change those). This basically makes you have to reinvent most of the dpr2xcode logic, which is a real pain, as I’m still in that process and not completed.
These are the things you usually want to manually keep track of:
- most of the manual changes are keeping the “YourProject.dpr” and dpr2xcode generated “YourProject.pas” in sync
- altering the PNG files to show different splash graphics / application icons
I will extend this list over time.
Note that this detour should be gone in a future Delphi version, but for now you need to take the above into account.
It means that you might feel like programming with one hand behind your back. Well, the Objective C and Xcode way feels very similar, but from a different perspective :)