Iris Classon - In Love with Code

Error CompileAppManifest Task Failed Unexpectedly

Tue, 07 Apr 2026 12:00:00 +0200

Iris Classon - In Love with Code https://www.irisclasson.com/2026/04/07/error-compileappmanifest-task-failed-unexpectedly/ -

Hope you’ve had a lovely Easter! I caught the flu the week before, and am still recovering. Flu plus Easter = I was away for over a week. Which means by the time I came back and did a pull there had been quite a few changes in the work code base. After staring at the screen for two hours running various updates I finally got around to attempting a build, but got the following error:

Xamarin.Shared.targets(614,3): Error
MSB4018 : The "CompileAppManifest" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
 at Xamarin.MacDev.Tasks.CompileAppManifest.SetXcodeValues(PDictionary plist, IAppleSdk currentSDK) in /Users/builder/azdo/_work/1/s/macios/msbuild/Xamarin.MacDev.Tasks/Tasks/CompileAppManifest.cs:line 534
 at Xamarin.MacDev.Tasks.CompileAppManifest.Compile(PDictionary plist) in /Users/builder/azdo/_work/1/s/macios/msbuild/Xamarin.MacDev.Tasks/Tasks/CompileAppManifest.cs:line 338
 at Xamarin.MacDev.Tasks.CompileAppManifest.Execute() in /Users/builder/azdo/_work/1/s/macios/msbuild/Xamarin.MacDev.Tasks/Tasks/CompileAppManifest.cs:line 166
 at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
 at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(TaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

If you come across this, take a closer look at the error.

The null reference exception is in the SetXcodeValues method, which usually means you have a SDK mismatch. For me it was simply a missing workload update since I was updating my environment:

dotnet workload update

If you get this error, make sure you have the right Xcode version for the MAUI version you are using.

Hope this helps!

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/04/07/error-compileappmanifest-task-failed-unexpectedly/ -

Fourth Edition: A History of .NET Web Development

Tue, 31 Mar 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/03/31/fourth-edition-a-history-of-.net-web-development/ -

The fourth edition of my .NET web development history book is out today.

https://leanpub.com/historyofnetwebdevelopment-4thed

Since its inception in the early 2000s, the .NET web development platform has evolved significantly. Each release has introduced new capabilities, reshaped best practices, and responded to changing demands in how we build applications.

Understanding that evolution helps make sense of where the platform is today and where it is heading.

In this fourth edition, we follow the journey of .NET web development from its early foundations through to the modern ecosystem. We cover the shifts toward cloud-native architecture, improvements in performance and developer experience, and the growing role of AI-related abstractions in .NET 9, along with the continued refinements and simplifications introduced in .NET 10.

If you’ve read a previous edition, this one picks up where it left off and brings the story up to date. If this is your first time, it starts from the beginning and covers the full arc.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/03/31/fourth-edition-a-history-of-.net-web-development/ -

GitHub Copilot Model Training

Sun, 29 Mar 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/03/29/github-copilot-model-training/ -

A little reminder for those of you who haven’t logged in to GitHub for a while! On April 24th, GitHub Copilot will be using interaction data to train their model.

Important update On April 24 we’ll start using GitHub Copilot interaction data for AI model training unless you opt out. Review this update and manage your preferences in your GitHub account settings.

You can change the setting here: https://github.com/settings/copilot/features

Scroll down to privacy and choose to disable to opt out, if that’s your preference.

More data, and data from real usage, equals smarter models and better replies as they explain in the announcement blog post: https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/

But it’s equally important to let people opt out and make that option easy to find. Worth noting that interaction data from Copilot Business, Copilot Enterprise, or enterprise-owned repositories are not used.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/03/29/github-copilot-model-training/ -

Expired Azure Credentials in GitHub Actions

Thu, 26 Mar 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/03/26/expired-azure-credentials-in-github-actions/ -

If your GitHub Actions workflow suddenly starts failing with an error like:

AADSTS7000222: The provided client secret keys are expired

it usually means your Azure service principal secret has expired and needs to be rotated.

Here is a quick guide to updating your Azure credentials and getting your pipeline working again.

The Azure credentials format

In many GitHub workflows, Azure authentication is stored as a JSON secret (often called AZURE_CREDENTIALS):

{
 "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
 "clientSecret": "your-secret-value",
 "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
 "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Each field maps directly to values in Azure. Where do you find these?

Client ID is the same as Application ID
Client secret is the value of the secret you create
Subscription ID: Azure portal → Subscriptions → select your subscription
Tenant ID is the same as Directory ID

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/03/26/expired-azure-credentials-in-github-actions/ -

Bluetooth Log Distance Path Loss Calculation

Tue, 03 Mar 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/03/03/bluetooth-log-distance-path-loss-calculation/ -

I realize I didn’t show the calculation in the previous blog post. That was partly intentional as it’s not a good idea. Even more so indoors, where you have more surfaces and obstacles.

But, here it is, the C# implementation:

public double? EstimateDistanceMeters(double txPowerAt1Meter = -59, double pathLossExponent = 2.4)
{
 // _ema is the smoothed RSSI discussed in the previous blog post
 if (!_emaRssi.HasValue)
 return null;

 return Math.Pow(10.0, (txPowerAt1Meter - _emaRssi.Value) / (10.0 * pathLossExponent));
}

The path loss exponent describes how fast signal drops — approximately 2 in open space, and 2.2–2.4 indoors.

The value -59 for txPowerAt1Meter is a convention, not a law of physics. It comes from BLE beacon practice, especially Apple’s iBeacon spec, where manufacturers often define RSSI at 1 meter as approximately -59 dBm. So developers started using -59 as a default when they don’t have a calibrated value, and many devices ship with that as their default.

Calibration, which I talked about in the previous post, would be a better way to get a more accurate value for the txPowerAt1Meter parameter.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/03/03/bluetooth-log-distance-path-loss-calculation/ -

File-Based Apps in .NET 10

Sun, 01 Mar 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/03/01/file-based-apps-in-.net-10/ -

One of my favourite improvements in recent .NET versions, and something that feels properly usable in .NET 10, is file-based apps. You can create a single .cs file and run it directly. No project file, no solution, no folder structure, just code.

dotnet run hello.cs

That’s it.

What it looks like

A minimal file-based app is just a .cs file with top-level statements:

var name = args.FirstOrDefault() ?? "world";
Console.WriteLine($"Hello, {name}!");

Save it as hello.cs, run dotnet run hello.cs, and you are done.

If you need a NuGet package, you can reference it at the top of the file. For example, using System.CommandLine to handle arguments:

#:package System.CommandLine@2.0.0

using System.CommandLine;

var nameOption = new Option<string>("--name", () => "world");

var root = new RootCommand
{
 nameOption
};

root.SetHandler((name) =>
{
 Console.WriteLine($"Hello, {name}!");
}, nameOption);

await root.InvokeAsync(args);

There is no .csproj to manage and no explicit restore step. The tooling takes care of it in the background.

Why it matters

C# has always been a strong choice for small tools and automation, but the setup got in the way. Before writing any actual logic, you had already created a project, picked a template, and committed to a structure.

Languages like Python and JavaScript never had that overhead. A script is just a file. You write it and run it.

File-based apps move C# much closer to that experience. It becomes practical to reach for C# for quick scripts, small utilities, or experiments without switching languages or setting up a project. That lowers the barrier both for experienced developers who want speed and for beginners who just want to try something without understanding the full project system first.

Key benefits include

Reduced boilerplate for simple applications You can go from idea to running code without scaffolding a project. For small utilities, that removes most of the friction that used to come before the actual work.

Self-contained source files with embedded configuration Dependencies and basic configuration can live alongside your code. That makes the file portable and easier to share, since everything you need is defined in one place.

Works well with modern publishing options File-based apps fit naturally with things like single-file publishing and Native AOT. If you decide a script should become something you distribute, you are already close to a publishable shape.

Easy path to CLI tools A small script can evolve into a proper command-line tool without a big rewrite. You can start simple and grow into a more structured project when it makes sense, instead of committing upfront.

When to use it

This is not a replacement for regular projects. As soon as you need multiple files, tests, or anything resembling real application structure, you still want a project.

But for automation scripts, quick data processing, trying out an API, or teaching someone the basics of C#, a single file is often exactly the right tool.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/03/01/file-based-apps-in-.net-10/ -

BLE Scanning on Android in .NET MAUI

Sat, 28 Feb 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/02/28/ble-scanning-on-android-in-.net-maui/ -

In my previous post I mentioned scan modes briefly, mostly in the context of why RSSI behaves the way it does on Android. A few people asked for a more complete example, so here is a MAUI-ready Android service you can drop in.

BluetoothLeScanner gets the scan settings, and ScanSettings.Builder().SetScanMode(ScanMode.LowLatency) is the bit that enables low-latency scanning. In .NET for Android, those settings are passed into StartScan(...). Android’s BLE docs also recommend stopping scans promptly because continuous scanning is expensive on battery.

1. Shared interface

Create this somewhere in shared code, for example Services/IBleScanner.cs.

public interface IBleScanner
{
 event EventHandler<BleDeviceDiscoveredEventArgs>? DeviceDiscovered;

 bool IsScanning { get; }

 Task StartScanningAsync(CancellationToken cancellationToken = default);
 Task StopScanningAsync();
}

public sealed class BleDeviceDiscoveredEventArgs : EventArgs
{
 public BleDeviceDiscoveredEventArgs(string id, string? name, int rssi)
 {
 Id = id;
 Name = name;
 Rssi = rssi;
 }

 public string Id { get; }
 public string? Name { get; }
 public int Rssi { get; }
}

2. Android implementation

Put this in Platforms/Android/BleScanner.android.cs.

using Android.Bluetooth;
using Android.Bluetooth.LE;
using Android.Content;
using Microsoft.Maui.ApplicationModel;
using Application = Android.App.Application;

public sealed class BleScanner : Java.Lang.Object, IBleScanner
{
 private readonly BluetoothManager? _bluetoothManager;
 private BluetoothAdapter? _adapter;
 private BluetoothLeScanner? _scanner;
 private ScanCallbackImpl? _callback;

 public event EventHandler<BleDeviceDiscoveredEventArgs>? DeviceDiscovered;

 public bool IsScanning { get; private set; }

 public BleScanner()
 {
 _bluetoothManager =
 Application.Context.GetSystemService(Context.BluetoothService) as BluetoothManager;

 _adapter = _bluetoothManager?.Adapter;
 _scanner = _adapter?.BluetoothLeScanner;
 }

 public Task StartScanningAsync(CancellationToken cancellationToken = default)
 {
 EnsureBluetoothReady();

 if (IsScanning)
 return Task.CompletedTask;

 _callback = new ScanCallbackImpl(args =>
 {
 MainThread.BeginInvokeOnMainThread(() =>
 {
 DeviceDiscovered?.Invoke(this, args);
 });
 });

 var settings = new ScanSettings.Builder()
 .SetScanMode(Android.Bluetooth.LE.ScanMode.LowLatency)
 .Build();

 var filters = new List<ScanFilter>();

 _scanner!.StartScan(filters, settings, _callback);
 IsScanning = true;

 if (cancellationToken.CanBeCanceled)
 {
 cancellationToken.Register(() =>
 {
 _ = StopScanningAsync();
 });
 }

 return Task.CompletedTask;
 }

 public Task StopScanningAsync()
 {
 if (!IsScanning || _scanner == null || _callback == null)
 return Task.CompletedTask;

 _scanner.StopScan(_callback);
 IsScanning = false;
 _callback = null;

 return Task.CompletedTask;
 }

 private void EnsureBluetoothReady()
 {
 _adapter ??= _bluetoothManager?.Adapter;
 _scanner ??= _adapter?.BluetoothLeScanner;

 if (_bluetoothManager == null || _adapter == null || _scanner == null)
 throw new InvalidOperationException("Bluetooth LE scanning is not available on this device.");

 if (!_adapter.IsEnabled)
 throw new InvalidOperationException("Bluetooth is turned off.");
 }

 private sealed class ScanCallbackImpl : ScanCallback
 {
 private readonly Action<BleDeviceDiscoveredEventArgs> _onDeviceDiscovered;

 public ScanCallbackImpl(Action<BleDeviceDiscoveredEventArgs> onDeviceDiscovered)
 {
 _onDeviceDiscovered = onDeviceDiscovered;
 }

 public override void OnScanResult(ScanCallbackType callbackType, ScanResult? result)
 {
 if (result?.Device == null)
 return;

 var args = new BleDeviceDiscoveredEventArgs(
 id: result.Device.Address ?? string.Empty,
 name: result.Device.Name,
 rssi: result.Rssi);

 _onDeviceDiscovered(args);
 }

 public override void OnBatchScanResults(IList<ScanResult>? results)
 {
 if (results == null)
 return;

 foreach (var result in results)
 {
 if (result?.Device == null)
 continue;

 var args = new BleDeviceDiscoveredEventArgs(
 id: result.Device.Address ?? string.Empty,
 name: result.Device.Name,
 rssi: result.Rssi);

 _onDeviceDiscovered(args);
 }
 }

 public override void OnScanFailed(ScanFailure errorCode)
 {
 System.Diagnostics.Debug.WriteLine($"BLE scan failed: {errorCode}");
 }
 }
}

3. Register it in MauiProgram.cs

builder.Services.AddSingleton<IBleScanner, BleScanner>();

4. Use it from a page or view model

public partial class MainPage : ContentPage
{
 private readonly IBleScanner _bleScanner;

 public MainPage(IBleScanner bleScanner)
 {
 InitializeComponent();
 _bleScanner = bleScanner;
 _bleScanner.DeviceDiscovered += OnDeviceDiscovered;
 }

 private async void OnStartScanClicked(object sender, EventArgs e)
 {
 await _bleScanner.StartScanningAsync();
 }

 private async void OnStopScanClicked(object sender, EventArgs e)
 {
 await _bleScanner.StopScanningAsync();
 }

 private void OnDeviceDiscovered(object? sender, BleDeviceDiscoveredEventArgs e)
 {
 System.Diagnostics.Debug.WriteLine(
 $"Found {e.Name ?? "(unknown)"} [{e.Id}] RSSI={e.Rssi}");
 }
}

5. Android permissions

Modern Android BLE scanning requires Bluetooth scan permissions, and older Android versions may also require location permission for scan results to work correctly.

In Platforms/Android/AndroidManifest.xml you will usually need:

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

<uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

And on Android 12+, you also need to request the runtime permissions before scanning.

Side note

LowLatency is the most aggressive scan mode Android exposes, but it still does not guarantee perfectly continuous callbacks because behavior can vary by Android version, device, and power policy. BluetoothLeScanner is the correct Android API to use for scan operations, and ScanSettings is where you configure the scan mode.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/02/28/ble-scanning-on-android-in-.net-maui/ -

Why BLE RSSI Spikes on Android

Fri, 27 Feb 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/02/27/why-ble-rssi-spikes-on-android/ -

Working on the BLE emulator, I kept noticing that RSSI readings on Android were jumpier than on iOS. Not just a little — noticeably more erratic, even when nothing was moving and the environment hadn’t changed.

It took me a while to understand why. The answer is scan modes and duty cycling.

Scan modes

When you start a BLE scan on Android you can choose how aggressively the radio listens:

SCAN_MODE_LOW_POWER — short bursts with long gaps. This is the default.
SCAN_MODE_BALANCED — moderate frequency
SCAN_MODE_LOW_LATENCY — as close to continuous as you can get

The problem with anything other than LOW_LATENCY is that the scanner goes quiet between windows. BLE devices advertise at their own intervals — often 100 to 1000 ms — and Android simply misses packets while the scan window is closed. When scanning resumes, you get whatever advertisement happens to arrive next. Because you missed the intermediate packets, that value can differ significantly from the last one you saw, and that shows up as a spike.

You set it like this:

var settings = new ScanSettings.Builder()
 .SetScanMode(ScanMode.LowLatency)
 .Build();

Duty cycling

Even with LOW_LATENCY, Android may still apply internal duty cycling depending on device and OS version. You don’t control this, and missed packets are simply lost — they are not queued.

What you do see is irregular timing between callbacks. Samples arrive unevenly, and because RSSI varies naturally due to multipath, antenna orientation, and nearby obstacles, uneven sampling makes the signal look more erratic than it actually is.

RSSI is inherently noisy even under ideal conditions — scan behavior amplifies that noise rather than causing it. iOS is smoother here. CoreBluetooth handles scan scheduling internally and tends to produce more consistent readings. Android gives you more control, but also more noise.

Why it matters

If you read my previous post on RSSI proximity estimation, you might recognize why the outlier rejection and the consecutive-hits guard were necessary. I didn’t write them because I had read a spec. I wrote them because raw Android readings were doing strange things and those two additions made behavior noticeably more stable.

Duty cycling is a large part of why.

The guards are not a workaround for bad code. They are a response to how the Android Bluetooth stack actually behaves.

If you need better readings

A few things that help:

Use SCAN_MODE_LOW_LATENCY if battery is not a concern
Increase your smoothing alpha slightly on Android compared to iOS
Be more aggressive with outlier rejection — a 15 dBm threshold is reasonable, but you may want to go lower

For my emulator it was enough to just know that the jumpiness was expected, and not a sign that something else was wrong.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/02/27/why-ble-rssi-spikes-on-android/ -

Approximating BLE Proximity with RSSI in .NET on iOS

Fri, 20 Feb 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/02/20/approximating-ble-proximity-with-rssi-in-.net-on-ios/ -

I’ve continued working on my hobby project, a Bluetooth device emulator, and at some point I had what felt like a brilliant idea. I wanted to map out nearby Bluetooth devices from the receiving end and get a sense of where they were located.

That turns out not to be a straightforward problem. Bluetooth doesn’t tell you where something is. What you get is signal strength, and distance is just one of many factors that affect it.

Still, it felt like there had to be a way. I started playing around with this mostly for fun, knowing that I wouldn’t be able to produce a reliable distance estimate good enough for real-world use. There are simply too many variables that influence the signal.

But for the sake of curiosity, I wanted to see how far I could get.

RSSI

RSSI, Received Signal Strength Indicator, is a measure of how strong a received radio signal is. In BLE it is expressed in negative dBm values:

closer to 0 means stronger signal
more negative means weaker signal

So -50 is stronger than -80.

The important detail is that RSSI is not a distance. It is affected by distance, but also by a number of other factors that can easily dominate the reading.

What affects RSSI the most

Obstacles and materials

Walls, metal, and even people can significantly reduce signal strength. The human body is mostly water, which absorbs 2.4 GHz signals very effectively. Simply putting a phone in your pocket can change RSSI noticeably.

Indoor reflections and multipath

Indoors, signals bounce off surfaces and arrive via multiple paths. Some reinforce each other, others cancel out. This creates rapid fluctuations in RSSI even when nothing is moving.

Distance and transmit power

Distance still matters, and so does transmit power, but they are only part of the picture. Two identical distances can produce very different RSSI values depending on the environment.

The distance formula

There is a well-known formula to estimate distance:

distance ≈ 10 ^ ((TxPowerAt1m - RSSI) / (10 * n))

It works in theory, but in practice it depends on two values you rarely know precisely:

RSSI at exactly 1 meter for your specific devices
the environment factor n, which changes depending on walls, furniture, and people

You can calibrate these values, but even then the estimate will drift as soon as conditions change.

The result is that distance calculations tend to look precise but behave inconsistently.

The math behind it

The formula is based on a simplified radio propagation model called the log-distance path loss model, which in turn is derived from the Friis transmission equation.

The key idea is that signal strength does not decrease linearly with distance. It decreases logarithmically as the signal spreads out.

In practice, engineers express signal strength in decibels, which turns the relationship into a linear equation:

RSSI = TxPowerAt1m - 10 * n * log10(d)

Where:

d is distance
TxPowerAt1m is the expected RSSI at 1 meter
n is the path-loss exponent

If you rearrange that equation to solve for distance, you get:

d = 10 ^ ((TxPowerAt1m - RSSI) / (10 * n))

That is the formula we started with.

What it is really doing is estimating how far away a device would be if the signal behaved in a smooth, predictable way. Indoors, that assumption rarely holds.

Proximity, not distance

Instead of asking “how many meters away is this device,” a more reliable question is: is it very close, nearby, or far away?

That maps much better to what RSSI can actually tell you.

A simple set of buckets might look like this:

>= -60 → immediate
-60 to -75 → near
-75 to -88 → far
< -88 → unknown

These values are not universal. You will need to tune them based on your environment and hardware.

Working with Core Bluetooth in .NET

When scanning, you get RSSI from the discovery callback. When connected, you explicitly request updates.

public override void DiscoveredPeripheral(
 CBCentralManager central,
 CBPeripheral peripheral,
 NSDictionary advertisementData,
 NSNumber RSSI)
{
 if (RSSI != null)
 {
 var value = RSSI.Int32Value;
 // feed into estimator
 }
}

For connected devices:

peripheral.ReadRSSI();

And handle the callback:

public override void RssiRead(CBPeripheral peripheral, NSNumber rssi, NSError error)
{
 if (error != null || rssi == null)
 return;

 var value = rssi.Int32Value;
 // feed into estimator
}

Smoothing RSSI

Raw RSSI is too unstable to use directly. You need to smooth it.

A simple and effective approach is an exponential moving average:

_ema = alpha * rssi + (1 - alpha) * _ema;

Where alpha is typically between 0.2 and 0.3.

You should also ignore obvious outliers. If a value suddenly jumps by 15 dB compared to your current average, it is often just noise.

Instead of switching proximity immediately, require a few consecutive readings before changing state. This stabilizes the experience significantly.

A practical estimator

Putting it together:

public enum BleProximity
{
 Unknown,
 Immediate,
 Near,
 Far
}

public sealed class BleRssiEstimator
{
 private double? _ema;
 private readonly double _alpha = 0.25;
 private BleProximity _current = BleProximity.Unknown;
 private BleProximity _candidate;
 private int _candidateHits;

 public void AddSample(int rssi)
 {
 if (rssi >= 0)
 return;

 if (_ema.HasValue && Math.Abs(rssi - _ema.Value) > 15)
 return;

 _ema = _ema.HasValue
 ? _alpha * rssi + (1 - _alpha) * _ema.Value
 : rssi;

 UpdateProximity();
 }

 public BleProximity Current => _current;

 private void UpdateProximity()
 {
 if (!_ema.HasValue)
 return;

 var next = Classify(_ema.Value);

 if (next == _current)
 {
 _candidateHits = 0;
 return;
 }

 if (next != _candidate)
 {
 _candidate = next;
 _candidateHits = 1;
 return;
 }

 if (++_candidateHits >= 3)
 {
 _current = next;
 _candidateHits = 0;
 }
 }

 private static BleProximity Classify(double rssi)
 {
 if (rssi >= -60) return BleProximity.Immediate;
 if (rssi >= -75) return BleProximity.Near;
 if (rssi >= -88) return BleProximity.Far;
 return BleProximity.Unknown;
 }
}

Calibration matters

If you want reasonable behavior, you need to calibrate:

Place devices 1 meter apart
Measure RSSI for 10–20 seconds
Average the result
Adjust your thresholds based on real-world testing

Even small changes in placement or environment can shift results noticeably, so calibration is not a one-time task.

RSSI works best when you:

treat it as a relative signal, not a precise measurement
smooth aggressively
use proximity buckets instead of meters

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/02/20/approximating-ble-proximity-with-rssi-in-.net-on-ios/ -

Why Your BLE Manufacturer Data Disappears on macOS (.NET + CoreBluetooth)

Thu, 05 Feb 2026 00:00:00 +0000

Iris Classon - In Love with Code https://www.irisclasson.com/2026/02/05/why-your-ble-manufacturer-data-disappears-on-macos-.net--corebluetooth/ -

If you’ve ended up here, I am sorry. I also hope you have not spent as much time as I did trying to figure out why the manufacturer data is always empty on the receiving end.

I have been working on a .NET MAUI BLE device emulator and realized, after an embarrassing amount of debugging, that Apple does not let us include more than a local name and service UUIDs when advertising with Core Bluetooth.

The supported keys are:

CBAdvertisementDataLocalNameKey
CBAdvertisementDataServiceUUIDsKey

Which is unfortunate, because I needed manufacturer data for my emulator devices. More precisely, I needed a way to send more data without connecting.

Apple’s approach is simple. Advertise just enough to connect, then exchange real data after connection. I would have saved myself a lot of time if I had internalized that earlier.

https://developer.apple.com/documentation/corebluetooth/cbperipheralmanager/startadvertising(_:)

My assumption was straightforward. If I can read manufacturer data when scanning, I should be able to send manufacturer data when advertising.

Nope. That symmetry does not exist here.

So, workarounds it is.

Option 1: Use GATT for the real data

Advertise just enough to be discovered, then use GATT for the actual data.

That means advertising a single service UUID, optionally adding a short local name, and then reading a characteristic after connecting. That characteristic can contain whatever you need, like serial number, firmware version, device role, owner tag, or location.

Option 2: Encode identity in the service UUID

Another option is to encode identity into the service UUID itself.

For example, you can use a fixed base UUID and let the last bytes represent device type, instance, or region. It is not pretty, but it is reliable on Apple platforms.

Option 3: Use the local name

You can also use the local name to carry a bit of extra information.

Something like DEbtn1, where DE stands for Device Emulator and btn1 identifies the device. You do not have many bytes to work with, but it is often enough to distinguish your devices in a crowded BLE environment.

If you have a smarter approach, I would love to hear it. For now, I am combining all three strategies in my emulator.

There will likely be more posts like this as I continue exploring CoreBluetooth and working with Bluetooth in .NET and .NET MAUI.

Comments

Leave a comment below, or by email. - https://www.irisclasson.com/2026/02/05/why-your-ble-manufacturer-data-disappears-on-macos-.net--corebluetooth/ -