Kind of annoying, but at the end of the day it’s not the only way to have Docker working on a machine, even on other platforms, and this is what we’ll talk about today, with a mostly-step-by-step guide on how to set everything up.

And speaking of other platform, even if this article is mostly aimed at ARM64, most of this applies to regular x64 Windows too if you just want to avoid Docker Desktops’s license requirements.

Word of warning first though: the end result will not be 1:1 equivalent to what Docker Desktop gets you. No easy-to-use UI, everything will be CLI-based and mostly important it will not be possible to mount directories from the Windows filesystem as volumes. Both are minor annoyances (and irrelevant to me personally), but something to note about the volume limitation is that this one is really a non-issue, since performance would be abysmal anyway.

But that’s enough introduction, let’s get to the important stuff.

The general idea

In short, what we’ll be doing is to install and run Docker Engine inside a WSL distro and then use a feature called Docker Contexts to expose the engine to the Windows side via HTTPS, so that Windows tools can use it too (like Visual Studio Code’s Remote Development feature).

Prerequisites

WSL 2. That’s it. And git.

More specifically, at least version 1.0 which is only distributed via the Microsoft Store and which is compatible with either Windows 10 or 11.

That means that if you’ve installed the old non-Store version, you’ll need to switch to the Store release.

As the Store version is now the default, you can either install it via this store link or by just running wsl --install.

(By the way, if you haven’t installed Windows Terminal or PowerShell 7 it’s a good time to do so and set them as default).

Of course we’ll also need a Linux distribution to run Docker into. You can pick whatever you prefer, but since Ubuntu 22.04 is my distro of choice, this is what I will use for the rest of the article, and the only one I’ve tested so far.

Keep in mind though, the only distro that Docker officially supports on arm64 are CentOS, Debian, Fedora and Ubuntu.

Enabling systemd

After setting up the distro and configuring it to your liking, it’s time to make a choice: whether to enable systemd or not.

In my case I chose to do so for convenience, but it’s not mandatory. You will just need to manually start dockerd before using Docker.

This step is extremely easy: from WSL, just edit the /etc/wsl.conf file by adding these two lines:

[boot]
systemd=true

Save, quit your Linux distro, switch back to PowerShell, shut WSL down running wsl --shutdown and re-launch your distro.

This next boot will take slightly longer, but now commands like systemctl will work:

Installing Docker Engine

Now it’s time to actually install the engine. For this step you can refer to the official documentation for the most appropriate steps for your distro of choice.

Since I’m extremely lazy, I’ll just use the official install script by committing the cardinal sin of using curl | sh.

curl -sSL get.docker.com | sh

No, the irony of the install script recommending Docker Desktop is not lost on me.

Don’t forget to add your user to the docker group (sudo usermod -aG docker $(whoami))

Great, now we can run Docker locally inside WSL!

Building Windows tools

To use Docker from Windows we’ll need two tools: the Docker CLI itself and docker-compose.

The easiest way to get to get the CLI for windows/arm64 is to just build it locally, using Docker itself, reducing the dependencies required to zero.

Just clone the repo, cd into it and run one single command:

docker buildx bake --set binary.platform=windows/arm64

(of course, replace arm64 with amd64 if you’re on a regular x64 machine).

The build will take a couple minutes at maximum and leave a .exe in the build directory

We’ll need to move this binary somewhere accessible to Windows. What I like to do is to create a “tools” directory somewhere in C:\ and just add this folder to PATH. In this way, I can just drop any random tool I need there, as if it was /usr/local/bin or similar in any Linux distro.

Fortunately, we can access the Windows filesystem from inside WSL:

Then we can just use the System Properties dialog to edit the PATH with the new folder

Don’t forget to fully close Terminal and reopen it for the changes to apply.

Now that the CLI is in our PATH we can start configuring it to connect over to the engine running in WSL.

A word about security

At this point we could just setup the engine to expose its API over HTTP in addition to the usual UNIX socket, configure the Windows side and be done with it. It would already work.

Enabling HTTP as-is though will mean that everyone on the network will be able to call the engine running in our distro, and unless you’ve enabled rootless docker that would imply giving everyone on your network root access to your WSL distro, and by extension give them the ability to run any arbitrary piece of code on the Windows side, by abusing the interop feature.

Not even binding to localhost only is safe, as that would give root access to any malicious script running in your browser!

Sounds like a bad idea? It is. Big time.

