The project I’m working on is in a maturing state. This means it needs to remain stable while still delivering new features. This is where feature toggles come into play. By adding these toggles and conditional execution paths to your code, you can keep the functionality unchanged until you turn a toggle on and then return to the previous behavior by turning it off again.

In the Azure ecosystem, we have the App Configuration resource with fairly basic feature toggle capabilities, so that’s what I’m using because it fits our current needs.

Setup in Aspire

For ease of local development, we use Aspire. To enable App Configuration, you’ll need the Aspire.Hosting.Azure.AppConfiguration package.
This lets you add a new resource to the AppHost: var appConfig = builder.AddAzureAppConfiguration("config");.

On your local machine, you probably don’t want to use an actual Azure resource, but an emulator. This can be configured using these lines of code:

appConfig.RunAsEmulator(emulator =>
{
    emulator.WithLifetime(ContainerLifetime.Persistent);
    emulator.WithDataVolume();
});

This works like a charm on Windows.
If you’re on Apple Silicon, like I am, it won’t.

Get the App Configuration emulator to work on Apple Silicon

When you start the AppHost with the emulator configured, you’ll see something like this in the logs:

[sys] Could not create the container: ContainerName = config-f2b35acd:
[sys] docker command 'InspectContainers' returned with non-zero exit code 1
[sys] object not found
[sys] container not found
[sys] Error response from daemon: No such container: config-f2b35acd
[sys] not all requested objects were returned
[sys] only 0 out of 1 containers were successfully inspected
[sys] docker command 'CreateContainer' returned with non-zero exit code 1
[sys] error
[sys] Unable to find image 'mcr.microsoft.com/azure-app-configuration/app-configuration-emulator:1.0.2' locally
[sys] error
[sys] 1.0.2: Pulling from azure-app-configuration/app-configuration-emulator
[sys] error
[sys] no matching manifest for linux/arm64/v8 in the manifest list entries

Turns out there’s no image that’s compatible with Apple’s M-series processors.

There are a couple of ways to work around this issue. You could host the emulator yourself in a separate process and point your configuration to it, or emulate a different processor architecture in Docker. I don’t like either option, because I want my Aspire workflow to be seamless without having to think about additional steps in my development.

What I did instead was build the correct image myself!
The App Configuration repository can be found on GitHub: https://github.com/Azure/AppConfiguration-Emulator.

If you clone this repository, you can compile, publish, and build the image, which is what I did. Of course, you won’t be able to push the image to the mcr.microsoft.com registry, but that’s not a problem. Docker will first search for the image on your local machine. Here’s the script I used to make the correct image available locally:

# 1. Publish the emulator host project
echo "Publishing emulator host project..."
dotnet publish src/Azure.AppConfiguration.Emulator.Host/Azure.AppConfiguration.Emulator.Host.csproj \
  -c Release -o publish

# 2. Build the Docker image
echo "Building emulator image..."
docker build -t appconfig-emulator-local:1.0.2 .

# 3. Tag it with the name Aspire expects
echo "Tagging image as: mcr.microsoft.com/azure-app-configuration/app-configuration-emulator:1.0.2"
docker tag appconfig-emulator-local:1.0.2 \
  mcr.microsoft.com/azure-app-configuration/app-configuration-emulator:1.0.2

# 4. Verify
echo "Verifying target image is available locally..."
docker image inspect mcr.microsoft.com/azure-app-configuration/app-configuration-emulator:1.0.2 \
  --format 'Architecture={{.Architecture}} OS={{.Os}}'

echo "Done. Aspire can now use local image."

Next steps

With the image available locally and tagged the way Aspire expects, you can run the Aspire workload and use the emulator as expected. It’s working well on my machine. There’s also a GitHub issue addressing this concern, but the repository isn’t very active, so I’m not sure whether this will be resolved in the official registry any time soon.
At least you are able to work with the emulator from an Aspire perspective, just like your peers that work on a Windows machine.