Over the past year, we have had many customers ask about our plans to continue cross-platform multi-device support in C++Builder. We’d like to provide an update on our plans.
Platform Overview
We prioritized VCL work for C++Builder to FMX, which puts us behind on our support on platform support. Currently, C++Builder 10.4 supports:
- Windows 32 and 64-bit in VCL and FMX
- iOS 64-bit in FMX
- Android 32-bit in FMX
Those most impacted should already know the following, but to be clear: On August 1, Google’s deadline for 32-bit applications will come into effect and if you want to continue to update your apps on the Play Store, you will need to recompile them as Android 64-bit. C++Builder does not currently support this platform. We will not deliver Android 64-bit support by August 1st, nor in C++Builder 10.4.1 (2020.)
It’s worth noting that 32-bit Android applications are still fully functional – in fact, we released a hotfix to 10.4 solving C++ Android 32-bit exception handling issues a few days ago. Android devices still support 32-bit apps; it is only the Play Store that has the 64-bit limitation, meaning that in-house applications or sideloaded applications remain fully functional.
We also have not scheduled macOS 64-bit support for 2020. When we do, we will likely move directly to support ARM (Apple Silicon.)
If Android 64-bit is important to you, RAD Studio with Delphi is fully compatible. Contact us today to discuss a discount and make the switch.
Customer Feedback and Platforms
In March 2019, we sent out a customer survey. The overall feedback from our C++Builder customers in that survey was to ask us to focus on Windows and Windows quality: compiler quality, STL, and IDE (including code completion.)
The majority of our C++Builder customers are targeting Windows only, using the VCL. They do so because of VCL’s performance and the native controls, and the new controls we provide; further, Microsoft has created pressure to upgrade to Windows 10 and our Windows 10 support is highly useful to those migrating apps, or to those looking for a high-quality UI app environment for Windows 10.
The strategy this put us on was clear: to focus on Windows and ensure it met your expectations, ahead of working on other platforms. For this reason, we removed macOS Catalina support from the roadmap, and we have been working on Windows quality ahead of Android 64-bit support since then.
Windows Quality
We are very aware that since our Clang upgrade in November 2018, the quality for Windows, including IDE tooling, has not been what we want to deliver.
So what’s our plan? What are we addressing?
We have long-standing issues around code completion, the linker, some STL classes, and some compiler ICEs. Further, there are IDE productivity features we want to provide to ensure C++Builder surpasses other IDEs in terms of productivity. Our goal for Windows is the following:
For quality:
- To provide fully functional code completion and other Code Insight features
- To fully resolve all linker issues, possibly through an entirely new linker
- To resolve STL issues
- To provide excellent C++ compatibility with common C++ libraries, meaning we have excellent compatibility with other toolchains
For features:
- To provide further code tooling, such as refactorings, through integrating Visual Assist, meaning C++Builder will have stronger productivity tools than even Visual Studio
- To provide C++17 or higher language support
- To provide much more speedy, accelerated compilation speed especially for large projects
The ultimate aim here is to ensure that (a) things work as you want and expect, and (b) we are both compatible with general C++ (which helps you) and surpass other tools in productivity. Our libraries, like the VCL, are world-leading — having IDE productivity also at that level will make C++Builder a significant force.
While we are not there yet, that strategy explains our focus and what we have delivered since that survey. Let’s dig into both what we have delivered, and what we have planned, with some comments that explain them in light of the above.
Improvements
In the time since that survey, we have delivered:
- Windows 64-bit C++17, meaning that you can target Windows 32- and 64-bit with modern C++
- A modern version of Boost (until then, we shipped Boost 1.55): Boost 1.68 for 10.3, and Boost 1.70 for 10.4 today
- A large number of compiler stability, RTL methods, STL fixes, linker fixes, and more for the overall toolchain, including compatibility with the classic compiler, which means upgrading from the old classic to modern Clang is much easier than it used to be
- A number of popular open source libraries on GetIt. As well as making these easy to use, they’ve been great test cases to find RTL or other areas where we were not compatible with other toolchains. (We often use POSIX methods or approaches in our headers, even on Windows; also, many headers in common C++ libraries are written to assume specific compilers.)
This includes libsimdpp, Eigen, NemaTode, SDL 2, and others, and resolved many compatibility issues through that work, giving much greater capability for you to bring in external C++ libraries and source - Updated CMake support to improve features such as resource linking, as well as automatically handling configurations for other compilers for our toolchain – again increasing compatibility
- An entirely new debugger for Windows 64-bit, which both addressed debugging issues for Clang, a whole class of common issues debugging C++ in general. This makes debugging with Clang on par with debugging with classic for Win64.
In future, we plan to deliver:
- Linker fixes, including changes to debug format storage and linking, reducing memory load when linking debug builds. Under research is significantly larger changes to the linker.
- Visual Assist for C++Builder, adding refactorings and other tools to the IDE
- Updated STL, removing STL bugs
- CMake integration in the IDE
- Fixed code completion for C++
- Parallel compilation, decreasing the time it takes to build your project as a function of how many CPUs you have available – that is, 4x, 8x or even faster
Summary
Our C++Builder customers have asked us to focus on Windows and quality, and that’s what we’re doing. We are focusing on providing high-quality Windows development for you, especially with a focus on IDE productivity to match our existing UI productivity, as well as resolving important issues. This does mean that we will not have Android 64-bit or macOS support in the short-term (6-9 month) timeframe. However, we are working on – and have delivered – some important improvements to Windows already. Further items, like Visual Assist integration, are exciting for making C++Builder lead ahead of other IDE’s productivity. We understand that this prioritization may impact some of you negatively for which we apologize. We feel that focusing on quality and Windows is the right thing today to ensure we give you the product you want and need.
Once we are confident in the quality enhancements and feature set for Windows development we will reevaluate the landscape and take appropriate steps to address other platforms and features. Stay tuned for upcoming releases and stay in touch with other feedback or requests!
Note: These plans and roadmap represent our intentions as of this date, but our development plans and priorities are subject to change. Accordingly, we can’t offer any commitments or other forms of assurance that we’ll ultimately release any or all of the described products on the schedule or in the order described, or at all. These general indications of development schedules or “product roadmaps” should not be interpreted or construed as any form of a commitment, and our customers’ rights to upgrades, updates, enhancements and other maintenance releases will be set forth only in the applicable software license agreement.