This is why in the next step we’ll deal with this aspect of the setup, with TLS certificates. We’ll create a local Certification Authority, and then use this CA to create two certificates: one for the engine (so that the CLI can authenticate it) and another client certificate for the CLI itself.

Then we’ll configure the engine to only accept connections from clients using credentials signed by our CA, making the entire setup as secure as possible.

(If you’re wondering why we need HTTP at all, contrary to WSL 1 AF_UNIX sockets are not supported on WSL2, which gives us no other choice.)

Generating all certificates

This part will be based upon the official Docker docs.

We’ll use openssl, which should be already installed (at least, it is on Ubuntu 22.04 I’m using).

The CA

First step is generating the CA key:

openssl genrsa -aes256 -out ca-key.pem 4096

and then its certificate

openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

All fields are optional, but make sure to use localhost as FQDN.

The Server

Now that we have a CA, we can generate a key for our server (the Docker daemon)

openssl genrsa -out server-key.pem 4096

And then a Certificate Signing Request

openssl req -subj "/CN=localhost" -sha256 -new -key server-key.pem -out server.csr

A CSR is basically us asking a CA to cross-sign the public key for the certificate we just generated ourselves, never sending the private key to anyone else. In this case the CA is under our control and its key is actually sitting next to the server key, but it may not always be the case.

To cross-sign the key, we’ll need to create a file with this content (I’ll call it extfile.cnf just like the docs do)

subjectAltName = DNS:localhost
extendedKeyUsage = serverAuth

And now generate the certificate

openssl x509 -req -days 365 -sha256 -in server.csr\
  -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem \
  -extfile extfile.cnf

The Client

The last piece of the puzzle is the certificate we’ll use to authenticate the Windows-side CLI, the client.

For simplicity we’ll perform this step on WSL too and then copy all the required files over to Windows.

The process is similar to the previous two, first we generate a key

openssl genrsa -out client-key.pem 4096

Then generate a CSR

openssl req -subj '/CN=client' -new -key client-key.pem -out client.csr

Then create the configuration file (extfile-client.cnf)

extendedKeyUsage = clientAuth

Last step, generate and sign the certificate itself

openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem \
  -CAkey ca-key.pem -CAcreateserial -out client-cert.pem \
  -extfile extfile-client.cnf

Cleanup

Now that we have our keys and certificates for CA, daemon and CLI we can delete the configuration and CSR files

rm extfile.cnf extfile-client.cnf client.csr server.csr

To protect the private keys, we’ll need to change their permissions

chmod 0400 ca-key.pem client-key.pem server-key.pem

And then update the public keys to be world-readable

chmod 0444 ca.pem server-cert.pem client-cert.pem

Configure Docker Engine to use HTTPS with TLS

This step is different whether you use Systemd to manage the engine or not. If not, the only difference from just launching dockerd is that you’ll need to pass a few args with the paths of the certs.

In my case I moved certs and keys to /opt/docker-certs for convenience.

sudo dockerd \
  --tlsverify \
  --tlscacert=/opt/docker-certs/ca.pem \
  --tlscert=/opt/docker-certs/server-cert.pem \
  --tlskey=/opt/docker-certs/server-key.pem \
  -H=0.0.0.0:2376 \
  -H=unix///var/run/docker.sock

With systemd we’ll need to edit its unit which is usually located at /lib/systemd/system/docker.service and add the same arguments to the ExecStart line.

run systemctl daemon-reload to reload the unit file, systemctl restart docker to restart the service and voila, the daemon will be running with the new settings.

Configure a Docker Context on the Windows Side

Now it’s time to setup the last part, the Windows-side CLI.

First of all, we’ll need to copy the CA certificate, the client certificate and the client key over to the Windows filesystem. This is easy with the interop feature in WSL

mkdir /mnt/c/docker-certs
cp ca.pem /mnt/c/docker-certs
cp client-cert.pem /mnt/c/docker-certs
cp client-key.pem /mnt/c/docker-certs

Create the context

docker context create wsl --docker "host=tcp://localhost:2376,ca=c:/docker-certs/ca.pem,cert=c:/docker-certs/client-cert.pem,key=c:/docker-certs/client-key.pem"

and finally enable it

docker context use wsl

And we’re done!

