RonaldK

Very likely that it has the same code quality as the Linux compiler: https://quality.embarcadero.com/browse/RSP-17724

Is there any country in the world, where you can change the rules of using, after you have bought it?

Does your project use visual inheritance? (TForm/TDatamodule inherited from other?)

Android 64-Bit support is now scheduled to 10.4 and dated to "late 2019" . Does this means: the Delphi Android development will end at 1. August and maybe continue in late 2019?

Here an active FGX discussion: http://fire-monkey.ru/topic/5600-fgx-native-первое-опубликованное-приложение-в-google-play-market/?page=2&tab=comments#comment-35653

One reason could have been the new RAD server.

The lonely wish that Delphi once again becomes a bright light in the forefront, not just chasing after the story. This long running behind makes more and more the feeling that at some point the compiler will not come anymore and the part for Android, iOS and macOS will end at some point. I am of the opinion that if you go the way of the different platforms, then with full force ... or not at all. This half-dead is not a business model.

It's re-scheduled to 10.3.x. I would assume it's included in the next Service Pack before the release of the 10.4.

It's on the roadmap for 10.4.x (Mid 2019) https://community.idera.com/developer-tools/b/blog/posts/rad-studio-august-2018-roadmap But you're right. It's hard to believe that Emba will deliver on time.

There is another nice "Enterprise feature" in the Linux compiler (still open): Linux x64 compiler produce very bloated code. https://quality.embarcadero.com/browse/RSP-17724

I think you know that VCL is very closely linked to WinAPI. The special strength of VCL is this depth. CrossVCL is available and you can use it. Eugene is fast and has very good support. Mobile is on the evaluation roadmap. What should change through Emba? Deploying a little WINE with each application has strength and weakness. It's one way, but not the solution for all.

... or do you mean Eugene (the father of FMX)? I dont think that an open source Compiler or another Compiler makes it better. The current weakness of Delphi is the lack of a good development team behind Delphi. In my view, the step away from the own development team was a fatal mistake.

Well, back to the title of this thread. Isn't LLVM open source and thus problems will be fixed better and faster?

Shared Memory: https://stackoverflow.com/questions/5646202/sharing-data-array-between-two-applications-in-delphi

If Apple keep their update frequency, the non 32Bit macOS will touch the ground in Sept. this year. The 64Bit macOS compiler is shifted to version 10.3.x. Rio was released at 21.Nov. 2018. It took 3 month to release service pack 1 for "only" some bug fixes. If you look back to the other deadlines for Delphi: Like iOS 64 Bit, Android API level, ... It's hard to believe that the new macOS compiler will be available in time.

Yes, but you can run existing/old 32 bit apps. I fear that you cant do this on the next macOS. Any company with 32 bit only, will get out of business on this platform.

The roadmaps before planned this for Tokyo, then Rio, then Rio service pack 1. Now it's officially 10.3.x, not directly 10.3.2. Just Matthias mention this. It's hard to believe that it will be available in time and Firemonkey will fully work with the new compiler.

Is there any time frame for 10.3.2? When Apple keep there release date cycle of macOS, we can except, that the new macOS without 32Bit support will be in Sept. this year.

What about 64Bit compiler for macOS? Wasn't that scheduled for Rio Service Pack 1?

If the procedures works sequential, set flags while entering and leaving the procedure and ask the MemoryManager from a TThread how many memory is currently used.

Are you using the new Skins/Themes in the IDE? It's better when you disable it?