首先澄清一个问题, 很多同学其实是误会了, 以为只要搞定了Delphi 就能很快写快餐程序了. ios 本身的知识还是需要一些的, 并没有什么捷径可以走. 但如果一个团队有分工协作的话, DelphiXe4 也可以考虑作为一种技术方向. 用对了地方, 就可以发挥Delphi的长项了. 数据库程序和应用应该是不成问题的. 数据处理什么的. 毕竟有很多高质量的组件. 只要是平台无关的, 都会很容易在多个平台上得到支持. Mac上应用市场还是挺大的. 得找对了方向. 或者说需求.
虽然对Andriod的支持目前还没有, Free Pasacal 的方案已经有了. 鉴于我还没有实际折腾过 Andriod 就不做评论了, 只记录一下自己的期待.
既然同时支持 Andriod 和 iOS 甚至于其它设备. 就要想办法弥补Native UI的裂痕. 以及UI Style . 如果不能完全统一成一个中间层, 比如FMX . 那就只能 M V C分离了, 对应平台去设计窗体样式等, 逻辑代码是一份. 其实Xe2的方式已经支持andriod ios 了. Xe4换了个方案, 走编译器底层. 我觉得这是一种意识, 毕竟如果100%依靠Xcode工作的话, 只有pascal语法有价值了. Delphi Ide 以及组件资源优势都没办法发挥. 当然, 现在也不是100% 所见即所得的, 越多的使用 原生的接口 ,越多的依赖于iOS 本身. 距离跨平台就越远. 举个例子：同样是http操作, 用 idHttp 就是跨平台的, 以后会支持andriod的. 而用 ios 自带的 NSURL 什么的 就不行了. Xe4 有个概念是 PropertyAcess ,现在看概念的意思多一些.
真的用起来,你会发现如果想发挥长处,就不可避免的会深度耦合于某个平台. 毕竟不是所有的功能都可以实现. Apple 又不允许使用私有Api.
通过IDE设定的方式的确 可以节省很多代码的编写, 而加载和释放也无需操心过多 . 要是objective c 还得熟悉整个流程, 还要为delegate的函数编写代码. 自己加载图片什么的.
这些在delphi里还是老路子, 拖拽就ok.
说到UI了,其实现在连FMX自己的很多细节也都不够IOS, 比如 没有轮菊花, 耗时一点的, 用户都不知道干啥呢.
还有UI定制的功能, 比如重设界面的背景图, tableview的cell的样式什么的 我还在摸索中.
Delphixe4开发App是一点问题都没有. 就是看功能了. 就是看能做什么就做什么.别想着不着边的事.
说到这里, 我现在发现其实 游戏是最容易达到跨平台的. 游戏UI部分肯定是平台无关的. 所以只要拿到系统的 opengles的接口, 剩下的就顺理成章了.
但游戏最终也是个软件产品, 所以要整合平台的功能, 广告啥的,还是需要平台的知识的.
最后的就是一句话: 该delphi的事 就是提高开发效率, 组件优势明显, 减少非核心代码. 该是ios andriod的事, 还得去学习去解决, 甚至多了一层ios 到 delphi的事.
做游戏的话,也有一些选择, zengl, asyphre hge(pascal) 但想不出来有什么优势. 现在各种engine framework 都很多. js 的 vb的 c++的 as 的. 所以不用太担心跨平台的事, 更应该专注于游戏产品本身. 不如就中规中矩的用 cocos2d-x /iphone , 或者学学Unity3d 做画面更亮的. 但归根到底你会发现， 游戏的结构啊, 数据管理, 乃至公式什么的, 都是一样一样的. 跟上面那些引擎啥的一点关系也没有. 做游戏的确是个很挑战的事.