It’s frustrating when you onboard a project just to discover that there is absolutely no guidance about how to setup your machine to actually start working on it. And it’s equally frustrating when the documentation exists but either it’s not actively maintained, obsolete or maybe just too specific to someone else’s preferences, leaving you to troubleshoot any issues you’ll encounter while trying to bring everything up.

That’s even before everyone’s environment starts diverging or even “rot”. That’s a completely different kettle of fish.

For this reason, containerization technologies have increasingly become a staple of local environments. Instead of installing a database engine on your machine to share across different codebases, you can spin up a container just for the one you’re working on.

Need different versions? Just update the image. Oh, we’re switching to Postgres? Just pull the new one. You completely busted something and want to start from a clean state?

Just create a new one. What would have been an entire day lost reinstalling your machine, is now a sub-30 seconds command.

Downsides

Containers are useful but not perfect. Unless you plan to work entirely in vim inside the container (or emacs, for people who prefer it), you’re still going to need an editor that is installed locally on your machine and some way to share code and other data between the host machine for your editor to consume and the container.

This is, to put it lightly, less than optimal in many cases, file sharing in Docker for macOS and Windows is notoriously slow. There are ways to alleviate it but you can’t completely work around it, and it’s also something that’s going to aggravate the setup steps outlined in your docs, ultimately making it longer, more error-prone and difficult to maintain.

You will also need other tooling outside of your container, to some degree, like linters, static analyzers and other things that are going to work within your editor or IDE to give you the modern developer experience you’d expect today.

And this is where Visual Studio Code’s Remote Development extensions come into the picture.

Remote Development extensions

This is a set of extensions for the editor that let you work with codebases that are not on your local machine, but rather on different machines.

It might not seem to be something particularly new, tons of editors in the past have supported something like that, but they often worked by passing files back and forth between the local and remote machines using tecnologies like FTP or (hopefully) SFTP.

Visual Studio Code goes one step further: it connects to the machine, downloads and runs a headless version of the editor and then connects to it.

I also like how it treats other installed extensions: some of them are installed locally, like themes, others like language servers are installed remotely, and then there are API that extensions can leverage to work across both environments.

There are three extensions in the pack, for three different technologies:

• One lets you connect to other machines via SSH (and even supports ARMv7 and Arch64, which means working with headless SBCs like the Raspberry Pi is a breeze).

• Another one is for WSL (Windows Subsystem for Linux), and basically does what it says. This is particularly nice on Windows because it means you can keep the source code on the Linux side of WSL, avoiding the cross-VM file sharing performance hit we talked about earlier. And the UI itself renders natively on the Windows side, avoiding all the issues you would have got by installing (a separate copy of) Visual Studio Code on Linux and then using a Windows X11 server like VcXsrv or X410 to have it running on screen. A nice touch is that installing VSCode in Windows automatically adds a code command in WSL, which will let you run VSCode-on-WSL from a WSL shell like you would do in native Linux. It’s one of the little things that makes the experience less jarring than it otherwise would have been.

• But the main star of the show is the Docker-specific extension. Like the other two, it’s pretty straightforward: it spins up a container, copies the headless server into it, runs it and connects to it. The best part is that everything required to know including what image to use, what ports to expose, which environment variables to set etc is all defined in a JSON file, which can then be checked in your source control repository.

Long story short, the documentation for your local environment would then boil down to:

1. Install Visual Studio Code
2. Install the Remote Development Extensions Pack

Then, when you open a workspace that has been setup you’ll get a prompt like this:

Click “Reopen in Container” and a couple of minutes later you’ll be off to the races.

That’s just for the repo, how about the rest?

Setting up a local development environment is of course more than that, but since reading about something can be very boring (and I know I am), maybe it’s better to show you how to actually use it.

For this example, we’ll start with a .NET 5.0 web application. Nothing fancy, it’s just an app that exposes some REST API, a Swagger UI frontend, uses Postgres as its main database, a couple of S3 buckets and Redis for caching.

This is our starting point. We won’t go into the actual app code (also because I’m cheating and the code is just what comes out of scaffolding) but notice we also have an .editorconfig file there to define a styleguide.

Normally this would require the developer to manually install the EditorConfig extensions for this to be actually useful, but just keep this in the back of your mind for now.

Noticed the green button in the lower left corner of the window? That’s the sign at least one of the Remote Development extensions is installed.

The first step will be to create the JSON with all the container settings. We have two options: it can either be in the root (named .devcontainer.json) or inside a separate directory (.devcontainer/devcontainer.json in this case).

