If you compile your app for AVX2 and it runs on Windows ARM under Prism emulation, is it faster or slower than compiling for SSE2-4.x?

I assumed it would be roughly the same — maybe slightly slower due to emulation overhead, but AVX2's wider operations would compensate. The headline gives it away: I was wrong.

This post explains how I found out, what I measured and how, the benchmark results, and why.

Curiosity

A few weeks ago, in a Hacker News thread on WoW (the game) emulated performance on Windows ARM, I wondered:

I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) ... I’ve found very little info online about this.

Well, I nerdsniped myself, because those math benchmarks are now complete and so we have the perfect framework for testing AVX2+FMA emulation performance overhead on ARM Windows. I have no technical reason to do so: if you use our compiler we encourage that if you want to run your app on Windows ARM to just compile your app for Windows ARM. It's simply: I want to know.

Thus I spent much of Sunday crunching our data and figuring it out.

ARM emulation of x86

You can skip this bit if you know about Windows ARM's emulation and what various Intel instruction sets like SSE through AVX2 are: go forward to Benchmarks.

Windows 11 lets you run both 32-bit and 64-bit Intel apps on ARM. It does this via emulation. Essentially, x86/64 code is translated on the fly into ARM. Windows 10 supported emulating 32-bit Intel, and by 2021 Windows 11 introduced emulating 64-bit apps.

In 2024 Windows 11 was updated with a new emulation layer, Prism. The main user-facing change seems to have been performance: 'Microsoft told Ars Technica that Prism is as fast as Apple’s Rosetta 2' and:

Most x86 apps now run without issues, and in many cases don't even feel like they're being emulated. These days, the majority of users won't notice a difference between using an Intel PC or a Snapdragon one
– Windows Central

Is emulation complete / entire?

x86 and x86_64 have not always remained the same. Over time they add more functionality, which is exposed as instruction sets. These are the base instructions that an app can be compiled to use and are often focused around doing things faster. For example, the x87 floating point math instruction set still exists (it was introduced in the 1980s!) but was succeeded a quarter century ago by SSE2, introduced with the Pentium 4. SSE2 lets you perform floating point math operations much faster. A few years later the SSE 4.x series also improved largely integer-based operations. This is a very handwavy summary: in fact, these are part of a wide series of instructions intended to process data fast, where possible in wider configurations (more data at a time per clock tick) than older instructions, each new improvement introduced one by one over many years. This does not even begin to address the other supplementary extensions: ones for bit manipulation, specific math patterns like multiply-add, and more.

This is important to understand because software does not all use the same sets of instructions. Figuring out baseline standards of which sets it was reasonable for an app to use was a mess, and Linux folk found it annoying enough that, working together with Intel and AMD, Red Hat and SUSE defined standardised versions to allow known safe targets for compiling for specific collections of instruction sets. Thanks to them, x86_64 now has four main versions that modern compilers target, which define generations of new instructions. x64 version 1 is that same old year-2000-ish era; x64 version 2 circa 2008 level, v3 circa 2013 level, and v4 circa 2017 level.

It takes time for instructions to become mainstream: if you are building software for 64bit Intel Windows in general, you likely won't build solely for the v4 2017 level because you may have users who have older computers, or ones newer than 2017 but which had less capable chips that didn't feature all the latest instruction sets. AVX-512 (v4) is a wonderful instruction set for very wide vectorised behaviour but still many computers in practical use today don't have it.

And similarly to how actual hardware may or may not support specific instruction sets, Windows x86 emulation also supported only a subset.

That subset was approximately x64 version 2 (ie with SSE2 and 4.x) and only recently have newer versions of Windows have supported v3: to handwave, AVX2 and FMA. This is new, exciting, and to my knowledge, largely unknown.

We are comparing performance using x86-64-2 level vs v3 level running emulated on ARM.

That brings us to that Hacker News comment and today. What's the emulation performance for those newer instructions?

Our benchmarks

At RemObjects we make a multi-language (6 of them!) compiler toolchain that targets native CPUs via LLVM (as well as .NET, JVM, and WASM backends.) We recently integrated a new vectorised math library, which gave us the perfect benchmark framework for testing this.

We already supported ARM Windows, that is not new, but our cross-platform RTL had our own implementations of common math methods on the 'Island' (native) platform (the normal set: sin/pow/exp/floor and so forth.) These were correct in that they followed known algorithms, but we felt there was room for performance optimisation. We settled on integrating a third party open source math library. At the time I wrote the above HN comment, this integration was still being tested and tweaked; we even changed some of LLVM's internal passes.

Today, we have this new math implemented for macOS ARM (and x64), and Windows i386, x86_64, and ARM64. Our Windows 32-bit (i386) math supports SSE2/4.x, but the math library for Windows x64 supports using either v2 (SSE2-4.x) or v3 (AVX2-targeted) level depending on the x64 revision you target in the compiler options. (You can actually tell Elements to target v1 through v4, but our new math library kicks in at v2, with more performance with v3, and we have not enabled anything extra in math for v4; you can certainly compile allowing AVX-512 etc if you wish for your code in general though.)

As part of checking our new math code as (a) correct and (b) improved performance, we have concrete data running 21 different math operations on both real x64 hardware, and Windows ARM on Parallels on a Mac M2.

Because these are different machines we cannot compare the wall clock time, but we can compare the relative time, using the SSE2-4.x level as a basis: what is the relative performance difference of using AVX2(+FMA) on Intel vs on ARM? Normalising against the earlier, well-emulated instruction set means that the difference between emulated and real hardware gives us the answer of how well AVX2 emulation performs.

We can also use ARM64 on ARM, and AVX2 on x64, as a handwavy comparison for if you need ARM: an indication if emulation provides 'good enough' performance or if there's real value in compiling for ARM.

Thus:

• Using SSE2-4.x as a baseline for performance on both ARM and x64 (ie, scaled this to 1), what is the relative performance of AVX2 when emulated on ARM vs running on x64, and thus what overhead does ARM emulation of AVX2 provide compared to native?
• Using two kinda similar-gen machines, and hand-waving that it's nothing more accurate than that, how well does ARM-native vs x64-emulated vs x64-native perform? Do you need to compile for ARM, or can you get away with letting your apps run under Windows emulation?

Details

Performance tests instruct LLVM to build targeting the specific instruction set; are heavily vectorised; and our AVX2 level includes FMA (fused multiply-add.) We use only 256-bit wide AVX2, not the 128-bit wide instructions. Specifics are:

• Normalised to 1.0: CPU x86-64-v2 (referred to as 'SSE2-4.x' above, because those are the primary instructions math uses), feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2
• AVX2+FMA comparison: x86-64-v3, feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+avx,+avx2,+fma,+bmi,+bmi2,+f16c,+lzcnt,+movbe,+xsave
• ARM64: 'generic' ARM64 CPU, no specific feature set

Each math operation is run on a randomly initialised array of 64-bit doubles as input, in a loop (ie intended to be vectorised), 10 million times. The output is retained and 'used' in order to prevent the loop being optimised away. In IR, we verified the loop exists, is vectorised, and appears to look as expected. Numbers reported are typical timing runs, with no observable difference in cold vs warm runs. Timing is of course only around the tight loop itself, not the prolog or epilog setting the data up or 'using' the results.

All the 21 results are then scaled as a ratio vs baseline instruction set, x64 v2, and the geometric mean calculated to give a single representative number. This means that we can tell how much faster AVX2-level code is vs SSE2-4.x level, both on actual Intel hardware, and under ARM emulation.

Test machines

x64: Tiger Lake i7 (2.80 GHz), mobile-class CPU, circa 2021, on Windows 11 Pro 25H2.

ARM: Apple M2, circa 2022, macOS Tahoe 26.1 with the ARM version of the same version of Windows 11 Pro (25H2), running on Parallels 26.

x86_64 AVX2 emulation on ARM: Results

The following chart scales x64 v2 to 1.0 (grey baseline) and x64 v3 i(ie AVX2+FMA) is relative to that (Intel in green, ARM emulation in blue), that relative number calculated as the geometric mean of the result ratios of x64 v3 vs v2 for 21 common math functions run on 64-bit doubles per the above detailed description.

Normalised to 1.0, larger is better (faster).

As expected, using AVX2 on native Intel is significantly faster: 2.7 times faster.

But when the same code is run on ARM, the AVX2 implementations are notably slower than SSE2-4.x. They are almost exactly 2/3 as performant as emulating the older instruction set.

This means if your app uses x64 v3 with AVX2, and runs on emulated ARM on Windows, following this data, it will run slower than if you restrict it to the x64 v2 compilation level.

Why?

At the time I wrote the HN comment that started this, I had noticed that we didn't see faster performance using the AVX2 versions of our math function on ARM; what I had not yet measured was such a significant slowness.

Some possible reasons are:

• ARM has 128-bit wide NEON operations. AVX2 is using 256-bit wide operations (our code is not using 128-bit widths). This means the emulation code has to handle running two halves; it would be very close to impossible to make that equal performance.
  This is in my estimation the most likely single reason.
• The Prism AVX2 emulation code is new, compared to that emulating older instruction sets, and may not yet be fully optimized.
• It may optimise for heavily for 32-bit singles, not 64-bit doubles. Our math library focuses on double-precision.
• The ARM emulation documentation notes, 'Prism is optimized and tuned specifically for Qualcomm Snapdragon processors. Some performance features within Prism require hardware features only available in the Snapdragon X series...'
  These tests were on an Apple M2. While I'm sure Microsoft wants to support, or even prioritise, non-Apple hardware, in my view, Windows on Mac (via Parallels) is worth them supporting. But perhaps they don't support it well, yet.
• The emulation code may look for specific patterns that our code does not meet: perhaps, and this is entirely speculation, known (eg) VC++ Intel output, such as common RTL methods, may map to specific ARM64 patterns in the emulator. We are using LLVM, and (probably) rarer math implementations, therefore, less common sequences of operations.
  I cannot speak to how the emulator is implemented, and if this is even likely. It's a guess.
• Our x64 v3 performance seems, at this stage of testing, to be faster than Visual C++'s. (By a significant factor: in this chart, where our AVX2 code at our maximum FP precision came in at 2.7x the baseline, a VC++ 2022 version of the same benchmark compiled in x64 release mode, default FP accuracy, no further changes to default settings came in at 1.3x running on native Intel hardware. Yes, that is a 2x difference, and we attribute this to the VC runtime likely lacking AVX2-optimised math routines; their SSE2 math is slightly faster than ours, gosh dangnum darn it.)
  Therefore, for AVX2, using our compiler may be unfair compared to using other tools.

Meaning in practice

It is rare to have tight loops of operations: data processing, scientific and engineering software, etc., are the most likely. Even games may push much to the GPU. Therefore, the impact you see on your AVX2 app is unlikely to represent your app running at 2/3 the speed of your AVX2-4.x app. Only parts of it will.

If you have apps that do real number-crunching, whether that's native or something like Python, you should have the ARM version installed. (You likely have the ARM64 Python wheels installed anyway. But check.)

Although this checked floating point math, it is likely that it also applies to integer instruction set emulation too.

Therefore, it's likely worth treating Windows' ARM emulation of AVX2-level support as for support and compatibility, not for equal performance. To get performance, you'll need to compile as ARM.

If performance is key: Yes, it is absolutely key to build your app as ARM, not to rely on Windows ARM emulation.

This weeks Elememts build brings three new and exciting language features to the Oxygene language – and they all center around a single new keyword: field.

Field-Backed Properties

Things started off by bringing one of the new C# 14 features to Oxygene: Field-backed Properties.

