> ## Content Index > Fetch the complete content index at: https://blogs.remobjects.com/llms.txt > Use this file to discover other available public pages before exploring further. # Behind the Build(s) — .2605 - URL: https://blogs.remobjects.com/2021/02/20/behind-the-build-s-2605/ - Published: 2021-02-20T12:45:43.000Z - Updated: 2021-02-20T12:45:43.000Z - Author: marc hoffman - Tags: #Import 2026-08-17 20:17 On Friday we published [Elements](https://www.elementscompiler.com/elements/?ref=blogs.remobjects.com) build .2605, the first "Stable" channel build of the year, and wrapping together a *lot* of great changes and improvements from the past couple months of previews. Let's have a look at some of the new features and enhancements ## Support for Importing `.xcframework`s .xcframeworks are a new(ish) file format introduced by Xcode that allows grouping a set of frameworks for two or more Apple platforms in one container. Essentially, it is a folder structure that can contains separate regular .frameworks, build for each of Apple's SDK types (macOS, iOS, tvOS, watchOS) and (in EBuild parlance) [Build Destinations](https://docs.elementscompiler.com/EBuild/Projects/BuildDestinations/?ref=blogs.remobjects.com) (Device, Simulator, Mac Catalyst). For a while, Elements has been able to automatically import Objective-C .frameworks for use in your projects, via [Import Projects](https://docs.elementscompiler.com/Tools/FXGen/ImportProjects/?ref=blogs.remobjects.com), and Fire (and theoretically, Water — but be careful there, as .frameworks tend to break when copied to a Windows file system) can create such Import Projects *for* you, when you simply drag the .framework into your solution, or as a Reference into a Cocoa project. The same now works for .xcframeworks. Just drag them in, and Fire will create a [multi-target](https://docs.elementscompiler.com/EBuild/Projects/Targets/?ref=blogs.remobjects.com) Import Project for you, with targets for each SDK that the .xcframework supports, and for both Toffee and Island backends. When the Import Project gets built, EBuild will automatically pick the right .framework form inside the .xcframework folder structure for each target and build destination. ## Code-behind Generators On the .NET platform, *generators* are used to create .Designer.x files for Settings, Resources and — in Mercury — .myapp files. In the past, these generated .Designer files lived as part of the project, and had to manually updated when the file that drove their content changed. This is no longer the case. You can now *optionally* delete the .Designer.pas (.Designer.cs, etc) file form your project, and if you do, EBuild will automatically generate it from the .settings, .resx or .myapp file at *build* time and inject the result into the compile. On less source file to worry about, and you can be assured the .Designer code will always be up to date. Our .NET project templates have all been updated to reflect this new model, but your existing projects will not be affected, *unless* you explicitly opt in by deleting (or simply removing) the .Designer.x code file from your project. ## Optional Locking A very small change, but the Oxygene `locking` statement (and its equivalents in the other languages now accepts `nil` as a lock object, and *not* cause a lock in that case. This makes it very easy to write code that can *optionally* lock when a lock object is assigned, or not, if it is not. Background: the use case we added this for was EBuild itself. A while ago, we added support for parallel builds in EBuild — the option to build several projects, or sub-tasks of projects, in parallel , if their dependencies allow it (you can enable this in the IDE, or with the `--parallel` command line option). This required the addition of locks in a few places for thread safety, obviously, but on the flip side, these locks are just unnecessary overhead when running in (normal) non-parallel mode. This new compiler change made it very easy to *only* use the locks when running in parallel mode — without having to encode that decision in every single place the lock is required. EBuild simple assigns or clears its global lock object, depending on whether locking is needed. ## Uppercase Oxygene Keywords For those crazy ones among you who like their Oxygene code to YELL AT YOU, Fire and Water now expose an option to make it easier to have your keywords in uppercase. Simply switch the "Use upper-case Oxygene Keywords" option in Editor preferences,, and the editor will automatically uppercase keywords as you type them (similar to how it automatically PascalCases [Mercury](https://www.elementscompiler.com/elements/mercury/?ref=blogs.remobjects.com) keywords), and use uppercase for keyword completion (such as "`if`" adding "`then`"). ## And so much more... And as always, this is just the mere tip of the Eisberg. Check out the full [weekly build logs](https://www.remobjects.com/portal/downloads/elements?ref=blogs.remobjects.com) for for the complete list of changes. # ??