1. 项目概述：为什么需要梳理Delphi的平台支持？
如果你是一个Delphi的老用户，或者正考虑将某个历史悠久的桌面应用现代化，那么“Delphi到底支持哪些平台？”这个问题，绝对是你绕不开的坎。从经典的Delphi 7到最新的Delphi 12.3（或按版本号称为D12，即Delphi 12 Athens），再到即将到来的Delphi 13（D13），Embarcadero（以及之前的Borland、CodeGear）对平台支持的策略发生了翻天覆地的变化。尤其是在Delphi XE4（2013年）这个关键节点之后，FireMonkey框架的成熟和移动开发的兴起，彻底改变了Delphi的生态。
我见过太多项目，在升级或迁移时，因为对平台支持范围理解不清而踩坑。比如，一个用Delphi XE2写的FireMonkey应用，想直接编译到最新的macOS Sonoma上，却发现链接器报错；或者一个VCL老项目，想尝试发布到Linux服务器，却发现无从下手。这些问题的根源，就在于没有一张清晰的“平台支持地图”。
这篇文章，我就结合自己从XE时代一路用到D12的经验，以及官方文档和社区动态，为你彻底梳理从Delphi XE4到Delphi 13（基于当前已发布和预览信息）所支持的平台和操作系统。这不是一份简单的列表，我会重点解释每个平台支持背后的技术架构（VCL vs. FireMonkey）、编译器差异、部署要求，以及在实际开发中你会遇到哪些“坑”和“惊喜”。无论你是维护遗产代码，还是启动一个全新的跨平台项目，这张地图都能帮你做出更明智的技术决策。
2. Delphi XE4~XE8：移动时代开启与FireMonkey的进化
这个时期是Delphi转型的阵痛期与机遇期。Delphi XE4（2013年发布）是一个里程碑，它首次正式将iOS支持纳入产品线，而XE5则加入了Android支持。至此，Delphi凭借FireMonkey（FMX）框架，正式吹响了向移动平台进军的号角。
2.1 核心平台支持矩阵（XE4~XE8）
我们先看一张简表，了解这个阶段的基础支持情况：
| 版本 | Windows (VCL) | Windows (FMX) | macOS (FMX) | iOS (FMX) | Android (FMX) |
|---|---|---|---|---|---|
| XE4 | Win32 (32-bit) | Win32, Win64 | ❌ 不支持 | iOS (32-bit, Device+Simulator) | ❌ 不支持 |
| XE5 | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32-bit) | Android (ARMv7) |
| XE6 | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32-bit) | Android (ARMv7) |
| XE7 | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32-bit) | Android (ARMv7) |
| XE8 | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32-bit) | Android (ARMv7) |
关键解读与实操要点：
Windows的绝对主场：这个时期，Windows平台依然由经典的VCL（Visual Component Library）和新兴的FMX共同覆盖。VCL仅支持32位Windows（Win32），这是其技术根基决定的。而FMX项目则可以编译为32位或64位Windows应用。对于需要原生Windows外观和极致性能的桌面应用，VCL仍是首选；对于希望代码能跨平台（尤其是移动端）的项目，则必须选择FMX。
移动平台的初探：
- iOS：从XE4开始支持，但仅限于32位。这意味着你只能针对较老的iOS设备和模拟器进行开发。随着苹果在iOS 11（2017年）后彻底停止对32位应用的支持，用XE4~XE8编译的iOS应用早已无法提交到App Store，甚至在新设备上无法运行。这是一个巨大的历史局限性。
- Android：从XE5开始支持，目标是ARMv7架构的处理器（俗称32位ARM）。这在当时覆盖了绝大多数Android设备。部署时需要配置Android SDK/NDK路径，这是第一个让许多Windows开发者感到陌生的环节。
macOS的缺席：是的，在这个阶段，Delphi官方并不支持直接开发macOS桌面应用。虽然FMX框架设计时考虑了跨平台，但macOS的编译器后端和配套框架尚未就绪。社区有一些非官方的移植方案（如用Free Pascal编译），但并非生产级选择。
2.2 技术架构与踩坑实录
这个阶段的跨平台，可以概括为“同一套UI代码，多个后端渲染器”。FMX框架在Windows上使用DirectX或GDI+进行渲染，在iOS上使用原生Core Graphics，在Android上使用自定义的基于OpenGL的渲染引擎。这种设计带来了灵活性，也引入了复杂性。
我踩过的一个典型坑：控件的像素级差异。在Windows上设计得完美无缺的界面，在iOS或Android上可能出现布局错乱、字体渲染不一致、甚至某些特效（如模糊、阴影）表现迥异。这是因为不同平台底层图形API的行为不同。解决方案是必须进行真机多轮测试，并使用TForm.Scaled属性、PlatformVariant风格以及条件编译（{$IFDEF IOS}）来微调每个平台的UI细节。绝对不要假设“一次设计，处处完美”。
另一个常见问题是第三方控件的兼容性。许多优秀的VCL控件库（如DevExpress VCL, TMS, ComponentOne等）在这个时期开始推出对应的FMX版本，但功能完整度和稳定性往往滞后于VCL版。在选择控件时，必须仔细核查其宣称支持的FMX平台列表，并最好能找到试用版进行实际跨平台编译测试。我曾遇到一个图表控件在Windows FMX上工作正常，但在Android上直接导致应用崩溃，原因是其使用了某个不兼容的底层API。
部署与签名也是大坑。为iOS应用申请开发者证书、配置Provisioning Profile、理解Ad Hoc与App Store发布的区别；为Android应用生成Keystore、对齐Zip。这些流程对于传统的Windows开发者来说完全是新领域。XE系列自带的部署工具（Deployment Manager）虽然提供了一些帮助，但很多细节仍需手动配置或通过命令行脚本完成。我的经验是，尽早建立一套自动化构建和签名脚本，可以节省大量后期调试时间。
3. Delphi 10.x 系列（柏林~悉尼）：64位、Linux与macOS的加入
Delphi 10 Berlin（2016年）开启了10.x时代，这是一个平台支持大幅扩展的时期。最重要的变化是：64位编译器成为主流，并且加入了Linux和macOS服务器端支持，以及后来的macOS桌面端支持。
3.1 平台支持的重大扩展
| 版本 | Windows (VCL) | Windows (FMX) | macOS (FMX) | iOS (FMX) | Android (FMX) | Linux Server |
|---|---|---|---|---|---|---|
| 10 Berlin | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32-bit) | Android (ARMv7) | ❌ 不支持 |
| 10.2 Tokyo | Win32 | Win32, Win64 | ❌ 不支持 | iOS (32 & 64-bit) | Android (ARMv7) | ✅ 引入 (Console App) |
| 10.3 Rio | Win32 | Win32, Win64 | ✅ 引入 (64-bit) | iOS (64-bit) | Android (ARMv7, ARM64) | ✅ 支持 |
| 10.4 Sydney | Win32 | Win32, Win64 | ✅ 支持 (64-bit) | iOS (64-bit) | Android (ARMv7, ARM64) | ✅ 支持 |
关键解读与实操要点：
iOS 64位支持（10.2 Tokyo）：这是生死攸关的更新。从10.2 Tokyo开始，Delphi的iOS编译器支持生成64位代码，使得开发的App能够符合苹果App Store的上架要求，并支持所有现代iOS设备。如果你有从XE时代遗留下来的iOS项目，升级到10.2 Tokyo或更高版本是将其现代化的第一步。迁移过程通常比较平滑，主要工作是重新配置开发证书和更新一些可能废弃的API。
Android ARM64支持（10.3 Rio）：随着64位Android设备的普及，Google Play也逐步要求应用支持64位架构。10.3 Rio增加了对ARM64（AArch64）的支持。在项目配置中，你可以选择同时生成ARMv7和ARM64的应用包（APK），或者只生成64位版本以减小包体积。注意：如果你的项目使用了特定的原生库（.so文件），必须确保有对应的ARM64版本，否则在64位设备上会崩溃。
Linux服务器端支持（10.2 Tokyo）：这是一个战略性的转变。Delphi开始不再局限于客户端UI应用，而是进军服务器端领域。10.2 Tokyo引入了对Linux（最初是Ubuntu和RHEL/CentOS）的控制台应用程序支持。这意味着你可以用熟悉的Object Pascal编写Web API服务器（配合框架如
DelphiMVCFramework）、后台服务、数据处理工具等，并部署到廉价的Linux云服务器上。技术栈上，它使用的是非UI的“可移植类库”，很多VCL/FMX的UI控件不可用，但核心的RTL、数据库访问（FireDAC）、网络（Indy）等都能正常工作。macOS桌面端支持（10.3 Rio）：千呼万唤始出来。10.3 Rio终于带来了官方的macOS桌面应用开发能力。同样是基于FMX框架，你可以将Windows上的FMX应用编译为64位的macOS应用（.app）。这背后是Embarcadero与苹果LLVM工具链的深度集成。实测体验：第一次将Windows FMX应用编译到macOS上运行，感觉非常奇妙。大部分业务逻辑代码无需修改，但UI需要针对macOS的HIG（人机界面指南）进行调整，例如菜单栏、窗口样式、字体渲染等。同样，第三方控件的macOS兼容性需要重点评估。
3.2 Linux与macOS开发的实操细节
Linux服务器开发：
- 编译器：使用LLVM-based的
dcclinux64编译器。 - 部署：产出是一个标准的Linux ELF 64位可执行文件。你需要通过FTP/SCP等方式将其上传到Linux服务器。
- 依赖库：这是最大的坑。你的程序可能依赖一些系统库，比如
libc.so,libpthread.so等。在开发机上（通常是Windows），Delphi通过一个“SysRoot”目录来模拟Linux环境，其中包含了链接时需要的库文件。但务必注意，开发机SysRoot中的库版本必须与目标服务器上的库版本兼容。最好使用与目标服务器相同或相近版本的Linux发行版作为SysRoot来源。我曾因为开发机使用Ubuntu 18.04的SysRoot，而服务器是CentOS 7，导致程序运行时链接失败。 - 调试：远程调试支持有限，更多依赖日志输出。建议在代码中集成强大的日志系统（如
CodeSite或LoggerPro）。
macOS桌面开发：
- 编译器：使用基于苹果Clang/LLVM的
dccosx64编译器。 - 开发环境：必须在Windows主机上安装一台macOS虚拟机或拥有一台网络可达的macOS编译服务器（Paserver）。Delphi IDE将代码发送到macOS机器上进行编译和链接。
- 签名与公证：从macOS Catalina开始，未签名的应用运行会受到诸多限制。你需要加入苹果开发者计划，为应用签名，甚至进行公证（Notarization），才能分发给其他用户。这个过程比iOS签名更复杂，涉及创建开发者ID应用证书、配置Entitlements文件等。强烈建议：在项目初期就搭建好签名流程，不要等到发布前才处理。
- UI适配：FMX在macOS上使用Cocoa后端。要尊重macOS的设计规范，例如使用
TMainMenu并正确设置NSMenu的属性，处理“关于”窗口和偏好设置的标准位置等。可以使用TPlatformServices来调用一些平台特有的服务。
4. Delphi 11/12/13 (ALEXANDRIA~)：统一与深化，瞄准未来
从Delphi 11 Alexandria（2021年）开始，Embarcadero的发布节奏和平台战略趋于稳定。目标很明确：巩固并优化现有平台支持，提升开发体验和代码质量，同时为未来的新平台（如ARM64 Windows）铺路。Delphi 12 Athens和预览中的Delphi 13进一步强化了这一路线。
4.1 现代Delphi的全平台视图
| 版本 | Windows (VCL) | Windows (FMX) | macOS (FMX) | iOS (FMX) | Android (FMX) | Linux Server | Android (FMX) 64-bit | macOS (ARM64) |
|---|---|---|---|---|---|---|---|---|
| 11 Alexandria | Win32 | Win32, Win64 | 64-bit (Intel) | 64-bit | ARMv7,ARM64 | 64-bit | ✅ 成熟支持 | ❌ 仅Intel |
| 12 Athens | Win32 | Win32, Win64 | 64-bit (Intel) | 64-bit | ARMv7, ARM64 | 64-bit | ✅ | ✅实验性支持 |
| 13 (预览) | Win32 | Win32, Win64,ARM64 | 64-bit (Intel/ARM) | 64-bit | ARMv7, ARM64 | 64-bit | ✅ | ✅正式支持 |
关键解读与实操要点：
Android ARM64的成熟：从11 Alexandria开始，对Android ARM64的支持已经非常稳定，成为新建项目的默认选择。Google Play现在强烈推荐甚至要求上传64位版本。在Delphi中，只需在“Project > Options > Building > Target Platforms”中勾选“Android 64-bit”，即可轻松生成对应的APK。
Apple Silicon (macOS ARM64) 的支持：这是近年来的热点。随着苹果Mac全面转向自研的ARM架构芯片（M1, M2, M3），应用需要原生ARM64版本以获得最佳性能。Delphi 12 Athens通过更新的LLVM工具链，提供了对macOS ARM64的实验性支持。这意味着你可以编译出“Universal 2”应用（同时包含Intel和ARM64代码）。到了Delphi 13，预计这将变为正式且完善的功能。对于需要发布到Mac App Store或面向新Mac用户的应用，这将是必选项。迁移时需要注意，所有依赖的第三方原生库（如果有）也必须提供ARM64版本。
Windows on ARM64的展望：Delphi 13的预览信息显示，其一个重要特性就是对Windows ARM64平台的原生支持。随着高通骁龙X Elite等芯片的推出，ARM架构的Windows设备预计会增多。Delphi提前布局，允许开发者用同一套代码（尤其是FMX）为未来的Windows ARM设备做好准备。这可能是继移动端之后，又一个重要的新市场。
VCL的坚守与局限：可以看到，VCL依然坚守着32位Windows的阵地。Embarcadero多次明确表示会继续维护VCL，因为它承载着海量的企业级遗产代码。但是，VCL的跨平台之路基本已经关闭。它的未来在于现代化改造，例如高DPI感知、视觉样式更新、与FMX共享非UI代码库等。对于全新的、需要跨平台的项目，FMX是唯一的选择。
4.2 平台选择的实战策略与心得
面对如此多的平台选项，在实际项目中该如何选择？以下是我的几点心得：
策略一：新项目，从FMX和多平台开始。如果你的项目是全新的，且潜在用户可能使用多种设备（Windows PC、Mac、手机、平板），那么毫不犹豫地选择FireMonkey（FMX）。从项目创建的第一天起，就为所有目标平台（至少是Windows 64-bit, macOS, iOS, Android）配置好构建配置。即使你暂时只发布一个平台，这种架构也能保证未来扩展时成本最低。使用TForm.StyleBook和样式来统一管理UI外观，而不是硬编码颜色和字体。
策略二：遗产VCL项目，采用“绞杀者模式”渐进迁移。对于庞大的VCL桌面应用，全部重写为FMX是不现实的。可以采用“绞杀者模式”（Strangler Pattern）：
- 将核心业务逻辑代码抽取到独立的、非UI的“共享单元”或“动态链接库”中。这部分代码通常与UI无关，可以很容易地被FMX新项目引用。
- 对于需要现代化或移动化的新功能模块，使用FMX开发一个新的独立应用或插件。
- 通过进程间通信（IPC）、本地网络接口或共享数据库，让新的FMX模块与老的VCL主程序协同工作。
- 随着时间的推移，越来越多的功能被迁移到FMX端，直到老的VCL主程序最终被“绞杀”替代。
策略三：服务器端，拥抱Linux。如果你正在用Delphi开发后台服务、API接口或数据处理工具，强烈建议将Linux作为首选部署平台。原因很简单：成本低、性能高、资源占用少。Delphi 10.2+的Linux服务器支持已经相当可靠。结合Docker容器化部署，可以轻松实现持续集成和弹性伸缩。在开发时，善用条件编译{$IFDEF LINUX}来处理平台特有的文件路径、系统调用等差异。
关于第三方控件的忠告：你的项目能走多远，很大程度上取决于你所选的第三方控件库对目标平台的支持程度。在选择控件库时，不要只看它宣传的“支持FMX”，一定要：
- 查阅官方文档，明确列出支持的具体平台（如：iOS 64-bit, Android ARM64, macOS）。
- 下载试用版，在你的所有目标平台上实际编译和运行Demo。
- 关注社区论坛，看其他开发者在该平台上使用该控件时是否报告了重大问题。
- 优先选择那些更新活跃、与Embarcadero新版本发布节奏保持同步的控件厂商。
5. 未来展望与总结：Delphi的平台之路
回顾从XE4到D13的历程，Delphi的平台支持策略清晰地反映了一条从“Windows专属”到“多端并进”的转型之路。FireMonkey框架是这场转型的技术基石，虽然早期磕磕绊绊，但如今已能胜任从移动应用到桌面软件的跨平台开发。Linux服务器端的支持则开辟了另一个广阔的战场。
展望未来，Delphi 13对Windows ARM64和macOS ARM64的强化支持，表明Embarcadero正在紧跟硬件生态的变革。对于开发者而言，这意味着我们手中的Pascal代码的生命力和适用场景再一次得到了扩展。
最后，分享一个我自己的项目决策框架：当启动一个新项目时，我会画一个简单的表格，横轴是目标平台（Win, Mac, iOS, Android, Linux），纵轴是功能模块。然后评估每个模块在每个平台上的必要性和实现复杂度。如果某个模块在某个平台上复杂度极高而必要性极低，也许可以考虑在该平台上简化或移除该功能，而不是强求100%的代码复用。跨平台开发的目标不是“一份代码，处处完美”，而是“一份核心逻辑，多端最佳体验”。在追求效率的同时，尊重每个平台的特性，这才是Delphi跨平台开发带给我们的真正挑战与乐趣。