We’ll go for the separate directory route and place this inside the file:

{
    "image": "mcr.microsoft.com/dotnet/sdk:5.0-alpine"
}

Just the image name for now. Now invoke the Command palette (F1 or Ctrl/Cmd + Shift + P) and select “Remote-Containers: Reopen in container” and wait (you can also find this command clicking on the button in the lower left corner).

A couple of seconds or minutes later, we’ll be greeted by a similar-looking window, the only noticeable difference will be the “Dev Container” string inside the lower left corner button.

But opening any of the .cs file will make this notification appear:

That’s because the headless instance has no extensions installed, you can also notice it from the left sidebar, which has a lot less icons compared to the previous screenshot.

Of course, we could install it by clicking on the button and call it a day, but we would be required to do so every time we rebuild the container.

Kind of defeats the purpose of making things simpler, doesn’t it?

Luckily, the JSON files comes to help once again: we can list there the extensions we want to use, and it will automatically install them at build time. Since we’re using EditorConfig, we can also add its extension there too!

The JSON files now becomes like this:

{
    "image": "mcr.microsoft.com/dotnet/sdk:5.0-alpine",
    "extensions": [
        "ms-dotnettools.csharp",
        "editorconfig.editorconfig"
    ]
}

You can add any extension there, and you can find the IDs for each one from its details page in the Extensions section:

After invoking the “Rebuild container” command from the Palette and waiting a couple of minutes we’ll see this:

Notice how the C# Extension is installing its dependencies. That’s because the main extension was already preinstalled during bring-up and we’re greeted by its first-launch dependency installation. Also notice that we’re installing the Linux dependencies even if this screenshot was taken on Windows.

Dockerfiles

But we’re not done here! Sometimes it might be enough to start from an image (either a public one or some developer image that’s maintained internally), but it also might be useful to personalize this image.

Of course the extension supports this too, we just need to define a Dockerfile inside of our .devcontainer directory and change our JSON to use it instead of the prebuilt image.

Let’s suppose we want to install the dotnet-format tool, that automatically checks and formats your code according to the EditorConfig rules:

What we need is a Dockerfile like this:

FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine

# This is needed for Global Tools to work
ENV PATH="${PATH}:/root/.dotnet/tools"
# Install .NET Global Tools
RUN dotnet tool install -g dotnet-format

and also to change our JSON like this (I also threw in the Docker extensions):

{
    "dockerFile": "Dockerfile",
    "extensions": [
        "ms-dotnettools.csharp",
        "editorconfig.editorconfig",
        "ms-azuretools.vscode-docker"
    ]
}

And now we can:

• Edit the source code, with all the bells and whistles like IntelliSende, code navigation, smart refactorings etc.
• EditorConfig integration in the editor
• Use the CLI to autoformat the code according to the styleguide

Of course this can be used to install anything you might need. The JSON also offers some fields where you can define commands to be run at certain stages, like before/after building the container, after starting it etc.

For example, you could use postCreateCommand to run a script that configures LocalStack using the same templates you would use to define your infrastructure on the real AWS, using awscli-local. In our example, we would use it to create (and maybe seed) the S3 buckets the app uses, the database etc.

Talking about LocalStack, S3 buckets and databases, our sample app uses all of them. Are we supposed to install everything inside the container?

Of course not. Docker Compose is supported too!

This makes our JSON slightly more complicated now, since we have to tell the extension something that in the previous sample was automatically configured by itself.

{
    "dockerComposeFile": "docker-compose.yml",
    "service": "devcontainer",
    "shutdownAction": "stopCompose",
    "workspaceFolder": "/workspace",
    "extensions": [
        "ms-dotnettools.csharp",
        "editorconfig.editorconfig",
        "ms-azuretools.vscode-docker"
    ]
}

Now the dockerFile field has been replaced by dockerComposeFile, we have to specify which of the services defined inside the YAML is the one vscode-server will be launched from, what to do when shutting down and most importantly which workspace to open since now it will be our responsibility to mount the correct folder inside the workspace.

(just a sidenote, override files are supported too)

In our case, the docker-compose.yml we’ll put inside the .devcontainer directory will be similar to this:

version: '3'
services:
  devcontainer:
    build: .
    environment:
      - LOCALSTACK_HOST=localstack
      - CONNECTIONSTRINGS__REDIS=redis
      - CONNECTIONSTRINGS__POSTGRES=Host=postgres;Username=postgres;Password=MySecretPassword
    volumes:
      - ..:/workspace
      - ./persistence/nuget:/root/.nuget
      - /var/run/docker.sock:/var/run/docker.sock
    command: sleep infinity
    ports:
      - 5000:5000
      - 5001:5001
  localstack:
    image: localstack/localstack
    environment: 
      - SERVICES=s3
      - DATA_DIR=/tmp/localstack/data
    volumes:
      - ./persistence/localstack:/tmp/localstack
  redis:
    image: redis:5.0.6-alpine
  postgres:
    image: postgres:12
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=MySecretPassword
      - PGDATA=/pgdata
    ports:
      - 5432:5432
    volumes:
      - ./persistence/postgres:/pgdata

There is A TON to unpack here.

For starters, we’re now defining four containers. One is the “devcontainer” we’ve worked with until now, but we’ll come back to that later.

We’ll start with the redis service, which just defines which image to use. Since all containers are on the same virtual network, it means that if we installed the redis-tools package inside our main container, we’ll be able to connect to it using the redis hostname.

Then we have postgres which is a little more complicated: in addition to the image we also define some required environment variables for the default username and password to use. We also move the PGDATA into a different location, that’s mounted externally in order to maintain persistence of its data. This way, if we rebuild the container we won’t lose all the data in the database. Its port is exposed externally, so we can use local tools to connect to it if there’s the need.

The same thing is done with LocalStack (you can find more info about its environment variables in its own documentation), but there too we used an external volume to avoid losing data upon rebuilds.

And then we have our devcontainer. Of course this one doesn’t define an image to use, rather builds it from our old Dockerfile.

Some of its configuration is required for everything to work, specifically the first volume that’s defined there, its purpose is to mount the real workspace inside the container, something that up until now was done automatically by the extension (it’s the same path we put in the JSON). More importantly we also have to override its command, otherwise the container would have exited immediately after starting. This is an easy way to keep it running indefinitely.

I also added a volume mounting the Docker socket: after doing this we can just install the Docker tools inside the container, allowing us to interact with our machine’s docker installation. It’s pretty useful if you don’t want to jump to a separate terminal when you need to build images for example.

Also notice the environment variables: the first one contains the hostname for the LocalStack container, which we can use at runtime on our application to detect whether we should use the real S3 or rather change the service endpoint URL to the LocalStack one.

The other two instead contain connection strings for Redis and Postgres in the format .NET Core expects which means that we can use our YAML to seamlessly override configuration keys only when running inside a devcontainer.

Conclusions

If I might seem enthusiastic about this feature it’s because I am: it opens so many scenarios and solves so many problems that it’s hard not to use it.

And this is exactly what we’re doing internally, authoring standard developer images and templates to rollout across projects.

We first tested it out in one of our .NET projects while it was still in preview and we immediately saw its advantages for making onboards easier, and how it made sharing samples and experiments much easier as part of our tech Fridays. Or it might make it simpler to setup a lab for an internal workshop.

If you want to learn even more you can head to the official docs which also describes more advanced scenarios like Docker over SSH.

This article also appeared on TUI Musement’s tech blog.

Its use is trivial, just assign any property like you would do on the “real” control, like this:

UITextfield.appearance.backgroundColor = UIColor.grayColor;

But what if we have more complex, custom properties?

Objective-C has as an interesting feature called “categories” that basically lets you extend classes outside of your control adding methods (and properties), implementing protocols etc. Swift of course has extensions, but for the purposes of this post we’re going to focus on Objective-C categories.

If you wanted to add a placeholderTextColor property on a UIText field, you just need to define a category like this:

@interface UITextField (Placeholder)

@property UIColor* placeholderTextColor;

@end

@implementation UITextField (Placeholder)

-(UIColor*)placeholderTextColor {
    // omitted for brevity
}

-(void)setPlaceholderTextColor:(UIColor*)placeholderTextColor {
    // omitted for brevity
}

@end

and then use it as any other property:

UITextField someField = ...;
someField.placeholderTextColor = UIColor.grayColor;

Objective-C even lets you use it in UIAppearance:

UITextField.appearance.placeholderTextColor = UIColor.purpleColor;

If all this looks familiar, it’s probably because C# has a similar feature called Extension Methods that has a similar purpose, albeit a bit limited compared to the Objective-C counterpart (you can just add methods).