Field-backed properties solve the conundrum where, as soon as you want a property to do anything more complex than just store and retrieve a value straight-up, you need to manually declare a field to store its value in by hand. With the new syntax, you can let the compiler handle that part for you, but still provide custom getter or setter code. And you can use the new field keyword (same in C# and Oxygene) to access the "backing field" from inside that code.

In C#:

private string _msg;
public string Message
{
    get { return _msg; }
    set 
    { 
        _msg = value ?? throw new ArgumentNullException(nameof(value)); 
    }
}

Now simply becomes

public string Message
{
    get;
    set 
    {
        field = value ?? throw new ArgumentNullException(nameof(value));
    }
}

No manual getter code; no private field declaration, no msg cluttering up the class's scope. And, most importantly, no chance to accidentally access _msg directly from other pasts of the class.

The same concept applies to Oxygene:

property Message: String write begin
  field := coalesce(value, raise new ArgumentException(nameOf(value));
end;

Any property that uses the field keyword in its read or write code becomes a field-backed property.

Also, any field-backed property will be read/write, and get its default read or write Implementation implied, if not specified, like in the example above. Why can we assume that's the intention? Because a read-only or write-only field-backed property would be pointless – who else would read (or write) its value, otherwise?

Field-backed Properties for Oxygene are documented in full, here.

Fields

Now that we have a field keyword in Oxygene anyways, this opened up the door for additional opportunities.

I have long been a proponent of proper naming, because the way we call things shapes the way we think about them. It's one of the takeaways I got from the excellent book Object Thinking, and one of the reasons why – as far back as version 1.0, before it was even called Oxygene – I pushed for the introduction of the method keyword to the language. Because Classes do not provide functions and procedures (and there are additional arguments on why Pascal's terminology re: functions and procedures is bad – but that is for another day), they provide methods. So it feels only right to use the method keyword to declare them.

Another thing classes (and records) contain is fields. In fact, a class without fields is not much of a class. Even though fields are (usually) variable, as in mutable, they are not variables! Yet, what (optional, alas) keyword did we use to declare fields? var.

No more! As of today, the field keyword can be used inside a class or record declaration to declare one or more fields, replacing var as the preferred and suggested option.

Of course, var will continue to work, for backwards compatibility; just as function and procedure are still there to this day, if you prefer. But field is the way to go.

Field type members in Oxygene are documented in full, here.

Local Fields

But we did not stop there.

The third and probably coolest application of the field keyword is inside code, i.e. in the body of your methods.

Of course, the var keyword sticks around for declaring variables inside your code, whether in a var section at the top of your method, or – the preferred Oxygene way since 2004 – inline with the var statement.

This is not changing. But we've introduced a new field statement that follows the same semantics, but will declare a field on class-level – but scoped to be accessible only in the current method or scope. The field will be initialized the first time the line declaring it is hit, and after that, its value will persist across all future calls to the same method (on the same instance).

Essentially, a local field is like declaring a regular private (all fields should be private) field, but limiting access to it to a single method or scope within a method.

• Local fields can be instance (the default) or static for the class when using class field or the static modifier. (same as for regular, global fields).
• Local fields in a static method or a static class will, of course, always be static.
• Local fields in an instance constructor need to be static (because what would be the point, otherwise) and are not supported in a (static) class constructor.

For example, this Log method keeps internal track of indentation level, based on what strings it got sent to writeLn:

    method Log(aMessage: String);
    begin
      field fIndent := 0;
      if aMessage.StartsWith("<-") then
        dec(fIndent, 2);
      writeLn("".PadEnd(fIndent, ' ')+aMessage);
      if aMessage.StartsWith("->") then
        inc(fIndent, 2);
    end;

Local Fields for Oxygene are documented in full, here.

Get All Your Fields Now!

All of these (and field-backed properties in RemObjects C#, of course) are available in Elements .3057, out on the Preview channel today. We expect next week's .3059 to bring them ot the Stable channel and the free trial.

Read more about Elements here. New stuff is being added to Elements every week.

If you're a Delphi developer, you might not be used to thinking of Object Pascal as a language that produces very fast code. Not in the way people talk about C++ or Rust, anyway; those languages are famous for performance.

We think that should change. And we've done something about it.

Depending on your platform and what your code does, recompiling your Object Pascal with Oxygene instead of dcc32/dcc64 could now give you 4x to 11x faster math performance.

In our benchmarks, we're on par with Visual C++, and at the AVX2 level, faster than Visual C++ – yes, in Pascal. Let me explain what that means and how it works.

How we got here

Back in November we upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. Island, our LLVM native code compiler backend, uses the IslandRTL for many functions including math. We don't reuse the system C RTL, because it can have varying implementations on every platform. We provide our own. Our math functions had correct implementations, of course, but we realised modern instruction sets offered an opportunity we hadn't yet taken.

It also became apparent that LLVM wasn’t being fully leveraged. While standard optimisation passes were in place, the possibility of going further was worth exploring.

So we set about investigating. What do other toolchains do? What does Visual C++ do? What does Rust do? What do other LLVM-based toolchains do, which are best practices we can also make use of?

What Is Island/Delphi?

Elements is our compiler with six language frontends: Oxygene (Object Pascal), C#, Swift, Go, Java, and VB. One compiler, multiple input languages, all of which can interoperate seamlessly; our own IDE is written using multiple languages in the same codebase, inheriting from and calling methods written in different languages with no bridging layer. It's a bit like Delphi & C++Builder, but six languages not two, and fully multidirectional across any language to any other.

Elements can target multiple platforms: .NET, JVM, WebAssembly, and native CPUs. The native CPU target is what we call 'Island', and it uses LLVM, the same compiler infrastructure as behind Clang, Rust, and Swift.

Island/Delphi is a mode where you can import a Delphi project and compile it with Oxygene, linking to Delphi packages. This includes using the VCL; the Water IDE imports the VCL and other standard Delphi packages, though third-party components need to be imported manually (a straightforward File > Import step, which you can also do in the Fire IDE on macOS, or within Visual Studio.)

Island/Delphi isn't at 100% Delphi compatibility yet: think of it as a v0.9. But we think it's amazing: for many projects you can import and rebuild. Your Object Pascal still works, your VCL forms still work; the difference is what happens at compile time, because you get the benefits of a modern LLVM-based toolchain, including a wide variety of modern language features that Object Pascal developers have asked for.

What We Improved Lately

Two things that work together:

1. A fast, vectorised math library

We looked at what other toolchains did to get faster math than the default system libraries. Rust developers who want vectorised math can use SLEEF, so we integrated it.

SLEEF is an open-source math library designed for SIMD operations, providing vectorised implementations of sin, cos, exp, log, and the rest.

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

2. CPU target selection

You can now tell the compiler which CPU level to target:

• Win32: SSE2 (always)
• Win64: x86-64-v1 through v4 (default to v2; and we recommend v3 if your users have ~2013+ hardware)
• ARM64: Native Windows ARM compilation, which Delphi doesn't support yet

When you target a higher instruction set level, the math library uses more capable implementations. AVX2 for v3, for example, processes 256 bits of data per instruction instead of 128.

You can read more details on our general Elements blog post, since this benefits all six Elements languages.

The Performance Difference

We benchmarked 21 common math functions (sin, cos, exp, pow, log, sqrt, and so on) running each 10 million times on 64-bit doubles. Here's what we found comparing to Delphi 13.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Read more about the methodology here.

The reference compiler is normalized to 1.0. All reported results are expressed as multipliers relative to this baseline (for example, '4x faster' means four times the performance of the normalized compiler).

Win32

Oxygene Win32 (SSE2 default): 4.2x faster than Delphi Win32

Win64

• Oxygene Win64 v2 (default): 2.3x faster than Delphi Win64
• Oxygene Win64 v3 (AVX2): 5.5x faster than Delphi Win64
• Visual C++ Win64 AVX2: 2.7x faster than Delphi Win64

At our default settings we're roughly on par with Visual C++. With AVX2 targeting x86-64-v3, Oxygene is noticeably faster than VC++ also targeting AVX2.

Windows ARM

Delphi doesn't compile for Windows ARM, yet. If you have a Delphi Win32 or Win64 app running on Windows ARM, it's using Microsoft's Prism emulator to translate x86 instructions on the fly.

Oxygene ARM64 native: 11x faster than Delphi Win32 under emulation

This is not only the difference in using a highly optimising compiler, but it is also the difference between running translated code and running native ARM code.

Beyond Performance

Performance is what this post is about, but it's not the only reason to consider Oxygene.

Oxygene brings modern language features to Object Pascal: tuples, async/await, nullable types, soft interfaces, and more. You can use C# alongside Pascal in the same project. You can target platforms Delphi doesn't support: Windows ARM64, WebAssembly, Linux ARM, tvOS or watchOS...

If you've been looking for a way to modernise your Pascal development, a toolchain you can invest in that keeps up with current hardware and language design, Elements is worth evaluating.

The Practical Side

These are best-case numbers, i.e. tight loops of floating-point operations. Your real application probably doesn't consist entirely of sin() calls. But if you have code that does data processing, scientific calculations, signal processing, or anything else numerically intensive, you'll see real improvements.

The difference between "this calculation takes 10 seconds" and "this calculation takes 2 seconds" is highly noticeable.

In addition, instruction set supports means this applies to all code. Not just math code. Your string processing, or anything else, will be built with the same optimizing compiler that uses fast instructions and heavy optimization – just like C++, Rust, or Swift.

Try It Yourself

If you're curious:

1. Download Elements (there's a 30-day free trial)
2. Import your Delphi project: File > Import (Water on Windows, Fire on macOS, plus VS); the very first time, it will also import the VCL etc packages for you. At 4 seconds each for over a hundred, possibly for multiple bitnesses, it takes a few minutes. After this once-off step they'll be available right away for every other Delphi project you import in future.
3. Build with Oxygene targeting Island/Delphi (your imported project will be configured for this already)
4. Compare

Your VCL code works, your Object Pascal works; the difference is what happens at compile time.

This – modern CPU support, fast code – is the kind of work we do in Elements. If you try it, I think you'll find what it shows.

In our view, this work strongly supports Delphi by providing what it does not have inbuilt, whether that's platforms, compiler behaviour like optimizations or fast math, or language features. A compiler is just a component of your development environment, and since its beginning thirty years ago, Delphi has been all about replacing inbuilt components with third party ones: doing so is intrinsic to Delphi development and a big part of the Delphi ecosystem. Our suggestion you use Elements to compile means we directly recommend and support using the VCL and other Embarcadero technologies.

We are grateful to Embarcadero for their support as a tech partner ❤️, and hope our value for the Delphi ecosystem really shines 🌟.

We recently upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. We had our own implementations of sin, cos, exp, and the rest, which were correct, but modern instruction sets offered an opportunity we hadn't yet taken.

We looked at what other toolchains did to get better math performance than the system libm (libmath, ie, inbuilt C RTL.) Our toolchain does not use the system C runtime in general, so we don't delegate to it, even for math.

Among other things, when researching, we found that Rust developers who want vectorised math or to not rely on the system libm can use SLEEF. It's open source, accurate, fast, and supports multiple instruction set levels.

We prototyped it. Got some exciting numbers. We integrated it.

There are not many math libraries of this calibre. There are others: GPL-ed, or commercial, or Intel-only, or ARM-only. SLEEF is absolutely amazing.

The results were significant enough that we wanted to share what we did and why it works.

What We Changed

Two things, which complement each other:

1. A new math library

SLEEF provides vectorised implementations of common math functions (sin, cos, tan, exp, log, pow, sqrt, and so on.)

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

Taking advantage of this in general requires an optimising compiler that uses newer instruction sets – see the next section ;)

Sleef supports both Intel and ARM, and has both scalar (ie normal one by one) and vector (several at a time) versions of math operations. Its scalar functions can dispatch, that is, check the CPU and call a different internal implementation at runtime depending on what your CPU supports.

Its vectorised methods do not: you need to call and link the right ones depending on the target CPU.

Rather than building the math library multiple times for a target (like x64 with multiple levels of instruction sets) instead we use LLVM's support for vectorised math libraries, plus instruction sets, so that a version of the library - IslandMath.lib - contains all the various variants, and at compile-time/link-time our compiler instructs which set to use. This requires really tight integration with LLVM, including:

• LLVM's target CPU, and CPU feature set (supported instructions LLVM is allowed to use)
• LLVM intrinsics (because an intrinsic for trunc, say, needs to be able to be converted to this method call – including taking the intrinsic and using it in vectorised form)
• and LLVM's inbuilt awareness of math libraries: large tables of operations, widths, instruction sets, and methods to link to.

Thus we have a chain. In reverse it is: LLVM (target CPU and feature set, intrinsic, math library support) ⬅️ Elements compiler (specifies target CPU, specifies microarchitecture) ⬅️ EBuild build system (handles projects, passes the compiler its settings, handles automatic references to the math library.) Quite a bit to implement.

For your apps, IslandMath is an implicit reference. Our build system, EBuild, links it automatically. It is visible in the IDE: you always see what is being referenced and linked to in the Water or Fire IDEs, even if it's automatically managed.

2. CPU target selection

You can now tell Elements which CPU level to target:

• 32-bit Windows: Pentium 4
• 64-bit Windows: Choose x86-64-v1 through v4 (corresponding roughly to ~2000, ~2008, ~2013, ~2017 eras)
• ARM64: We handle this internally. Apple Silicon gets M1-specific targeting; Windows/Linux ARM gets generic ARM64.

Our default is x86-64-v2 for 64-bit, and 32-bit uses SSE2: conservative choices that work on any reasonably modern hardware.

These features enhance each other. When you target x86-64-v2, our math library uses SSE2+SSE4.1 implementations. When you target x86-64-v3, it uses AVX2+FMA implementations, which means 256-bit wide operations instead of 128-bit. More data processed per instruction means faster execution.

We also tuned our LLVM passes for better vectorisation. By customising passes, as well as customising how passes worked, we were able to ensure more code patterns that could be vectorised actually were vectorised. We believe this is similar to how the Intel C/C++ compiler works, which was famous for performance and we understand – don't quote us – made a similar set of analyses. It certainly worked for us.

The Results

We benchmarked 21 math functions (the standard C RTL set: sin, cos, exp, log, pow, sqrt, etc.), each running 10 million iterations on arrays of 64-bit doubles. We compared Elements to Visual C++ 2022 and  Delphi 13, running on the same hardware.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM, via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Where possible, i.e. for Elements, we looked at the IR to verify the code was behaving as we expected. We report the geometric mean of per-function speedups across each toolchain, which gives a single representative number that isn't skewed by outliers.

Win32

What we haven't added here is Visual C++'s SSE2 support (see below, roughly the same as the Win64 chart), where they are a shade faster than us, gosh dangum darn it. ...but wait, Win64 is another story entirely. Oh boy:

Win64

Compared to Delphi Win64:

• Elements Win64 v2 (default): 2.3x faster
• Elements Win64 v3 (AVX2): 5.5x faster
• Visual C++ Win64 AVX2: 2.7x faster

At our default settings (x86-64-v2), we're roughly on par with Visual C++: as noted, their SSE2 support is a shade faster than ours. (Compare the Elements x86-64-v2 bar on the chart above with the VC++ SSE2 bar: 2.27x vs 2.6x.) But if you can target x86-64-v3 (most CPUs from ~2013 onwards) and compare against Visual C++ using AVX2, Elements is significantly faster than Visual C++.

Wow!

ARM64

Not all toolchains compile for ARM, and their apps run under emulation. This lets us see the performance difference from native ARM combined with our optimizations and math library:

Delphi doesn't compile for Windows ARM yet. If you're running a Delphi Win32 app on Windows ARM under emulation:

• Elements ARM64 native: 11x faster than Delphi Win32 under emulation

Why Is This Faster Than VC++?

We were curious about this too.

Our best explanation for Intel is that Visual C++'s runtime library likely doesn't have AVX2-optimised math routines, or at least not as aggressively vectorised as SLEEF. VC++'s SSE2 math is actually slightly faster than ours on a few specific functions (sqrt, ceiling, floor), but SLEEF's vectorised implementations pull ahead on the trigonometric and hyperbolic functions, and that's where the overall result (the geometric mean) wins.

This applies to all six Elements languages. We wrote the benchmarks in Oxygene (Object Pascal), but that's the compiler frontend layer: the backend where this takes effect is the same for C#, Swift, Go, Java, and VB.

Practical Impact

These benchmarks are tight loops of floating-point math, ie the best case for this kind of optimisation. Your real-world app probably doesn't consist entirely of math. Yet, your real-world app will have many parts that benefit from the optimizations we offer outside of math.

That said, if you have code that does real number-crunching (data processing, simulations, engineering calculations, audio/video processing) you'll see meaningful improvements. The difference between "my app processes this in 10 seconds" and "my app processes this in 2 seconds" matters.

Try It

This – performance, modern features and settings, deep-in-LLVM engineering – is the kind of work we do on Elements. If you try it, I think you'll find it shows.

This week's build of Elements 12, build .3047, introduces a major new feature for the Oxygene language: Raw Strings. Raw strings are a new way of declaring string literals that make it easier to define more complex strings without worrying about escaping things such as quotes or curly braces.

Raw strings can come in two forms that behave similarly in most ways: single-line raw strings and multi-line raw strings. Any raw string literal starts with one or more hash symbols (#) followed by one or more double quote symbols ("), and all raw strings support interpolation with curly braces ({).

Single-line Raw Strings

A single-line raw string starts with the opening sequence (#" or a variation thereof), is followed by one or more non-quote characters, and then terminated by the same number of quotes that started it. Inside the literal, quote (and hash) characters can be used at will, as long as they are fewer than the quotes in the opening sequence, and they are not the first or last character:

var x := #""He said, "Hodwy!"."";

In the above example, the opening sequence has two quote marks after the hash: #"". This means the string will continue until another set of two quotes is encountered. Using single quotes inside the literal, like around the "Howdy", is fine, and they do not need to be escaped.

This works for any (reasonable) number of quotes:

var y := #"""""Want four quotes? why not!"""". It's fine!""""";

Note: For ambiguity reasons, a single-line raw string cannot be empty, as it would be impossible to tell whether it's just starting, or done. But then, an empty raw string is pointless – just drop the # and make it a regular string literal ;).

A single-line raw string must be terminated on the same line that started it (duh! 🙃).

Multi-line Raw Strings

A multi-line raw string starts with the same opening sequence (#" or a variation thereof), immediately followed by a linebreak. No non-whitespace characters may follow on the same line, not even comments (comments inside a string aren't comments, anyways ;).

The actual content of the string literal will start on the next line, and may continue across as many lines as needed to express the string you need.

The closing sequence – the same number of quites that started it – must follow on its own new line, preceded by nothing but whitespace:

var z := #""
         As the water flows over the bridge
         As we walk on the floodland
         As we walk on the water
         We forget
         We forget
         Rain from heaven 
           - The Sisterhood, "Rain from Heaven"
         "";

As before, the number of quotes in the opening sequence determines how many quotes are needed to terminate the string (here, two, therefore, the individual quotes on the last line are accepted as part of the string).

Multi-line raw strings have one additional special behavior, and that is the trimming of leading whitespace. The compiler will look at the number of spaces (tabs count as two spaces) in front of the closing quotes ("";), and remove the same number of leading spaces from the beginning of every line in the string.

As a result, even though the string is indented in code to match its surrounding – loosely suggested by the length of the var z := – the lines of the lyrics will have no indentation in the final string, and the last line of attribution will have only two spaces of indent.

This means you no longer need to have your multi-line strings stick oddly to the left edge of your code, defying the indentation of its surrounding code.

Note: All lines of the string must be indented at least as much as the closing quotes. If a line "sticks out" to the left, the compiler will emit an error.

Also note that the string literal shown above does not include a leading or trailing line break. It starts with A and ends with ". Of course, empty lines can be added at the start or the end of the literal, to add additional linebreaks. The string literal will also not include any trailing whitespace on any line.

Interpolation in Raw Strings

All raw strings support interpolation, similar to the existing interpolated strings starting with $" that Oxygene has supported for a while.

Just like the number of starting quotes indicates how many quotes end the string, the number of hashes (#) indicates how many curly braces ({/}) are used for interpolation:

var a := #"It's {time} o'clock.";

In its simplest form, a single curly starts and ends interpolation, just as you're used to from classic interpolated strings. In fact (with a couple of small caveats noted below), you can probably change most of your interpolated strings over to raw strings, just by replacing the $ with a #.

What if you want literal curly braces in your string... literal? No problem, just use more than one # in the opening sequence, and you can have as many as one fewer consecutive curly braces in your string, anywhere. Need some inline Json, for example? easy:

var j := ##""
         { 
           "Title": "IT", 
           "Author": Stephen King",
           "Published": 1984
         }
         "";

Need more than one? Also no problem:

var k := ###""{{Hello in double curlies, {{{lName}}}}}"";

Here, the double curlies at the start are kept literally, but the triple curlies near the end will treat lName as interpolated code.

If a literal contains more consecutive curly braces than needed to start an interpolation, the additional curly braces are kept literally:

var l := ##"keep a curly here: {{{5+3}}}"; // "keep a curly here: {8}"

Note: as mentioned before, there are a couple of small behavioral differences between interpolated raw strings. These are especially important to keep in mind if you are changing your $" strings to #" for consistency:

In classic $" interpolated strings, two {{ would be used to "escape" the interpolation. Raw strings do not do escaping like that, so you'd want to use  ##" instead, to have single-curlies in your literal without the need to escape them:

var x := $"{{keep one curly}"
// equals:
var x := ##"{keep one curly}"

Also, classic $" interpolated strings (and non-interpolated strings with double quotes) may contain linebreaks at any point, and will preserve all leading whitespace. Raw strings, as outlined above, will not, and must start on a fresh line, if they are multi-line:

var x := $"this
 is fine";
// equals:
var x := #"
         this
          is fine
         ";

Editor Support

The code editor in Fire and Water has been updated to visually highlight (or rather, lowlight) the curly braces "swallowed" by the interpolation. Especially when you're surrounding interpolations with additional curlies, this is a helpful visual aide:

Also: Delphi Multi-line Strings

It's worth mentioning here that a short while ago we also added support for Delphi's new multi-line string syntax, for compatibility purposes. Delphi multi-line strings start with an odd number of three or more single quotes ('), and end with the same amount. Similar to Oxygene's (and C#'s) raw strings, they too require the content of the literal to start on a new line, have the closing sequence on a new line, and will remove any leading whitespace. They do not support interpolating.

var d := '''
   Delphi's multi-line
   string syntax 
   is supported too
   ''';

Get Elements .3047 Now.

Elements build .3047 – with the new Raw Strings on Oxygene and much more is available on the Stable channel now, as free update for all customers, and as free trial download for new users.

Enjoy!

A few months ago, we previewed an AI coding assistant for Delphi called CodeBot at Embarcadero's AI Code Camp. In October, we gave a preview of an early alpha to the attendees at EKON. On January 13th Embarcadero and RemObjects will have a special webinar on CodeBot, including info about the beta!

Join live on Youtube here – no registration required!
Tuesday 13th January, 12 midday US Central, 6PM UTC.

And we have a teaser for it:

We're really looking forward to this webinar – don't forget to sign up for CodeBot updates at the bottom of this page!

From all of us here at RemObjects Software, we would like to wish you Merry Christmas, Happy Holidays, and a Happy New Year!

2025 has been an incredible year for the company and for our products. We have expanded our team, shipped countless updates to all products with many exciting new features, as well as launched the first brand new product in a few years. And our Oxygene language has seen its twenty-year anniversary this past year!

We're still just getting started, and we can't wait to share with you what's coming next!

See you in 2026.

Take care
–marc

This weeks build of Water, our Windows IDE for Elements adds an exciting new visual feature that many of you have been asking for for a long time: themes!

On the Fire side, we have had support for light mode and dark mode for a while, including dark (and light) editor color themes that force the IDE into dark (or light) mode, as well as the default theme which adjusts with the system.

Folks on Windows, using Water, have been stuck using only the light editor themes, because the rest of the IDE was not made to go along with (or look good) in dark. No more!

First, there's now the Black theme. Same basic colors as White, but the entire IDE is in dark mode, for the nightowls:

If you don't like it quite as dark, there's also Dark Gray. It's very simialar to the existing Light Gray editor theme, except the rest of the IDE gets themed – well – dark, rather than staying white:

For a bit of nostalgia, check out the the Turbo Pascal 2 theme takes you back to the 80s, with a dark IDE and, gray and yellow text on pitch-black. If I could stand to work in dark mode myself, this one would be my go-to:

We've also added a Monokai-inspired theme, for those of you who are more down to earth(-tone colors), or used to the color theme from other editors or IDEs.

Finally, the entire IDE also gets a retheming for the existing Pink Dream theme we introduced a few months back:

Each theme expands thruout the entirety of the IDE, including secondary windows such as the Preferences sheet here:

Themes are available in Elements .3041 today. As always, this build is a free update for all active subscribers. Get your copy now!

I am super thrilled to announce the release of our next brand new product here at RemObjects: GitBrowser.

GitBrowser is a native Git version control client for the Mac that aims to be easy and comfortable to use for beginners and Git experts alike, and to make the most common day-to-day version control tasks of developers not just easy, but fun.

Like our other tools, GitBrowser focuses on not getting in your way, and being lightweight, as well as intuitive and quick to use. Is has a major focus on working with multiple (dare I say, many) different Git repositories at once – a main feature I found lacking in most, if not all, other popular Git clients, but it will still be a faithful companion if you only work on one or two Git repositories at a time.

When you first start GitBrowser, it will ask you to add one or more local Git repositories to it. You can do so with the "Browse..." button on the Welcome sheet, or you can drag your folders in from Finder (or anywhere else) to the sidebar, at any time.

The sidebar always gives easy access to all the repositories you work with. You can arrange them in groups, sort them as you like, and even give them custom names. Selecting a repository in the sidebar immediately activates it and allows you to work with it. And you can even perform actions on any repository (active or not) from the context menu. Of course, you can hide and show the sidebar by pressing ⌘1, at any time.

The center column of GitBrowser shows the version history of your repository. All commits of your current branch are listed, with local commits that still need to be pushed shown in bold at the top, and any remote commits you have yet to pull shown in italic, above them. In addition to date color-coded author and commit message, the commit log also indicates any tags, and highlights merge commits in blue.

Select any commit, and the right-hand pane of GitBrowser will show its details, with the list of files affected by the commit at the top, and an inline diff view of the selected file at the bottom. Switch between files to browse all the changes of a commit.

Of course, sometimes you want to explore a changed file in more detail. Simply double-click a file, and GitBrowser will open it for comparison in your favorite diff tool (currently supported are Araxis Merge – IMHO the gold standard of diff tools, and my personal favorite – as well as BBEdit (yes, BBEdit has a diff viewer built in!). More options will be added based on user feedback, so let us know what your favorite diff tool is!)

The commit log has one additional row at the very top, and that is your local changes. Depending on the local status of your work, it might show "No local changes.", or a summary of locally changed, added, or deleted files. Selecting this row will show you GitBrowser's staging area in the right-hand pane

The staging area looks very similar to when you were viewing a previous commit, but it instead shows your local changes and – well – allows you to stage them for commit. In the file list at the top, you will see all files that have local changes, as well as any new files that are not under version control yet. You can check or uncheck the checkbox at the very right to stage (or unstage) one or more files. You also have more options available – such as stashing away changes for later, in each file's right-click context menu.

If you select a file, you will see the local changes in the embedded diff view at the bottom, just as before. This make sit really easy to double-checkl them all before staging – a practice i highly recommend.And of course you can double-click the file to open itn in Araxis Merge or BBEdit, to explore the diff in more detail.

If a file has both staged and unstaged changes (e.g., you staged it, and then made more changes – indicated by the checkbox showing in intermediate state), it will open as a three-way diff in Araxis Merge, showing you the original, the staged changes, and your local changes compared.

To commit your staged files, simply type in a commit message and then click the button. You can also press ⌘Enter+Up to commit and push in one go.

Are you sometimes bored with writing commit messages from scratch? GitBrowser can do it for you! In the Settings window (⌘,) you can connect GitBrowser to your favorite AI account. Once you have done so, all you need to do is mark a file (or several) for staging, and GitBrowser will automatically get busy and, within a second or so, prefill the commit message field with a (usually pretty good!) summary of your changes. You can accept the message as is, tweak it, or, of course, just write your own to replace it.

GitBrowser can use OpenAI, Claude, Gemini, Grok and Mistral as AI provider, as well as a local LM Studio (same as CodeBot in Fire)

Some more niceties and small details...

• You can press cursor-up/down in the commit message field to easily "recycle" one of your previous commit messages. Very handy if you're making multiple related commits, or following up on a previous change. (cursor-up/down works if the field is empty, or the current message is AI-generated). You can also right-click any commit in the commit log to reuse its message.
• GitBrowser lets you easily pull all your repositories (or all in a group) from the "File" menu, or the sidebar's context menu. Nice when you come in in the morning and get up to date with what the rest of the team(s) have been up to.
• GitBrowser finds Elements solutions in your repository and lets you easily open them in Fire from the context menu in the sidebar.

• Press ^⌥⌘F or ^⌥⌘T at any time to open your repository folder in Finder or Terminal, respectively.
• You can drag any file from GitBrowser to copy or open it. Dragging a file from a previous commit will automatucally extract that revision. You can also drag your repository folders from the sidebar, e.g. to open them in BBEdit or other folder-based tools.
• The diff view shows tabs as 8 spaces. This is on purpose, as it makes it really stick out if your file accidentally mixes tabs and spaces form indentation (something that of course cannot happen if you use Fire ;).
• You can swicth between local branches (and check out new remote ones) from the braches popup button in the toolbar. Local branches eill show in bold, if they are ahead of your current branch (i.e. has new stuff your).

... and much more.

In Summary

Version control – and let’s be honest, today that means Git – is (or should be) an essential part of every developer’s workflow, and it all stands and falls with having a great tool that makes version control easy and – dare I say – fun, rather than a chore.

For me, for the past three years, that tool has been GitBrowser, and I would not want to miss it. Which is why i am so excited to now be able to share it the rest if the world – and for free, no less.

Please remember: the goal of GitBrowser is to make the common, routine, every-day tasks of version control easy and intuitive. Pull, push, review tour changes and commit them, review what your team is up to, etc. It is not meant to be the and-all swiss army knife for all your advanced Git needs, and it currently does not replace falling back down to the Git command line for more complex and esoteric tasks – nor will it ever, probably.

As time goes by, we will add more and more functionality to it to make these common day-to-day tasks easier, and to cover more common tasks that GitBrowser currently maybe does not handle yet (includindg, yes, some very obvious ones still missing). Please let us known in the forums what you're missing, or what you'd like us to add.

Get Your Copy, Now!

GitBrowser is available now, as free download, at remobjects.com/gitbrowser. It is completely free, but it does require you to sign up for a free license, after a 30-pday trial period, available.

If you have any questions, suggestions, feedback or complaints, please let us know on our support forum, RemObjects Talk, at talk.remobjects.com/c/gitbrowser

I hope you enjoy using GitBrowser as much as I enjoyed creating (and using) it, every day!

Nov 14 marc hoffman b7f6b866707aff6ea80e0cf591377285bd781dfc GitBrowser: GitBrowser 1.0 📌 .237
...
2022 Nov marc hoffman bd7a07cfffe2b0c60f78951319c951b7f26f6ba1 GitBrowser app (wip)

This week is the Android release for Elements.

I'm a bit ashamed to admit that over the past couple of years, we have been neglecting the Android toolchain a bit. Google introduced some significant changes to their tooling a while back, including the new d8 engine for converting Java byte code (which our compiler for Java and Android emits) to Android's Dalvik bytecode, and the new aapt2 tool for processing resources – a very messy system on Android, if you ask me.

These new tools broke a lot of things, and their usage (outside of Google's own Gradle build toolchain) wasnt'/isn't very well documented, and at some point we just kind of threw the towel 🤷‍♀️. Simple Android apps are still built, but anything more complex depends on dependencies and resources had problems getting past aapt2.

Over the past month or so, I've been working on the side to bring one of my personal pet projects back to life. At first, the plan was to only focus on the iPhone version (done and done), but my partners in crime at the Meteorological Department Curaçao convinced me to also take another stab at reviving the Android version – Android being a very popular platform here.

Just like with iOS, this started by taking a deep dive into our Android toolchain in EBuild, and making many improvements. And i'm happy to say that with the help of a good friend, I was able to finally sort out all the intricacies with getting aapt2 and the rest of the gang to work as they should, and consistently. This involved improvements and fixes to

• Gradle/Maven package resolving
• Pre-processing of resources from .aar ("Android Archive" – essentially a .zip with a .jar, resource files, and other stuff)
• Pre-converting ("pre-dexing") external .jar references
• Build caching
• Packaging the final product
• ...and more.

In the end, my existing (at this stage, pretty old) app once again builds okay – with virtually no changes to the code needed, so I'm now ready to work on it again.

Android Push Notifications

With that out of the way, I set out to do one more Android-related task that I had been postponing for a long time, and that is implementing a clean system for Push Notifications for Android – which leads me to a small teaser for an upcoming new product.

When I first started working on Curaçao Weather, almost 10 years ago now, one of my goals was to make the app essentially "serverless". Yes, there is a server component that performs regular, scheduled processing of data (such as gathering weather data from multiple sources and putting it into a consistent format that the app can rely on). But the app doesn't talk to that server. Instead, all the data is stored in a semi-public S3 bucket whenever the processing runs, and the app can just download all the information it needs from there. I simply didn't want to worry about scaling issues (even though I am, of course, sure our software stack can handle them – it's what it was designed for, after all). But just plain static HTTPS removed a lot of that complexity.

But there were two features we couldn't handle with just that, and those were letting users send reports for weather impacts from the app back to the server occasionally, and – more importantly – handling Push Notifications.

Being a big fan of Amazon AWS in general (we use it for all our hosting, and much more), I turned to two solutions provided by AWS for solving this – even though I was reluctant to rely on third-party abstractions like that, and would end up being proven right.

AWS provided/provides abstracted support for cross-platform push notifications that merely required some (convoluted) setup on their system, and use of Amazon's client library inside the app – both on iOS and Android.  The system worked well... until it didn't, some five years ago, when it just stopped working. And, being a convoluted abstraction on top of many lower-level AWS systems, it was impossible to get to the bottom of it – so I scrapped it all, and implemented Push myself (something I had done before), but for iOS only.

I still liked the idea of being "serverless" for this app, so I thought: if I did have to create a server for the app to talk to, why not make it a general-purpose server for any app that needs similar functionality?

And with that (and some other ongoing projects), a new set of twin projects had been born:

Quantum Server & RemObjects Infrastructure

QuantumServer and RemObjects Infrastructure are two new products we have in the works, and they are, if you will, flip-sides of the same coin.

RemObjects Infrastructure is a set of Enterprise-level libraries (primarily for .NET, but some cross-platform) that implement functionality commonly needed in enterprise server back-ends. It includes things such as login and identity management, abstracted file storage, Push Notifications and email, AI model access and AI chat, and much more.

It builds on top of Remoting SDK and Data Abstract (where applicable), built on Oxygene, and is meant to be used by developers creating their own backend. While not publicly available yet, it has been successfully deployed by a range of initial development partners who helped drive its development. CodeBot in Fire and Water is also built on the AI layer provided by Infrastructure.

It is also the foundation of Quantum Server.

RemObjects QuantumServer is a stand-alone precompiled server application that exposes (or will expose) much of the functionality provided by Infrastructure, but without the need to build your own backend. You just install and configure it, then focus on creating "client" applications that can depend on it.

Curaçao Weather was one of the first projects to use QuantumServer, and now uses it for Push Notifications on both iOS and Android, as well as "dead drop" for one-way delivery of reports users want to share with the weather department.

As a result, I was able to drop any third-party dependencies on the AWS client libraries and similar components from the app.

Read more:

• Curaçao Weather App (iPhone/iPad/Mac app is available now, Android will be back in the store soon)
• Vision Thing B.V., the company behind it (and some other cool apps)
• RemObjects Infrastructure teaser page (stay tuned for more details)
• QuantumServer teaser page (same)
• and of course Elements, the toolchain that makes it all possible

I have spent the bulk of the past two weeks working on two personal side projects – built in Elements, of course. As is usually the case, this gave me ample opportunity to identify areas for improvement and add features to make Elements even more useful for everyone.

As such, builds .3023 and .3025 bring a vast amount of tweaks for macOS and (especially) development. In addition to many smaller quality-of-life fixes i'll list below, there's one major new feature: direct publishing to App Store Connect right from the build.

What happened is that after a few days of working on my projects, Apple's Transporter app, which is used for uploading apps to be published on the App Store, stopped working for me. When i say "stopped working", i mean it became literally unusable. Every time I start it, it crashes immediately, within a few seconds. From the crash log (reported to Apple, of course), it looks like maybe the app couldn't handle that I now had an iOS 26 style icon in the last version of my app that I submitted (successfully) with it.

A solution was needed, and there is a command-line tool that can be used to submit apps as well, so I figured it was time to just integrate this into EBuild!

Below, I will describe the whole process you need for submitting apps, both to the iOS and the macOS app store (the processes differ slightly). Some of the steps are not new, but the final actual submission set is.

Submitting apps to the App Store with Fire and EBuild

The first thing you want to do to prepare your project for app store submission is to designate one Project Configuration for it. You can either just use the "Release" config (I did that for my iOS app), or you could create a dedicated "AppStore" config (which I did for my macOS app – mainly because I also want to build that app for Developer ID – i.e., distribution outside of the Mac App Store).

You'll set up all App Store-specific settings for this configuration only – this way, you can keep using the Debug config for local testing.

The first thing you'll need to do is go to "Certificates, Identifiers & Profiles" on Apple's developer website and set up a few things. That page is handyly available right from the "Tools" menu in Fire:

You will need to create three (and a half) things:

• Create an identifier for your app. This is a reverse-dotted-domain style name that will uniquely identify in your app within the App Store. You will usually include your reverse company domain, e.g."com.evilcorp.mycoolapp".
  As part of setting up this identifier, you will also select any special capabilities that you want your app to use that need Apple permission – e.g. using MapKit, getting Push Notifications, access to HealthKit, or whatnot.
• With that done, you will create one or two certificates that are used to sign your app. You will need an "Apple Distribution" certificate; that one will work for iOS and macOS, and you can use the same certificate for all your apps. For Mac apps only, you will also need an additional "Mac Installer Distribution" certificate.
  Follow the steps on the website to create and download these certificates. This includes creating a Certificate Request in the Keychain app, uploading it, and then downloading the result. Double-click the downloaded file(s) to install the certificates in your keychain.
• Finally, you need to create a provisioning profile for your app. You need to pick either an "App Store Connect" (for iOS, tvOS, visionOS, etc) or "Mac App Store Connect" (macOS, duh) from the "Distribution" subsection.
  As part of creating the profile, you will select both the identifier and the certificate you created before, as well as a unique name. I find that I often need to update and re-download profiles for my apps, so I suggest giving detailed names to these. The pattern I use is "App Name (Month Year [optional letter])", e.g. "Verbs (September 2025)". That way, if I download new ones, I always know which one's the latest one.
  After downloading the profiles, you can simply double-click the iOS ones to have Xcode install them in the right place for you. I found this does not work for macOS profiles (Settings.app wants to install those), so instead, you need to manually copy those to ~/Library/Developer/Xcode/UserData/Provisioning Profiles.

With these three things out of the way, you can now set up your app project.

• First, make sure the "Bundle Identifier" setting in the "Packaging" section matches the identifier you picked above. You can set this on the project level (recommended), or specific for your App Store configuration (if you want to use a different identifier for local development)
• Next, navigate to the "Signing" section in Settings, and select your newly downloaded profile under "Provisioning Profile Name" and the Apple Distribution certificate under the "Certificate Name" setting.
• For macOS apps, you also need to pick a value for the "Installer Certificate Name" setting; select the second certificate you created; it will be called something like "3rd Party Mac Developer Installer: Company Name (TEAMID)".

If you don't see your new values yet, select "Refresh Options" from the pop-up. Make sure you pick the right items; especially for certificates, you may see many similar options to choose from – your certificate should be named "Apple Distribution: Company Name (TEAMID)", where your company name (or personal name) matches how you registered with Apple, and the Team ID is a ten-digit number/letter combo.

Make sure the certificates you selected are named "Distribution", and not "Development"!

Do note: the exact naming conventions of these certificates have changed over time, and may change again; the naming I am using here is based on certificates I generated just now, in September 2025.

Next, let's move to the "Packaging" section.

Since this only applies to building apps, your project will already have "Create .app Bundle" set to YES. Let's enable packaging that bundle for distribution, which is easy:

For iOS (and tvOS, visionOS, etc), enable the "Create .ipa File" setting. .ipa files are essentially .zip files that contain your .app bundle, as well as additional metadata. Elements creates them for you.

For macOS, enable the "Create .pkg File" setting instead. Mac apps get packaged as an installer package, for legacy reasons. But no worries, this is also handled for you.

If you do a build for your App Store configuration now, you should receive, as final output, a .ipa or .pkg file with your app name, its current version number appended. This file is ready for submission to Apple.

Distribute This!

Finally, let's set things up to upload your file to App Store Connect automatically for you. There are four settings available for this.

• First, you need to set the "App Store Connect Username" and "App Store Connect Password" settings. Username is your Apple ID, and for the password, you need to create an "app-specific password" at account.apple.com.
  I recommend setting the password in the "User" column of the settings, which makes it stored in your local .elements.user file, which you usually would not commit to, e.g., Git, or share with others

Ostensibly there is a way to store the password in Keychain instead, and EBuild will try to get it from there, if you leave the password empty – but in my testting, I have been unsuccessful in making this actually happen according to how Apple document it should work. 🤷‍♀️

• Lastly, there are two options you can choose for what to do on App Store Connect. You can set the "Validate w/ App Store Connect" setting to YES, and Elements will upload your final app to Apple for verification, but not submit it yet. If you set "Publish to App Store Connect" to YES, your app will be uploaded and submitted. Assuming that is successful, you will see the new build show up on the App Store Connect website within a few seconds, and within a minute or so (usually), you can take next steps – such as sending it to your testers on TestFlight, or submitting it for actual review to the store.

The "Validate w/ App Store Connect"-only option is a great first step if you just want to see if everything is configured correctly, as it will show you warnings (or errors) if anything is off, e.g. if you have a wrong profile or certificate selected, of if there's any other techncial problem that would prevent the binary from being submitted.

It is important to know that you can only (successfully) publish a build to App Store Connect with any given version number, once. After publishing has succeeded, you will have to increase the "Bundle Version" setting to a higher semantic versioning value before you can publish another build. For this reason, I would generally recommend only turning the "Publish to App Store Connect" option on after you have validated, and once you're sure that this is the build you want to publish. You can leave "Validate w/ App Store Connect" on all the time; "Publish" overrides it.

Of course, once everything is set up smoothly and you're in the groove of submitting new builds regularly without a hitch, you can just leave "Publish to App Store Connect" on for good. Work/test in your Debug profile, and when you're ready to ship a new build, just update the Bundle Version, switch to the App Store config, and press ⌘B – done. Then switch back to Debug to keep working.

Other Toolchain Fixes and Improvements

More things were fixed for Cocoa development this week

• The default location for provisioning profiles moved (and Xcode now clears out the old one, sometimes). EBuild now finds profiles in both places correctly.
• The internal tool for creating .pkg files moved with Xcode 26
• The toolchain was improved for handling new "os 26" icon files – both for macOS and iOS. The "Application Icon" setting is now available for iOS as well, and uses the new .icon format. For macOS, you can still specify a legacy .icns for pre-Tahoe, using "Application Icon (Legacy)" setting.
• When running in the iOS  Simulator, console output was not available in the Fire debug console, which made debugging very annoying. This now works as expected (but only for NSLog() and RTL2's Log function; there unfortunately is no way to get full StdOut (e.g. writeLn()) from the Simulator. I recommend using Log cross-platform everywhere. Also, check out the log and logc editor code snippets!)
• Third-party Frameworks nested in an iOS app were incorrectly re-signed with the app's bundle identifier, instead of their own. This was never an issue before, but it is now, so that was fixed.
• You can now explicitly mark framework references as "weak" in the IDE. This is helpful (dare say needed) for supporting older deployment targets. For example, iOS 26 pulls in a new UIUtilities framework if you use UIKit. You need to mark that as weak, or your apps will crash on start, on iOS 18 and below.

• There have been improvements to the iOS debug engine for evaluating locals, class members, and structs.
• There's a new "Always Build for Device" option that you can set for your Release/AppStore config. That way, you can keep, e.g., your favorite Simulator selected in the IDE, but when you switch configs to build for publication, it will build for a device, without the need to also change the target device.

Get Elements build.3025 now, out on the Stable channel for all active customers, and as a free thirty-day trial!

This week, Apple is releasing macOS 26 "Tahoe," the next major version of its Mac operating system. Tahoe brings a huge visual design change to macOS, and we've taken this opportunity to do some visual refinements to Fire, our Mac development environment for Elements, as well – both to make Fire fit in well with the changed aesthetics of Tahoe, but also just to give it a fresher and more modern look in general.

Personally, I think Fire has never looked more beautiful! 🤩

The new unified status bar now extends across all three panes at all times, and of course, still changes color based on what's currently happening in Fire – building, debugging, or if the last build failed.

Cleaner, SF Symbols-based icons have been added throughout the IDE, including for common actions on the toolbar, round building/running status icons that perfectly fit the new pill shape of the Tahoe tabs, as well as fresh icons for all objects in the application.

And Code Completion and other editor popups now show in beautiful Liquid Glass:

We've also added a few fun new themes, alongside tweaks and improvements to the existing ones. For example, here's the awesome new Pink Dream theme...

...and for the old-skool Pascalers among us, the Turbo Pascal theme will make you feel like you're back in the 80s, hacking away at Nicki the Robot in Turbo Pascal 2.0. Without losing any of the cool features that Oxygene has added to Pascal since those days, of course :).

Water

While not related to Tahoe of course, Water – our environment for Windows – has also received some GUI love, with all new toolbars, and other tweaks.

It's been a while since I've written one of these, but this week's Preview build of Elements, numbered at .2997, has such an astounding amount of stuff in its change log that I thought it might be worth talking about some of it.

As you know, we ship new Elements updates (almost) every Friday – even though we skipped one last week, because some stuff wasn't quite ready, but was "happening on main", as they say. Today's build is on the Preview channel, but should be solid to use; the expectation is that next week's update will be on Stable.

Let's dig in.

To start with, we've made a lot of UX improvements to license management and related areas. For one, you'll see a more straightforward and more intuitive UI if your trial license (or, god forbid, actual license) expires, along with options to purchase/renew, and request a trial extension (an option many users were not aware of):

We've also added a brand-new License Manager view that shows you all the licenses the IDE knows you currently have – again with a lot of actionable items to address shortcomings – and a cleaner and prettier way to log into your RemObjects account (more on that later).

Next, we've revamped the management of API keys for CodeBot and introduced a feature I wanted to add to Fire for a long time: Account Manager. The Account Manager sheet (available from the "Tools" menu and from CodeBot Preferences) is your one-stop place to register all accounts Fire and Water use – including your RemObjects account (which gets used to auto-update your licenses, as needed, as well as to check for updates), any AI accounts (such as ChatGPT) you want to provide for CodeBot and – in the future – more.

Your existing API key(s) for CodeBot will be migrated automatically on the first launch of the new build. And moving forward, you can add. more API keys as needed – including different keys for the same provider (if you have a company and private account for OpenIA, for example).

CodeBot now also remembers your preferred model per account, so you no longer need to re-select it when you switch.

CodeBot also gained a lot of other enhancements under the hood. It's gotten better at being able to make updates to your code (lots more coming on that front, soon), and it now has better, project-, platform-, and language-specific guidance for each prompt, making it even better a kowing what kind of code to generate for you (for example, in the past the model would often try to "Xamaini-fy" Cocoa calls when working in C# or Oxygene, rather than giving you the proper code using the straight native Objective-C-style APIs).

Improvements have been made to the toolchains for Delphi users, as well. You can now import an entire .groupproj file in the IDE (from the "File|Import Delphi Project..."), and Water will convert ot to a .sln and convert all the projects within. Project import/conversion itself has improved, bringing you even closer to a buildable project, sooner. For example, project dependencies are detected, and (where feasible) runtime packages will be referenced for you automatically.

Also, if you're building an Island/Delphi project for the first time, and you haven't imported the necessary Delphi SDKs yet, Water will now detect this and offer to do it for you automatically. SDK import also handles the latest (future) Delphi versions, now.

Expect more improvements and enhancements in this area soon, as we have many great things planned for Delphi developers.

Speaking of Windows, we've made improvements to our toolchain for Windows on arm64 – something that is becoming increasingly more important both to Windows devs, and Mac users running Windows in a VM on Apple Silicon.

We've finalized Island RTL and GC, so building native Island apps for Windows/arm64 is now fully supported. There's still some work left to do to make the debugging experience as smooth as it is on the other architectures.

Speaking of architectures, just as on modern Macs Fire allows you to easily test your app against Intel by selecting the "Mac (Rosetta)" item from the CrossBox menu, on Windows, you now get the option to pick a legacy/emulated architecture, where available. On x64 Windows, you will see a new "Windows PC (i386) option, and choosing it will run your app as 32-bit, if possible. On arm64 Windows, you will see an additional "Windows PC (x86_64)" option to run your app on emulated Intel rather than on native arm64.

And of course, you can select which of the three architectures you want to support at all, with the "Architecture" Project Setting; by default, Island projects are built for your local native arch.

BTW: the Environment.OSArchitecture and Enviornment.ProcessArchitecture functions in Elements RTL are very helpful for finding out at runtime how your app is running and what it is running on. And they work across all Elements platforms.

Let's see, what else is new?

We've made some improvements to the Debug Panel in Fire and Water. Per popular request, a toolbar button has been added to clear the debug log – previously, this feature was only available via the main menu and keyboard shortcut. Also, on Fire, hiding the debug pane will now smartly keep the debug toolbar visible while a debug session is active, and dismiss it when not. Especially helpful if you let the IDE manage showing/hiding the debug panel for you.

Last but not least, this build adds support for building against the new macOS 26 "Tahoe" SDK, and has received a first round of UI refinements and improvements to make Fire look great on the new Liquid Glass design of macOS 26. Of course, this will be an ongoing process as the new look evolves over the next three months of beta period.

That's it, you ask? No, of course not. As always, there are a whole bunch of other minor fixes and improvements too small to mention here. You can check out the complete change log here.

As always, the reminder that Elements build .2997 is a free update to all users with an active subscription. It being a Preview build, it is not available as a free trial download, but next week's .2999 should bring everything discussed here up to the Stable channel as to trial users, so stay tuned.

Buy your copy of Elements at remojects.com/shop, if you haven't already!

This week's build of Elements introduces a new aspect-based feature to Elements RTL: support for simple and easy no-code serialization.

With Elements .2981, you can now easily add the ability for a class to be read from and stored as Json or XML, simply by applying the new [Codable] aspect to it:

type
  [Codable]
  User = public class
  public

    property ID: Guid;
    property Name: String;
    property Email: String;
    property Telephone: String;
    property ZipCode: String;
  
  end;

Once a class is marked as such, you can use the new Enoder and Decoder descendant classes in Elements RTL to convert instances of that class into encoded data or create new instances from encoded data. Coder implementations are provided for Json and XML, but you can, of course, also create your own – for custom data formats, or if you want more flexibility or different output than you are getting from the provided implementations.

var lCoder := new JsonCoder;
lCoder.Encode(lUserA);
writeLn(lCoder.ToJson);

var lCoder := new JsonCoder withJson(lJson)
var lUser := lCoder.Decode<User>;

Controlling the Coding Format

There are a few ways you can influence how your types get encoded (and decoded). This is helpful to match your personal taste, but also if you need to conform to predefined Json or XML schemes that don't exactly match your code style.

By default, the names of the properties are used "as is" to determine the encoded values' name, so ZipCode will come through as e.g. "ZipCode": "44229" in Json.

The [Codable] attribute can take an option parameter of type NamingStyle that lets you override the naming rules. Supported values include camelCase, PascalCase, lowercase and UPPERCASE (sorry for yelling). The default is AsIs.

PascalCase and camelCase use smart logic to convert the identifiers in your code into the proper convention, ez ZipCode would become zipCode in camelCase.

type
  [Codable(NamingStyle.camelCase)]
  User = public class

You can also override the coded name of individual properties by adding the [Encode] attribute with a string value, eg:

[Encode("plz")]
property ZipCode: String;

Encode can also take a boolean parameter instead, and by specifying Encode(false) you can skip the property from being coded. ([Encode(true)] is implied, so specifying that would be redundant ;).

Supported Types

You can encode or decode classes (or records, i guess) that contain any of the following types

• Integers and UInts (8, 16, 32, 64 bits, plus IntPtr)
• Float and Double
• String
• DateTime (encoded and expected as ISO8601)
• Guids
• Json objects and arrays
• List<T> of supported types
• arrays of supported types (.NET only)
• Types that implement IEncodable/ IDecodable or the ICodable combined interface.

The Json coder will encode properties of JsonNode types natively; e.g. if your class has a JsonObject or JsonArray field, it will be encoded as a nested object or array in the result, and read back as such. Other encoders will encode them as string values.

As you may have guessed," Types that ICodable" includes any type you mark as [Codable], since what this aspect does is precisely that: it implements the interface for you, providing strongly-typed code that encodes and decodes all its members (without the need for Reflection).

You can also implement this interface yourself if you want to provide a custom way of how a specific type is encoded or decoded, instead of how [Codable] does it. Maybe you have a type that represents a data blob, and instead of coding its properties, you want to encode its data as a Base64 string.

Convenience

Some additional convenience can be gained in addition to applying [Codable] (or implementing ICodable), you also make your type decent from the Codable helper class. This is entirely optional but gives you additional niceties, such as a constructor withJson(aJson: JsonDocument); constructor, a ToJson, and a default implementation of ToString that returns the type as Json string.

How to use it?

Using RemObjects.Elements.Serialization is easy:

1. Make sure your project uses (or at least references) Elements RTL (i.e. has a Elements reference).
2. Add a reference to the new RemObjects.Elements.Serialization.dll from the "Cirrus" tab in the Reference Manager to it.
3. Add RemObjects.Elements.Serialization to your uses/import clause.

And that's it.

PS: Check out JsonDocument

As part of implementing RemObjects.Elements.Serialization (and working with a lot of Json in general), we have made a ton of improvements and tweaks to the JsonDocument implementation in Elements RTL over the past few years. If you have any need to work with Json data, I recommend you give it a try. (JsonDocument is also fully cross-platform across all Elements platforms).

Feedback

RemObjects.Elements.Serialization is solid and time-proven; I have been using it for internal and Infrastructure projects for going on two years now, and I expect you will find it immediately useful.

Let me know what you think and/or if you have any ideas for improvement!

I can't believe it's already been almost two years since we introduced CodeBot for our Fire (and shortly after, Water) development environment for Elements. A lot has changed in the AI landscape since then, and today, I am excited to talk about a whole bunch of improvements we're bringing to CodeBot in the latest Elements update.

To start with, CodeBot has been promoted from its own window into a new side panel on the right side of the IDE. This makes CodeBot even more accessible as you code, as you can easily look at CodeBot and your code/project without having to window-manage. Especially helpful if you're a fullscreen person like me. It also, as we'll see below, gives CodeBot more intimate access to exactly what you are working on right now – optionally, of course.

Secondly, in addition to being able to help you out with general questions and tasks and reacting to specific actions triggered right from inside the editor, CodeBot now also has direct access to your solution and the IDE to help you more proactively understand your code better and even perform changes and actions for you.

CodeBot can now look at the structure of your project, peek into particular files, and it can even add new files for you as needed. For example, you could ask it to create a new class that does <blank>, and it will automatically add it to your project.

While you are working in the code editor, CodeBot can have more direct access to what you are doing – for example, it can see your current selection, you can ask it to modify or replace your selected code, or insert new code at the cursor – among many other things.

CodeBot can also perform general actions, such as, for example, launching your project in the debugger or running tour EUnit tests.

Of course, we do realize that not everyone will be comfortable with giving an AI but this level of access to your code, so in addition to CodeBot being opt-in to start with (you need to provide your OpenAI API Key in Settings to enable it), you can disable CodeBot's access to your code and IDE, by unchecking the "Allow CodeBot to access Project data and Fire features" option.

With the option off, you can still use CodeBot as before for general questions or to explicitly trigger it on code snippets from the editor, but CodeBot will not be able to decide to look at (or change) your code on its own.

Finally, we've opened CodeBot up to be used with different LLM providers in the back. Until now CodeBot was exclusively backed by OpenAI's "gpt" model, and an OpenAI API key was required to enable it.

While in my experience, gpt-4o (at the time of writing this) still gives the best results, you can now select different LLM providers for CodeBot in settings. xAI's Grok is supported alongside Google Gemini, Mistral and Anthopic's Claude.

What's more, CodeBot can also, optionally, connect to local models running right on your system (or local network) in the open-source LM Studio app. This gives you even more options to explore the cutting-edge LLMs right from inside Fire and Water – at no cost for an AI account and without even requiring an internet connection. Performance and capabilities of this approach, of course, depend on your available hardware. I've been testing locally on my MacBook Pro with M2 Max and across the LAN onto a Mac mini with an M4 Pro, and I have been getting fairly good results (but I still find myself going back to 4o).

But this is just the beginning (again); we have lots more in the works. Let us know what you think, how happy you are with the results you get, and what other features or more tight integration between CodeBot and the rest of the development environment you'd like to see.

CodeBot v2 is available in Elements build .2975 and later, available now on the stable channel as a free download for all active subscribers, and as a free trial.