2018 has been a very exciting year so far for Embarcadero. In our roadmap, you can find the key features that we’ve planned for calendar year 2018/2019. Before we get to the details of our updated roadmap, we wanted to recap what we’ve delivered so far:
Back in March, we introduced RAD Studio 10.2.3, also known as 10.2 Tokyo Release 3, of Delphi, C++Builder and RAD Studio. This was the third release of Tokyo, and included CMake Command Line Support for C++, Rename Refactoring, Mobile support in Delphi and C++Builder Pro, RAD Server enhancements, FireMonkey User Interface Templates and more.
Just last month, for the first time ever, we launched a full featured Community Edition for Delphi and C++Builder. Not only is it great for new developers, but our existing community can look forward to the next generation of knowledgeable Delphi developers picking up the torch and furthering their legacy with new Delphi projects. This is also true for C++Builder, since Community Edition provides a great entry point for C++ developers around the world to experience all that C++Builder has to offer, especially in terms of our multi-platform capabilities.
As you will see in our roadmap, we have a lot of exciting features planned for the next major version release, 10.3 (aka Carnival), with the themes for the release being Language and Platform Enhancements for Multi-Device and Windows Developers. The modernization of the IDE will also continues at full pace.
We wanted to take this opportunity to share with you more details on several key focus areas outlined in our updated roadmap.
Sarina focuses on FireMonkey, the component libraries’ UX and styles, the installation experience and demos and documentation
One of my focus areas since I started at Embarcadero back in 2011 has been FireMonkey. I’m very passionate about what developers can do with the FireMonkey framework to deliver on their multi-device application requirements. If you’ve been following my blog, you’ve seen that building stunning UIs with FMX is a theme carried through many of my posts. It’s an area where FireMonkey really shines, and combined with our FireUI designer, a very unique offering in the developer tools space.
The FireMonkey UI Templates that we released over the past several months for Delphi and C++Builder developers not only make it easy to get started building your own multi-platform applications, but they also showcase the flexibility that FireMonkey provides, and how to easily tweak UI themes to create a totally custom look and feel.
For several years, we’ve gotten customer requests for Z-order and native controls support on Android. We’ve heard your requests and are actively working on Android Z-Order support in 10.3. This will allow developers to use FireMonkey styled controls such as buttons, labels and checkboxes with natively rendered controls like the browser and map control on the same form without the native control covering the styled control. This also provides the foundation for supporting natively rendered UI controls, such as TEdit, on Android. In the coming weeks, we’ll be inviting customers current on Update Subscription to our 10.3 NDA beta, so those interested can get an early look at what’s been in the works. We also plan to expand our native Android controls support to more controls in future releases.
Z-order support for Android will work the same as it does for Windows and iOS today, allowing developers to mix both styled controls and controls rendered by the underlying OS on the same form without any overlap issues.
Another Android related feature we’re working on is upgrading our Android API level support in RAD Studio to support level 26 (Android 8.0). This change requires significant work, and is not possible in a 10.2 update. This support is coming in 10.3. Although the usual beta restrictions do not allow for building and deploying production apps, active update subscription customers who join our 10.3 beta will find a special EULA provision allowing them to deploy (production) Android apps to the Google Play Store.
Platform support is key with a multi-platform framework like FireMonkey. We know that Android 64-bit support will be mandatory by the summer of 2019, and are working on plans to ensure our customers can meet this requirement next summer.
One roadmap change you may notice compared to the September 2017 roadmap is that we removed macOS 64-bit platform support from the initial 10.3 release.
This doesn’t mean that we don’t think macOS 64-bit is important. We removed it from the 10.3 release to focus on providing more quality and stability for the other key features that are in flight. With that said, our intent is to provide support for macOS 64-bit, including support for targeting the iOS 11 (and iOS 12) simulators, in a follow-on 10.3.x release. We know that developers looking to target the macOS App Store or leverage 64-bit APIs require macOS 64-bit support.
We have a number of customers today who distribute their existing 32-bit applications through their own web store and are currently not impacted by this Apple requirement.
In terms of looking ahead, a couple of months ago Apple announced that it was deprecating support of OpenGL in favor of Metal 2, Apple's new GPU library. While OpenGL will continue to be supported in the next versions of macOS and iOS, we are reviewing what will be required to support Metal later next year.
Marco focuses on the Delphi language and RTL, the VCL library and Windows integration, all things database and Web oriented, including RAD Server
While over the last few years RAD Studio and Delphi have expanded their focus on multi-device and mobile development with a single source code and compiled applications, the product remains rooted on Windows and in recent years we have made sure to keep a significant focus on VCL, the best component framework for Windows client applications. We have been adding new components and controls in each release.
Today VCL offers great support for Win32 API, but also integration to the newer WinRT API of Windows 10. We have new controls with modern UI, styling, and offer a great migration path to a modern UX while preserving most of your existing source code. Moreover, the IDE integrates the Desktop Bridge to build UWP applications you can distribute via the Windows Store.
As you can see in the roadmap, the plan is to continue and increase our investment in this area, specifically around store applications and the ability to check the application status in the store (checking if the customer has paid for the app, if it is a trial, and managing in-app purchases and subscriptions).
We are also going to expand our Win32 API coverage, given Microsoft has added important subsystems to it, and focus on continuous improvement for our support for High-DPI and 4K monitors on Windows. In this regard, we are going to introduce a new image list control that can manage images at multiple resolutions, similarly to what we do in FireMonkey. This will allow the application to avoid relying on image scaling (which often negatively affects image quality) but rather pick the best image for the current screen resolution. In terms of High-DPI support, we are working on the new “Per-Monitor V2” mode Windows 10 offers and plan to focus on resolving a large number of issues the current multi-monitor support has.
Beside the Windows 10 focus (which is for both Delphi and C++Builder), there are many other features we are working on for the Delphi personality. We have gone back to the drawing board for the language, and are planning on releasing the new features in phases -- as stability at the compiler level is of critical importance. We found out that good quality support for nullable types (planned, but deferred) requires changes in other areas of the language. The first we’ll be tackling is custom managed records, that is the ability to define a default parameterless constructor, a destructor and a copy operator for any record type. This adds a lot of power to records, a very nice complementary feature to classes and objects.
In terms of the Run-Time Library (RTL), the focus will be on performance and quality, more than additional features. From generic lists to large memory data structures, from JSON processing to the HTTP client library, we have found large room of improvements and are sure every customer will be pleased, because whether you are building a client application or a server one, whether you are using mobile or desktop platforms, performance gains are always nice to have.
The RTL performance enhancement also helps RAD Server. After 10.2.3, we released a performance update for our REST API engine, mostly focused on internal elements and better memory management in case of heavy multi-threading. What we couldn’t do in an update was improve the performance of your RAD Server modules, something we’ll achieve in the next release by making JSON processing, string processing, the TStringBuilder class and more core classes faster. Also, it is important with JSON and HTTP services to better support all standards and protocols, including borderline scenarios that other HTTP servers or clients expect.
We have much more than that for RAD Server, though. The next release will see a major overhaul of the logic RAD Server uses to map an incoming HTTP request to an internal resource (that is, a class offering methods to handle the HTTP method calls). Until now, the mapping has been based only on the URL and it has been fairly rigid. Now we plan on adding the ability to consider other HTTP request parameters, like the Content Type, Accepts, file extensions, and more to allow for more sophisticated mapping. For example, the same URL can return a JSON data structure, an image, or a PDF depending on the invocation context. Also, while today you often have to repeat the same code to handle requests over and over, you’ll be able to delegate the actual implementation of a resource request to a separate component, sharing most of the same code for multiple requests and reducing boilerplate code.
It is a really new version of RAD Server that’s coming along, and coupling it with the licensing changes (deployment licenses are now included with higher end SKUs) we are certain that this REST API engine will see additional interest and focus.
David focuses on the C++ language, the debugger, and IDE and user experience
In the past couple of releases of RAD Studio, we’ve introduced some great tools for C++ developers. First, rename refactoring: our first C++ refactoring. It’s one of the most common refactorings and significantly speed up and makes more reliable a common task. Second, we introduced command-line CMake support for C++Builder. This is the first of a couple of CMake-focused steps we have planned, and explicitly supports using ninja for fast builds. You can target Windows, iOS, and Android, including deploying to the device, all from CMake.
We have significant plans for C++ over the next year.
We will introduce our upgraded C++17-capable compiler. This will be for a single platform (Win32) initially, then rolled out to others since we want to support the same level on all platforms. When macOS64 support arrives, it will use this new version too. We will continue to update our compiler toolchain and keep it close to a recent version of Clang, meaning our users will get the benefits of both the optimizations and language support of Clang and the language extensions and power our environment provides.
Paired with this will be a new C++17 version of the Dinkumware STL, and performance enhancements.
We also plan a followup to the CMake support introduced in 10.2.2. This support was command-line only. Ultimately, we plan for further integration, aiming to make it very easy to import a CMake project into the IDE, and to build. Paired with this is an ongoing project to ensure common C++ libraries work with C++Builder (not hard, we have excellent language compatibility, and increasing this is constant and ongoing) and add them into GetIt, our package manager. Ultimately, any C++ user - used to our ecosystem or not - should find it very easy to use any app or library they choose with C++Builder. And our users should find it easy to bring in any C++ library into your apps.
Finally, some readers may have seen the very recent announcement that Idera acquired Whole Tomato. Whole Tomato make Visual Assist, a Visual Studio extension which is arguably the best C++ tooling addon for any IDE, period. It has excellent code insight, refactorings, and other tools. Visual Assist users can rely on its continued development for Visual Studio - it is an excellent standalone tool we want to see grow and thrive - and we also plan to integrate some key parts into C++Builder.
The RAD Studio IDE is used daily by many tens of thousands of Delphi and C++Builder users. Recently, in 10.2.2, we introduced a new dark theme for the IDE and code editor - one of our most popular additions ever, greeted with enthusiasm by large number of our users.
In 10.3.x, we plan a number of IDE improvements, both to the UX (user experience) and functionality.
Over the past few years, the IDE has had many extensions and changes. But, the way these have been presented in the UI has not always been polished. In 10.3, we plan some careful UX improvements that should make the IDE significantly nicer to look at and more pleasant to use for hours on end. Not all of these are just UI polish: many dialogs have improvements and reorganisation, and the end result is something significantly functionally better while also looking a lot more pleasant. We can’t wait to show you.
We are also integrating a number of items from Andreas Hausladen’s IDE Fix Pack, which we licensed earlier this year.
Longer term, we have some other improvements lined up. We have spent quite some time internally examining code completion and other code tooling, and have some significant improvements planned for both Delphi and C++.
Finally, we are also paying a lot of attention to better high DPI support in the IDE. Marco wrote above about significant improvements for high DPI in the VCL, and the RAD Studio IDE is mostly written in Delphi and C++Builder and most UI is built using the VCL. We hope to leverage the VCL improvements within the IDE too, though this will be done carefully and likely arrive after a release gives it to you our users in the VCL itself.
We don’t typically write much about the debugger in blog posts. The debugger is one of the core pillars of a development environment, but we tend to write about the compilers - after all, they’re where you see the language enhancements, the performance, etc. The debugger just does its work for you every day, silently, and is quietly updated as we also work on the flashier side of the toolchain.
However, we have some great improvements planned. On mobile platforms, we use a mix of LLDB and GDB depending on the platform. LLDB is the way forward, and we will be working on our Delphi front-end (language understanding) integration before making use of LLDB on more platforms. The end result as seen in the IDE will be a faster and more powerful debugger, which also understands and can interpret more Delphi statements. Naturally, C++ benefits from this too.
We have some great improvements planned for you: C++17, further CMake support, debugger improvements, language tooling, new FireMonkey features and new platform support (macOS 64-bit and Android 64-bit), Android native controls, HighDPI improvements, RAD Server enhancements, Delphi language features, great UX and look-and-feel improvements to the IDE.
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.
It looks like we now have the "follow-on" 10.3 release discussed above. Yet no 64-bit OS X. If we are not going to ever have that, please tell us, so at least we can start finding another solution before it becomes more of a crisis than it already is.