Extending native controls with Extension Methods.

Our PlaceholderTextColor sample above would be written like this:

public static class UITextFieldPlaceholderTextColorExtensions
{
    public static UIColor PlaceholderTextColor(this UITextField self)
    {
        var attributeName = UIStringAttributeKey.ForegroundColor;
        var color = self.AttributedPlaceholder.GetAttribute(attributeName, 0, out _);
        return (UIColor) color;
    }

    public static void SetPlaceholderTextColor(this UITextField self, UIColor placeholderTextColor)
    {
        if (self.AttributedPlaceholder is null)
        {
            if (self.Placeholder is null)
            {
                // Neither Placeholder nor AttributedPlaceholder are set
                // nothing to do
                return;
            }

            // We've got a plain Placeholder, apply the right attribute and set
            // it as AttributedPlaceHolder
            self.AttributedPlaceholder = new NSAttributedString(self.Placeholder,
                new NSDictionary(UIStringAttributeKey.ForegroundColor, placeholderTextColor));
        }
        else // An AttributedPlaceholder is already set
        {
            var attributedString = new NSMutableAttributedString(self.AttributedPlaceholder);

            // When passed a null UIColor we remove the attribute
            if (placeholderTextColor is null)
            {
                attributedString.RemoveAttribute(UIStringAttributeKey.ForegroundColor,
                    new NSRange(0, self.AttributedPlaceholder.Length));
            }
            else
            {
                attributedString.SetAttributes(
                    new NSDictionary(UIStringAttributeKey.ForegroundColor, placeholderTextColor),
                    new NSRange(0, self.AttributedPlaceholder.Length));
            }

            self.AttributedPlaceholder = attributedString;
        }
    }
}

This lets us set a color for the Placeholder text like this:

var someField = ...;
someField.SetPlaceHolderTextColor(UIColor.Gray);

Sorry, no nice property syntax with extension methods (yet).

Sadly Extension Methods are not (automatically) exposed to Objective-C, and of course the Xamarin bindings for the UIAppearance-derived classes have no idea about our extension methods!

But yet, we still want to fully take advantage to UIAppearance, after all one of the biggest reasons to use Xamarin is that it gives you full access to all the native features!

Enter the CategoryAttribute.

Exporting extension methods as categories

CategoryAttribute lets you export a static class containing extension methods as a category for an Objective-C class to its runtime, basically letting you write categories using C#. All we need to do is decorate the class with the attribute, passing the type of the class we want to extend:

[Category(typeof(UITextField))]
public static class UITextFieldPlaceholderTextColorExtensions
{
    ...
}

Please note that if you use the category only from Objective-C world and never from managed C# code, it may get removed by the linker! One way to avoid it is to apply the PreserveAttribute to the class. It’s not our case, but it’s something to keep in mind.

Exporting the category is just part of the story though. We also need to export the two extension methods using the usual ExportAttribute:

[Category(typeof(UITextField))]
public static class UITextFieldPlaceholderTextColorExtensions
{
    [Export("placeholderTextColor")]
    public static UIColor PlaceholderTextColor(this UITextField self)
    {
        ...
    }

    [Export("setPlaceholderTextColor:")]
    public static void SetPlaceholderTextColor(this UITextField self, UIColor placeholderTextColor)
    {
        ...
    }
}

Note the colon at the end of the setter’s selector, it means the method accepts one single parameter (and it’s required).

This won’t change anything from the C# on-the-spot usage point of view, but makes it possible for UIAppearance to set a default for that property. The problem is, as we said earlier, UIAppearance bindings have no idea our extension/category exists, so this code simply won’t compile:

UITextField.Appearance.SetPlaceholderTextColor(UIColor.Brown);

Wiring our extension to UIAppearance

Objective-C is a message-passing-based environment. It’s quite dynamic and classes can dynamically support any property, not unlike C#’s Reflection APIs. The way Objective-C does it is via “selectors”, which are objects that describe a message (roughly equivalent to .NET’s MethodInfo class).

var selector = new Selector("setPlaceholderTextColor:");
UITextField.Appearance.PerformSelector(selector, UIColor.Brown);

Note the parameter to the Selector constructor is the same as the one passed in the setter’s Export attribute.

We can use the same approach to call the getter:

var selector = new Selector("placeholderTextColor");
var color = UITextField.Appearance.PerformSelector(selector) as UIColor;

