Behind the Build

"Behind The Build" is a new blog series where I will try to give some background information on some of the highlights of the weekly change log.

As you probably know, we ship a new build of Elements every Friday (come rain or shine, usually), and while each build comes with a detailed change log, sometimes the items can be cryptic and — oftentimes — some real gems can be hidden behind a trivial item.

In this series, i will try to give some insight into what these items mean to you, the user, and/or some background on what was interesting about implementing a given feature or fixing a given bug.

There won't be a post every week, necessarily, and the post might trail the actual release by a few days, depending on schedule and on how much there is to talk about that week.

So let's get on with it — Build .2577 (December 4, 2020)

Default Deployment Target to Local macOS Version

This is an interesting one, and fixes a small annoyance that has been biting me on and off over the past few months.

For macOS (and iOS etc) projects, the Deployment Target Version defines whats the lowest OS version that the project is supported to run on. Try to run your app on an older version, and you will get an error. By default, new projects from template have no Deployment Target set, which means your app will only run on the OS version of the SDK you built it against

That's fine, normally, but it is beta season, so over the past few months i often found myself in a situation where i was running a stable OS, but using the latest beta Xcode. For example, my work machine was Catalina (macOS 10.15), but i was using Xcode 12, which includes the macOS 11 SDK. Or right now, my new M1 MacBook Air runs the shipping macOS 11.0.1, but i'm using the Xcode 12.3 SDKs, which is version 11.1 for macOS.

So if i create a new project to test something out, and hit Build, it gets build for macOS 11.1 and — i can't run my own app!

As of this weeks build, when you build Mac projects (Toffee or Island) that has no Deployent Target Version, the build will use the version of the local Mac (this only works when building locally, not over CrossBox) as the default. You can see this reflected in the Project Settings view, as well:

C# 9.0 Features

Over the past few and next few releases, you will see us rolling out C# 9.0 features for RemObjects C#.

There's not much to say about this per se, aside from that this us keeping our C# dialect in sync with how Microsoft is evolving the language (You can track our progress here).

One thing I do want to point out is that many/most features Microsoft is adding to C# 9.0 (and moving forward) are tied to .NET Core 5.0, meaning they wont be available to developers sticking to the classic .NET 4.x runtime. They also largely aren't compatible with Visual Basic.NET™.

This is decidedly not the case for RemObjects C#. Where possible (i.e. not a feature tied to capabilities not supported on 4.x or relying on types new to 5.0), every feature we implement will be supported on .NET 2.0 and up, as well as the non-.NET platforms, of course. They will also be compatible with Mercury, and the other Elements languages of course (and where sensible and necessary, we'll add symmetric features there as well. For example, Mercury and Swift will get the Record keyword, and Oxygene & the rest will get support for it via an Aspect.