delphi开发速度迅捷至少有30%（猜的，呵呵）的原因是因为其字符串（string、WideString、PChar、PAnsiChar等)处理能力。
而从delphi XE4开始，在system等单元中，出现了一个叫 NEXTGEN 的编译条件，这条件是在进行移动开发时自动定义的，而传统桌面开发时没有定义NEXTGEN。
这个编译条件直接导致原来的PAnsiChar、AnsiString无法使用（传统桌面开发没有影响），只要稍微接触深入，即可发现，其实并不是无法使用，字符串类型新增了如下定义：
1 {$IFDEF NEXTGEN} 2 _ShortStr = _ShortString; 3 _AnsiStr = _AnsiString; 4 _AnsiChr = _AnsiChar; 5 _WideStr = _WideString; 6 _PAnsiChr = _PAnsiChar; 7 {$ELSE} 8 _ShortStr = ShortString; 9 _AnsiStr = AnsiString; 10 _AnsiChr = AnsiChar; 11 _WideStr = WideString; 12 _PAnsiChr = PAnsiChar; 13 {$ENDIF} 14 MarshaledString = PWideChar; 15 MarshaledAString = _PAnsiChr;
其中带下划线开头的“_XXXX”的定义属于内部定义，无法直接使用，而我们也可以看出原来的PAnsiChar定义为_PAnsiChr，而_PAnsiChr则统一定义为MarshaledAString，也就是说，原来使用PAnsiChar的函数，其实可以使用MarshaledAString代替，不过这样是一种折中的做法，毕竟谁也不知道以后的变化，能用PChar和string就尽量用吧。
实际使用中也确实没有什么影响，但是在多平台开发中，为何delphi将原来的PAnsiChar去掉，使用MarshaledAString呢，其实在java、.NET中，已经很早就有这类托管的数据类型了，只是作为传统的delphi桌面开发人员，并不熟悉也不太想去熟悉，而使用托管的字符串数据类型一方面是实现内存的自动回收管理，另一方面也是方便各种字符串编码的转换。
个人认为，在Windows系列PAnsiChar就是Ansi编码，而在unix系列的PAnsiChar应该都是Utf8编码，作为跨平台开发语言，需要尽量屏蔽这种差异。
相信delphi XE系列的目标是将所有平台的字符串类型转换为string（即UnicodeString），只要使用VLC的函数，即可不关心当前平台的字符串类型，这种做法也将慢慢的屏蔽掉AnsiString，WideString等写法，而全部统一PChar和string（内部其实是PWideChar和UnicodeString）。
想法和做法都是对的，只是很多时候对开发人员来说是无奈的，毕竟很多操作系统的特殊功能是无法通过封装去实现无缝移植的。
关于字符串的变化，甚至导致classes中的BinToHex和HexToBin函数出现相当麻烦的变化，有兴趣的朋友可以去看看。
字符串相关的处理也出现了很多新的类型：
1） TMarshaller ：作为新字符串类型的转换类（其实是record，但是现在Record和Class其实功能上差别已经很小），可将string转换为ANSI、UTF8等
2） TStringBuilder：各种字符串处理功能，添加、比较、插入、转换等
字符串下标
默认情况下，在FMX中，Windows平台的string下标从1开始，移动平台下的string下标从0开始，而stringhelper中统一从0开始，
此前循环体中的for I:=1 to Length(sStr) do 的写法无法兼容所有平台，可以使用Low和High的写法，即 for I:=Low(sStr) to High(sStr) do
另外，可以使用编译条件来打开或关闭0下标的编译功能：
{$ZEROBASEDSTRINGS ON} //开启 0下标（在Windows平台使用后从0开始） {$ZEROBASEDSTRINGS OFF} //关闭 0下标（从1开始，在移动平台上使用后从1开始）