Of course having to type a literal string everythime is less than ideal. One way to encapsulate everything nicely is to write two extension methods for UITextFieldAppearance:

private static readonly Selector PlaceholderTextColorSetter = new Selector("setPlaceholderTextColor:");

public static void SetPlaceholderTextColor(this UITextField.UITextFieldAppearance self,
    UIColor placeholderTextColor)
{
    self.PerformSelector(PlaceholderTextColorSetter, placeholderTextColor);
}

Putting it all together

In this Gist you can find the complete code for the category and the extensions, hope you’ll find it useful!

As Ryan puts it:

UIDebuggingInformationOverlay is a private UIWindow subclass created by Apple, presumably to help developers and designers debug Apple’s own iOS apps.

The post also has code for using it in your Swift apps, but what if you’d want to use it in your Xamarin apps?

Turns out it’s quite easy, let’s see what Ryan’s code does step-by-step:

let overlayClass = NSClassFromString("UIDebuggingInformationOverlay") as? UIWindow.Type

This gets us the UIDebuggingInformationOverlay’s class object, the equivalent of a Type object in C#.

Next, he proceeds calling a static method, prepareDebuggingOverlay, using a selector:

_ = overlayClass?.perform(NSSelectorFromString("prepareDebuggingOverlay"))

We need to call this method, otherwise the overlay will be empty. Now we can just get a reference to the overlay itself, calling the overlay static method:

let overlay = overlayClass?.perform(NSSelectorFromString("overlay"))
                           .takeUnretainedValue() as? UIWindow

At this point showing the overlay is as simple as calling toggleVisibility:

_ = overlay?.perform(NSSelectorFromString("toggleVisibility"))

And that’s it!

It’s C# time

Now, let’s do it with Xamarin!

The first step is to get an handle to the native Objective-C class. Luckily, Xamarin provides a method just for that:

var overlayClass = Class.GetHandle("UIDebuggingInformationOverlay");

overlayClass is a IntPtr object since it’s a pointer to an underlying native object.

Now we need to call prepareDebuggingOverlay, but how? We have just an opaque pointer!

DllImport to the rescue

We must do it like how the Objective-C runtime does: we must send a message to the object, using the native objc_msgSend function. Since that’s a C function we can just use P/Invoke.

We don’t need any arguments, so we can import the most basic version of it:

[DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSend")]
static extern IntPtr objc_msgSend(IntPtr target, IntPtr selector);

and then just call it:

objc_msgSend(overlayClass, new Selector("prepareDebuggingOverlay").Handle);

we can now reuse this function for the next step, getting a reference to the overlay:

var overlay = objc_msgSend(overlayClass, new Selector("overlay").Handle);

and also for toggling it:

objc_msgSend(ovrlay, new Selector("toggleVisibility").Handle);

And we’re done! We should now see the debugging overlay over our app!

Let’s clean it up

I like my code to be well contained within its own class, I wouldn’t use this code as is, so I encapsulated all of it in a simple wrapper:

using System;
using System.Runtime.InteropServices;
using ObjCRuntime;

namespace debugoverlay
{
    public class UIDebuggingInformationOverlay
    {
        [DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSend")]
        static extern IntPtr objc_msgSend(IntPtr target, IntPtr selector);

        static IntPtr _overlayClass = Class.GetHandle("UIDebuggingInformationOverlay");
        static Selector _prepareSelector = new Selector("prepareDebuggingOverlay");
        static Selector _overlaySelector = new Selector("overlay");
        static Selector _toggleSelector = new Selector("toggleVisibility");

        IntPtr _overlay;

        public static void PrepareDebuggingOverlay()
        {
            objc_msgSend(_overlayClass, _prepareSelector.Handle);
        }

        public UIDebuggingInformationOverlay()
        {
            _overlay = objc_msgSend(_overlayClass, _overlaySelector.Handle);
        }

        public void ToggleVisibility()
        {
            objc_msgSend(_overlay, _toggleSelector.Handle);
        }
    }
}

It may need another bit of polishing (like making it a proper NSObject binding), but for debugging purposes it’s good enough. Feel free to use it!

Wrap-up

I’ll try to come up with a better version of the wrapper just for the sake of learning a bit more about C#/Objective-C bindings, if you have some advice feel free to reach out!

UPDATE 7 July 2017: The binding code is now on GitHub and on NuGet.