Forem: Aaron LaBeau

Porting a SwiftUI App to Avalonia: How does Cross-Platform .NET hold up

Aaron LaBeau — Fri, 17 Apr 2026 14:06:26 +0000

Let me start with a confession: I love SwiftUI. I don't love the fact that roughly 70% of developers outside of Apple's walled garden can run my SwiftUI app. That math doesn't work when you're building a developer tool.

So when I set out to ship Ditto Edge Studio — a debug and query tool for the Ditto edge database — I needed it to run on Windows, Linux, and macOS. On the Mac I already had a polished SwiftUI build. For everyone else, I turned to Avalonia. This post is about what I learned bringing the two into the same family, specifically around two features that had no business being easy to port:

A three-pane layout with a Sidebar, detail view, and Inspector (SwiftUI's NavigationSplitView + .inspector)
A Presence Viewer — an animated network graph of peers — built in SpriteKit on macOS and reimplemented with SkiaSharp on .NET

Spoiler: it's pretty good. Not "identical-pixel-for-identical-pixel" good, but "I'd ship this to customers tomorrow" good. Let me show you.

The Three-Pane Layout: Sidebar + Detail + Inspector

On macOS, SwiftUI hands you this layout on a silver platter. NavigationSplitView gives you the sidebar. .inspector gives you the right-hand panel. You write about twelve lines and Apple's engineers do the rest of the work while you sip a latte.

SwiftUI: The Frictionless Version

struct MainStudioView: View {
    @State private var columnVisibility: NavigationSplitViewVisibility = .all
    @State private var showInspector = false

    var body: some View {
        NavigationSplitView(columnVisibility: $columnVisibility) {
            // Sidebar
            unifiedSidebarView()
                .navigationSplitViewColumnWidth(min: 200, ideal: 250, max: 300)
        } detail: {
            // Center content — switches on the selected sidebar item
            Group {
                switch viewModel.selectedSidebarMenuItem.name {
                case "Collections": queryDetailView()
                case "Observers":   observeDetailView()
                default:            syncTabsDetailView()
                }
            }
            .id(viewModel.selectedSidebarMenuItem)
            .transition(.blurReplace)
        }
        .navigationSplitViewStyle(.prominentDetail)
        .inspector(isPresented: $showInspector) {
            inspectorView()
                .inspectorColumnWidth(min: 250, ideal: 350, max: 500)
        }
    }
}

That's it. Resizable columns, animated transitions, proper collapsing on narrow windows, native macOS chrome, the works. If you've never built this before, you won't appreciate how much is happening for free. If you have built it before — on, say, WPF in 2014 — you're probably reading this through quiet tears of envy.

Avalonia: Assembling the Ikea Version

Avalonia ships a SplitView control, but it's a two-pane component designed for the classic hamburger-nav pattern. Three panes with independent resizing means rolling your own with a Grid and a couple of GridSplitters. Is it as elegant as SwiftUI? No. Is it actually fine and kind of fun to build? Eh, if you have AI to help you find the XAML bugs, then yes.

Here's the load-bearing XAML from EdgeStudioView.axaml:

<Grid Grid.Row="1">
    <Grid.ColumnDefinitions>
        <!-- Icon nav rail (always visible) -->
        <ColumnDefinition Width="48" MinWidth="48" MaxWidth="60"/>
        <!-- Splitter 1 -->
        <ColumnDefinition Width="Auto"/>
        <!-- Sidebar listing panel -->
        <ColumnDefinition Width="Auto"/>
        <!-- Splitter 2 -->
        <ColumnDefinition Width="Auto"/>
        <!-- Detail view (takes the rest) -->
        <ColumnDefinition Width="*" MinWidth="400"/>
        <!-- Inspector splitter (only shown when inspector is open) -->
        <ColumnDefinition Width="Auto"/>
        <!-- Inspector panel (collapses via IsVisible) -->
        <ColumnDefinition Width="280" MinWidth="200"/>
    </Grid.ColumnDefinitions>

    <navigation:NavigationBar Grid.Column="0"
                              DataContext="{Binding NavigationViewModel}"/>

    <GridSplitter Grid.Column="1" Width="5"
                  ResizeDirection="Columns"
                  IsVisible="{Binding IsListingPanelVisible}"/>

    <Panel Grid.Column="2" MinWidth="200" MaxWidth="500"
           IsVisible="{Binding IsListingPanelVisible}">
        <ContentControl Content="{Binding CurrentListingViewModel}">
            <ContentControl.DataTemplates>
                <DataTemplate DataType="{x:Type vm:QueryViewModel}">
                    <sidebar:QueryListingView/>
                </DataTemplate>
                <DataTemplate DataType="{x:Type vm:SubscriptionViewModel}">
                    <sidebar:SubscriptionListingView/>
                </DataTemplate>
                <!-- ...etc. -->
            </ContentControl.DataTemplates>
        </ContentControl>
    </Panel>

    <GridSplitter Grid.Column="3" Width="5" ResizeDirection="Columns"/>

    <ContentControl Grid.Column="4" Content="{Binding CurrentDetailViewModel}"/>

    <GridSplitter Grid.Column="5" Width="5"
                  ResizeDirection="Columns"
                  IsVisible="{Binding IsInspectorVisible}"/>

    <Panel Grid.Column="6" IsVisible="{Binding IsInspectorVisible}">
        <!-- Inspector content here -->
    </Panel>
</Grid>

The pattern — DataTemplates keyed to ViewModel types inside a ContentControl — is Avalonia's idiomatic answer to SwiftUI's switch over an enum inside a Group. The MVVM ViewModel swaps, and Avalonia's ViewLocator or inline templates pick the matching view. Same conceptual dance, just with more angle brackets.

What I Lost (Being Honest)

Transitions. SwiftUI's .transition(.blurReplace) is a one-liner. In Avalonia I'd need to animate opacity/translation myself on DataContext change. I skipped it. Nobody filed a bug.
The collapse-on-narrow-window magic. SwiftUI knows when to hide the sidebar. On Avalonia I decide via a bound IsListingPanelVisible property and a toggle button.
Native macOS chrome. On Avalonia I use SukiUI's SukiWindow, which looks great and consistent on all three OSes — but it's not Apple-native. That's a feature, not a bug: the whole point was consistency across Windows/Linux/macOS.

What I Gained

One codebase. Three operating systems. Zero Electron. Native compiled performance with dotnet publish -r win-x64 --self-contained. I'll take that trade.

The Presence Viewer: SpriteKit vs. SkiaSharp

This is where things got interesting. The Presence Viewer shows a live network diagram of Ditto peers — nodes floating around, edges animating between them as connections come and go, color-coded by transport (Bluetooth, P2P Wi-Fi, WebSocket, etc.). It's the feature that makes people go "oh, cool" in demos. Losing it in the Avalonia build was not an option.

SwiftUI: SpriteKit Does the Heavy Lifting

On macOS I used SpriteKit — Apple's 2D game engine. Overkill for a debug UI? Absolutely. And that's the point. I get a physics-backed scene graph, built-in node dragging, and buttery 60fps animations that I didn't have to think about.

import SpriteKit
import SwiftUI

struct PresenceViewerSK: View {
    @State private var scene: PresenceNetworkScene?

    var body: some View {
        ZStack(alignment: .bottomTrailing) {
            SpriteKitSceneView(scene: $scene, viewModel: viewModel)
                .frame(maxWidth: .infinity, maxHeight: .infinity)
                .focusable()

            // Overlay controls on top of the scene
            VStack(alignment: .trailing, spacing: 8) {
                directConnectedToggle
                zoomControls
            }
            .padding(.trailing, 16)
            .padding(.bottom, 72)
        }
    }
}

class PresenceNetworkScene: SKScene {
    func updatePresenceGraph(localPeer: PeerProtocol,
                             remotePeers: [PeerProtocol]) {
        // Diff peers, add/remove SKNodes, animate with SKAction
    }
}

SpriteKit handles hit-testing, SKAction handles the tweens, and SKCameraNode gives me zoom and pan for the price of a couple of properties. If you ever wondered why Apple developers sometimes sound smug — this is why.

Avalonia: Hello, Skia

SpriteKit does not run on Windows. Shocker, I know. But Avalonia ships with SkiaSharp baked in — the same Skia that powers Chrome, Android, and sort of Flutter (it's been replaced by Impeller and I can see why after doing this). If you're drawing pixels on .NET and using Avalonia, Skia is your friend.

I built a custom Control that owns a WriteableBitmap, locks it every frame, and hands Skia an SKSurface to draw into:

public class PresenceGraphControl : Control
{
    private WriteableBitmap? _bitmap;
    private readonly PresenceGraphRenderer _renderer = new();
    private readonly PresenceGraphAnimator _animator = new();
    private DispatcherTimer? _animationTimer;

    public static readonly StyledProperty<PresenceGraphSnapshot?> SnapshotProperty =
        AvaloniaProperty.Register<PresenceGraphControl, PresenceGraphSnapshot?>(
            nameof(Snapshot));

    static PresenceGraphControl()
    {
        AffectsRender<PresenceGraphControl>(
            SnapshotProperty, PositionsProperty, ZoomLevelProperty);
    }

    public override void Render(DrawingContext context)
    {
        var bounds = Bounds;
        var pw = (int)bounds.Width;
        var ph = (int)bounds.Height;

        if (_bitmap == null ||
            _bitmap.PixelSize.Width  != pw ||
            _bitmap.PixelSize.Height != ph)
        {
            _bitmap?.Dispose();
            _bitmap = new WriteableBitmap(
                new PixelSize(pw, ph),
                new Vector(96, 96),
                PixelFormats.Bgra8888,
                AlphaFormat.Premul);
        }

        using var locked = _bitmap.Lock();
        var info = new SKImageInfo(pw, ph,
            SKColorType.Bgra8888, SKAlphaType.Premul);
        using var surface = SKSurface.Create(
            info, locked.Address, locked.RowBytes);

        _renderer.Draw(surface.Canvas, Snapshot,
                       GetEffectivePositions(), _zoom, _panX, _panY);

        context.DrawImage(_bitmap, new Rect(bounds.Size));
    }
}

The AffectsRender call is the Avalonia equivalent of saying "hey framework, when any of these properties change, please call Render again." A DispatcherTimer ticks 60 times a second to drive the animator, which interpolates node positions with a simple spring-ish easing. Pointer events get routed from OnPointerPressed / OnPointerMoved to figure out whether the user is panning the camera or dragging an individual node.

The renderer itself is refreshingly boring C#:

public class PresenceGraphRenderer
{
    private static readonly Dictionary<string, SKColor> ConnectionColors = new()
    {
        ["Bluetooth"]   = new SKColor(0,   102, 217),
        ["AccessPoint"] = new SKColor(13,  133, 64),
        ["P2PWifi"]     = new SKColor(199, 26,  56),
        ["WebSocket"]   = new SKColor(217, 122, 0),
        ["AWDL"]        = new SKColor(136, 68,  221),
        ["Cloud"]       = new SKColor(115, 38,  184),
    };

    public void Draw(SKCanvas canvas, PresenceGraphSnapshot? snap, /* ... */)
    {
        canvas.Clear(SKColors.Transparent);
        DrawEdges(canvas, snap);
        DrawNodes(canvas, snap);
        DrawLegend(canvas);
    }
}

The Honest Trade-Off

SpriteKit's animations are noticeably nicer. When a peer drops off the mesh, SwiftUI gives me a particle-poof-esque fade that took zero effort. On Skia I get a clean alpha interpolation. It's smooth, it's readable, it does the job — but it isn't magic. If your users are going to stare at this for hours, SpriteKit wins. If they glance at it to debug a sync issue and move on, nobody notices.

What Skia does give me:

Identical rendering on Windows, Linux, and macOS. No surprises.
Deterministic control. Every pixel is my fault, which is occasionally humbling and often useful when debugging.
Testability. I can unit-test the renderer and animator without standing up a UI — PresenceGraphRendererTests.cs is a real thing in the repo.
Performance. Skia is not slow. It's what your web browser uses. It does not need your pity.

So, Should You Use Avalonia?

If any of these describe you, yes:

You need one codebase for Windows, Linux, and macOS and you don't want to pay the Electron tax.
You already know C# / XAML, or you're happy to learn MVVM (it's not scary; it's WPF with better manners).
You can live without a few SwiftUI luxuries — .transition, implicit animations, the occasional bit of "how did that just work?" Apple magic.

If you're shipping Mac-only and SwiftUI meets your needs, keep shipping SwiftUI. It's a wonderful framework designed by people who clearly enjoy their jobs.

But for everyone else? Avalonia isn't a compromise — it's a serious, production-ready option that happens to run everywhere. I ported a real app. I shipped a real animated graph. I did not cry (much). My Linux users can finally stop asking if there will ever be a Linux version available.

And honestly, there's something poetic about Microsoft-stewarded .NET running a native app on Linux to manage an edge database that syncs over Bluetooth. We live in weird, wonderful times.

Claude Mythos and the Mobile App Security Wake-Up Call: Why Mobile Developers Can't Afford to Wait

Aaron LaBeau — Wed, 15 Apr 2026 15:21:12 +0000

Anthropic's new Claude Mythos model has already uncovered thousands of critical vulnerabilities — some of them hidden in production software for 27 years. The cybersecurity conversation has focused on operating systems, browsers, and cloud infrastructure, but mobile apps sit squarely in the blast radius. If your iOS or Android app ships without code hardening, runtime protection, and continuous security testing, an AI agent will find the cracks long before your next release.

An AI model just rewrote the threat model

On April 15, 2026, the industry began absorbing what Consultancy.eu called a "shockwave through the cybersecurity landscape": Anthropic's Claude Mythos is so effective at finding software flaws that it isn't being released to the public. Instead, access is restricted to a small consortium — "Project Glasswing" — so companies like Apple, AWS, Google, Microsoft, and NVIDIA can patch what the model finds before attackers do. And buried inside Anthropic's own red-team preview of the model is a finding that, frankly, stopped me cold: a 27-year-old bug in OpenBSD.

For anyone who didn't cut their teeth on it, OpenBSD is the project whose tagline — "Only two remote holes in the default install, in a heck of a long time" — was half-joke, half-mission statement. I ran OpenBSD on the edge of the ISP I worked at back in the 1990s. It was the operating system you picked when "secure by default" actually had to mean something, because your pager would go off if it didn't. Proactive code audits, memory-safety work, privilege separation, pledge, unveil — OpenBSD spent thirty years being the most paranoid, most carefully reviewed Unix on the planet.

The bug Mythos Preview surfaced is a textbook example of why that matters. It lives in OpenBSD's TCP Selective Acknowledgement (SACK) implementation, added to the kernel in 1998 shortly after RFC 2018 standardized SACK. OpenBSD tracks SACK state as a singly linked list of "holes" — byte ranges sent but not yet acknowledged. A subtle logic mistake, pivoting on a signed-integer overflow in the 32-bit TCP sequence-number comparison (int)(a - b), makes a normally unreachable codepath reachable. The net effect: a remote attacker can repeatedly crash any OpenBSD host that responds over TCP. Firewalls. Routers. Core internet plumbing. A denial-of-service primitive sitting in the network stack, untouched, for 27 years of some of the most adversarial human code review on the planet — found autonomously by an AI model for, per Anthropic's own figures, under $50 of compute on the run that surfaced it. If an AI can shake loose a latent flaw there, the baseline assumption for every other piece of software on earth needs to be re-examined.

The numbers are staggering. Thousands of critical vulnerabilities. Bugs that survived nearly three decades of code review. And as AI security expert Nanne van 't Klooster of Rewire put it, we are now watching "an arms race between autonomous AI agents — one that humans can no longer keep up with."

Read that sentence again. Then open your mobile app's repo.

Why mobile developers need to take this seriously

If you build mobile apps, it is tempting to watch this story from a distance. Claude Mythos is chasing OS-level flaws. The headlines name chipmakers and hyperscalers. Mobile apps don't appear in the press release.

That is exactly the problem.

The same AI capability that finds decades-old bugs in kernels will absolutely be turned on compiled mobile binaries. Everyone is a target, no one is too small. Mobile apps are:

Distributed as binaries. Anyone can pull your IPA or APK off a device and reverse-engineer it. There is no server in the way.
Handling the crown jewels. Authentication tokens, session cookies, payment credentials, cryptographic keys, health records, location data. Mobile is where the sensitive stuff lives.
Widely deployed and slow to patch. Even when you ship a fix, users lag behind for weeks or months.
Built on third-party dependencies. A single vulnerable SDK can expose millions of installs.

When autonomous agents can systematically explore every pathway in your app, your obscurity is no longer a defense. If your app's logic is readable, your logic will be read.

The mobile threat landscape, in plain terms

Guardsquare's overview of mobile app security makes the point bluntly: too many mobile projects treat security as an afterthought. Research cited on that page is hard to ignore — roughly three quarters of developers admit iOS and Android standard security isn't sufficient, many still rely on the OS alone, and 95% of survey respondents see room to improve their security program.

The recent Coruna and DarkSword iOS exploit kits are a preview of what's coming. As Guardsquare's research team documented, a single visit to a compromised site can bypass iOS sandboxing, hook sensitive functions inside your app, and exfiltrate credentials and keys in real time. Function hooks sit at the top of a method and redirect execution to the attacker's code before your logic runs. Hook SecTrustEvaluateWithError() to always return true, and SSL pinning is gone. Hook Keychain access, and your secrets walk out the door.

Now imagine that threat class accelerated by a model like Claude Mythos — an AI agent enumerating hook targets, chaining primitives, and writing working exploit code on its own timeline. Don't assume the operating system is a walled garden protecting your app's memory. The new exploits, and the new models, are a wake-up call.

What mobile app security actually looks like

Mobile application security is the protection of mobile apps against cyber attacks across the full software development lifecycle. It isn't one control. It's layers, and each layer reinforces the others. The practical pillars:

Mobile application security testing (MAST). Scan your code and dependencies continuously, early, and in your CI pipeline. The earlier an issue is found, the cheaper it is to fix.

Code hardening and obfuscation. Rename symbols, obfuscate control flow, encrypt strings, and virtualize sensitive routines so your binary doesn't read like source code when an attacker — or an AI agent — disassembles it.

Runtime application self-protection (RASP). Detect jailbreaks, root access, debuggers, hooks, emulators, and tampered system libraries at runtime, and respond — crash, degrade, revoke sessions, alert the backend.

App attestation. Prove that the app talking to your API at runtime is a genuine, unmodified build on a trustworthy device.

Threat monitoring. See what's actually happening in the wild, because static assumptions don't survive contact with real users and real attackers.

Single-layer defenses fall. Layered defenses make each successive step exponentially harder. That is the whole game.

How AppSweep fits in: shift security left, catch issues before release

AppSweep is Guardsquare's mobile application security testing platform, and it's built for the way modern mobile teams actually work.

Multi-analysis testing — static and interactive — tuned specifically for iOS and Android risks, not generic web scanners awkwardly retrofitted to binaries.
OWASP MASVS-aligned findings that prioritize what matters and map directly to the industry standard your auditors already know.
CLI-first CI integration with Bitrise, Fastlane, GitHub Actions, Jenkins, and the rest of your DevOps toolchain. Every build gets scanned. Regressions get caught before they ship.
Developer-first UI that produces actionable remediation guidance rather than a 400-page PDF nobody reads.

In a world where AI agents can enumerate every weakness in your compiled app, shipping without automated mobile security testing is like pushing to production without unit tests.

Yes, these are the ProGuard people

Worth pausing on this, because it matters: Guardsquare is the team behind ProGuard, the open-source shrinker, optimizer, and obfuscator that has been the default bytecode-processing step for Android developers for more than a decade. If you've shipped an Android app, you've almost certainly shipped with ProGuard — or with R8, the Android Gradle Plugin's ProGuard-compatible successor that still consumes ProGuard configuration syntax.

Anyone who shipped non-trivial Android apps in the 2010s remembers the ritual. I certainly do. Back when I was working on Xamarin.Android apps that sat on top of native Android code and bound Java libraries, I spent more hours than I'd like to admit hand-tuning proguard.cfg files to make sure controls, custom renderers, and reflection-accessed types didn't get stripped.

Xamarin.Android actually had two tree-shakers in the pipeline, and it's worth being precise about which did what:

The Xamarin/Mono managed linker (later evolved into ILLink in .NET) operated on the managed .NET IL side. It aggressively removed .NET types and members it couldn't prove were reachable. Anything accessed via reflection — custom Xamarin.Forms renderers, value converters, effects, platform-specific controls — would disappear silently unless you annotated them with [Preserve] or added a LinkDescription.xml. Setting Linker behavior to Link All Assemblies and watching half your UI vanish at runtime was a rite of passage.
ProGuard (and, in later toolchains, R8) operated on the Java bytecode side. It shrank the compiled Android code and any bound Java libraries. Miss a -keep rule for a class that was only referenced from JNI, from an AndroidManifest.xml entry, from a bound AAR, or from a library's reflection-based DI, and you'd get a ClassNotFoundException or NoSuchMethodError at runtime — usually only in a release build, because debug builds typically skipped shrinking.

The classic debugging loop was: ship a release build to UAT, watch a control fail to render or a callback fail to fire, grep the ProGuard mapping file, add a -keep class com.example.** rule, rebuild, repeat. Painful. But there was an unambiguous upside — the APK shrank. Dead code, unused library surface area, and unreachable methods all got cut. Smaller download, faster cold start, less memory pressure.

And here is the point that maps directly onto the Claude Mythos moment: code you don't ship is code that can't be attacked. Unused methods are ROP/JOP gadgets waiting to be chained. Unused reflection entry points are pivots. Unused debug scaffolding is a map of your app's internals sitting on every user's device. An unused vulnerable dependency is still a vulnerable dependency if its classes are in your DEX. Dead code is attack surface.

Shrinking is a security control, not just a size optimization. ProGuard's minification, combined with renaming and optimization, quietly removes functionality that an attacker — or an autonomous AI agent enumerating your binary — would otherwise have available to misuse. The same discipline that kept our Xamarin builds small is the discipline that keeps a modern app's attack surface tight.

iXGuard, DexGuard, and AppSweep are what happens when the people who wrote the tool the industry already trusts take that philosophy — remove what you don't need, protect what you do — and extend it to the full scope of modern mobile threats: static analysis, runtime attacks, supply-chain exposure, and the coming AI-driven wave.

The Claude Mythos lesson for mobile teams

Claude Mythos is a single data point in a much larger trend. The lesson is not "panic about one model." The lesson is:

Vulnerabilities that survived human review for 27 years were found in days.
Organizations with resources are racing to patch before the model goes public.
Mobile apps, which ship their attack surface directly to every user's pocket, are possibly next.

If your mobile security program is one annual pen test and a hope that the OS will hold, you are running on borrowed time. The organizations that come through the next 12 months intact are the ones that treat mobile app security the way they treat version control — continuous, layered, automated, and non-negotiable.

Research mobile app security before you ship another release

You don't need to buy anything today. You do need to know more than you did yesterday. This is real technical debt!

Start here. Read What is Mobile App Security. Learn the vocabulary — code hardening, RASP, obfuscation, attestation, MAST, OWASP MASVS. Understand the specific threats facing iOS and Android apps, and understand what a real defense-in-depth program looks like on mobile.

Then go deeper. Evaluate where your own app stands. Is your binary readable? Do you detect hooking? Are your builds scanned in CI? Does your security testing produce findings your developers actually fix? Look at AppSweep for testing and iXGuard for iOS hardening, and benchmark whatever you're doing today against what a layered program can look like.

Then act. The gap between organizations that take mobile app security seriously and organizations that don't is about to widen dramatically. The question is no longer if your mobile app will be targeted by an AI-assisted attacker. It's when — and whether you'll be ready.

Frequently Asked Questions

What is Claude Mythos?
Claude Mythos is an AI model from Anthropic, released in April 2026, that has demonstrated the ability to identify thousands of critical security vulnerabilities in operating systems and browsers — including flaws that went undetected for up to 27 years. Anthropic has restricted access to a consortium of major technology companies through an initiative called Project Glasswing so they can remediate before broader release.

Why does Claude Mythos matter for mobile app developers?
AI models capable of finding deep vulnerabilities in system software will be turned on mobile binaries next. Mobile apps ship their attack surface directly to end users, handle high-value data, and are frequently under-protected. Developers who rely on OS security alone are increasingly exposed.

What is mobile app security?
Mobile app security is the practice of protecting mobile applications from cyber attacks throughout the development lifecycle. It includes security testing, code hardening, obfuscation, runtime application self-protection (RASP), app attestation, and threat monitoring.

What is AppSweep?
AppSweep is Guardsquare's mobile application security testing tool. It performs static and interactive analysis of iOS and Android apps, aligns findings with OWASP MASVS, and integrates directly into CI/CD pipelines such as GitHub Actions, Fastlane, Bitrise, and Jenkins.

What is iXGuard?
iXGuard is Guardsquare's iOS app hardening product. It applies polymorphic, compiler-based obfuscation and runtime protections to defend iOS apps against static analysis, reverse engineering, dynamic instrumentation, hooking, and tampering.

Is Guardsquare the company behind ProGuard?
Yes. Guardsquare is the team behind ProGuard, the widely used open-source shrinker and obfuscator for Java bytecode. iXGuard, DexGuard, and AppSweep extend that heritage into comprehensive mobile application security.

What should I do right now?
Research mobile app security. Understand the threats, the defensive layers, and how your current app stacks up. The sources linked throughout this article are a strong starting point.

Sources:

Simplifying macOS App Deployment with Xcode Cloud: A Developer's Guide

Aaron LaBeau — Tue, 03 Feb 2026 19:39:46 +0000

Building and deploying MacOS applications doesn't have to be complicated. If you're an iOS or macOS developer, you've probably heard of Xcode Cloud—Apple's native CI/CD solution for app development. But is it worth using for your side projects? After switching from GitHub Actions to Xcode Cloud for deploying my SwiftUI macOS app, I can confidently say: absolutely. This guide walks through why Xcode Cloud might be the best choice for your macOS app deployment workflow, especially for side projects and small teams.

In this article: We'll compare Xcode Cloud and GitHub Actions for macOS development, explore real-world workflow automation, and see how Xcode Cloud handles app notarization and distribution—all through the lens of a production developer tool.

Estimated reading time: 8-10 minutes

What is Xcode Cloud?

Xcode Cloud is Apple's continuous integration and delivery (CI/CD) service built directly into Xcode. It streamlines the app development workflow by automating builds, testing, and distribution — all while keeping everything integrated into the tools you already use.

The service is designed specifically for Apple platforms, which means it handles all the Apple-specific quirks that can make CI/CD challenging. It automates builds with every code commit, runs tests across multiple device configurations in parallel, and integrates seamlessly with TestFlight and App Store Connect.

My Use Case: Edge Debug Helper

For context, the macOS app I'm deploying with Xcode Cloud is Edge Debug Helper—a SwiftUI-based developer tool for debugging applications built with Ditto.

Ditto is an offline-first database that enables apps to work reliably without constant connectivity by using mesh networking and CRDTs (Conflict-Free Replicated Data Types). It's particularly valuable for building edge applications where devices need to sync data peer-to-peer across Bluetooth, WiFi, and LAN—without relying on cloud infrastructure.

Edge Debug Helper allows developers to query and inspect Ditto databases across different environments (cloud, local servers, and peer-to-peer connections), making it easier to debug complex scenarios involving mesh networks, distributed data synchronization, and offline-first architectures. When you're dealing with CRDTs and multi-device sync in edge computing scenarios, having visibility into what's happening across your mesh network is invaluable.

For a macOS developer tool like this—where builds need to be notarized and distributed outside the Mac App Store—Xcode Cloud's automated workflow has been a perfect fit.

Xcode Cloud vs GitHub Actions: Why Make the Switch?

GitHub Actions is a powerful and flexible CI/CD platform, and many developers use it successfully for iOS and macOS projects. However, there's a significant complexity trade-off that's worth considering, especially for solo developers and small teams building native Apple applications.

The iOS/macOS Certificate Management Challenge

One of the biggest pain points with GitHub Actions for iOS and macOS development is certificate and provisioning profile management. Unlike Xcode Cloud, which automatically handles code signing with your Apple ID, GitHub Actions requires you to manually:

Export your certificates and provisioning profiles
Securely store them as GitHub secrets or in encrypted repositories
Set up tools like Fastlane Match for certificate synchronization
Handle certificate rotation and expiration
Manage Apple Developer Portal integration with two-factor authentication

According to recent developer surveys, certificate management is consistently cited as one of the most frustrating aspects of using general-purpose CI/CD tools for Apple platform development.

Custom Scripts and YAML Configuration

With GitHub Actions, you need to write custom YAML workflow files and often shell scripts to handle the build process. This means:

Learning GitHub Actions' YAML syntax
Writing scripts to install dependencies (CocoaPods, SPM, etc.)
Configuring build commands for different schemes and configurations
Setting up artifact uploads and downloads
Debugging workflow failures in a remote environment

While this flexibility is valuable for complex, multi-platform projects, it adds significant overhead for iOS-only or macOS-only projects. One developer aptly described their experience as: "If I ever end up in hell, my punishment would be setting up GitHub Actions for iOS projects".

The Simplicity Trade-off

Recent statistics from 2025 show that among iOS developers, the majority now use Xcode Cloud (41%) followed by GitHub Actions (31%). This shift reflects a growing preference for simplicity over flexibility for many developers.

Industry analysis confirms that while GitHub Actions offers more customization options, Xcode Cloud provides a significantly simpler setup with native iOS/macOS support. For solo developers and small teams working exclusively on Apple platforms, this simplicity is invaluable.

Xcode Cloud in Action

Setup Right from Xcode

Setting up Xcode Cloud is refreshingly simple. You can configure a workflow directly from Xcode in just a few minutes — no separate platform to learn, no YAML files to write, no certificate juggling required.

Everything is configured through a familiar interface within Xcode itself. You can set triggers (like pushing to a branch), choose build actions, specify test configurations, and set up deployment options — all through point-and-click.

Web Dashboard for Monitoring

While you can configure workflows in Xcode, you also have access to a comprehensive web dashboard through App Store Connect for monitoring your builds:

The dashboard provides an overview of all your workflows, recent builds, and their status at a glance.

Each build provides detailed information about the build process, test results, and any issues that occurred.

Once your build completes successfully, Xcode Cloud handles notarization automatically (for macOS apps), and you can download the notarized artifacts directly from the web interface.

Free Tier That Actually Works for Side Projects

Here's the best part: Xcode Cloud comes with 25 compute hours per month for free when you have an Apple Developer Program membership ($99/year). For side projects and developer tools like Edge Debug Helper, this is more than enough.

To put this in perspective, a compute hour is one hour of cloud execution time. If your typical build and test cycle takes 10 minutes, those 25 free hours give you 150 builds per month. That's plenty for most side projects and small team workflows.

Parallel Testing Across Multiple Simulators

One of Xcode Cloud's standout features is its ability to run your tests in parallel across multiple device configurations in the cloud. This means you can:

Test on multiple iOS versions simultaneously
Verify your app works across different device sizes (iPhone SE, iPhone Pro Max, iPads, etc.)
Catch device-specific bugs early
Do all of this without blocking your local development machine

This cloud-based parallel testing capability is particularly valuable because it prevents you from having to tie up your local machine running lengthy test suites, and it catches edge cases you might not test for locally.

My macOS App Deployment Workflow with Xcode Cloud

Here's how I use Xcode Cloud to build and deploy Edge Debug Helper, my macOS SwiftUI developer tool:

1. Automatic Builds on Push

I've configured my workflow to trigger whenever I push to my main branch. This ensures that every release-ready change gets built and tested automatically.

2. Wait for the Build

Once I push, Xcode Cloud takes over. It builds my app, runs my test suite, and notarizes the macOS app — all without any intervention from me. I can monitor progress in Xcode or the web dashboard.

3. Download the Notarized Build

When the build completes, I download the notarized app from the build artifacts through the web interface. This notarized binary is ready to be distributed outside the Mac App Store.

4. Create a Distributable DMG

I place the notarized app in the Scripts folder of my project repository (you can see this structure in the Edge Debug Helper SwiftUI/scripts directory).

I then run my create-build.sh script, which packages the notarized macOS app into a DMG file suitable for distribution. This script handles creating a professional-looking disk image with a custom background and window layout.

5. Create a GitHub Release

Finally, I:

Go to GitHub and create a new release
Tag the branch with the version number
Upload the DMG file
Add release notes describing what's new

This entire workflow is straightforward and requires minimal maintenance. Once set up, it just works—allowing me to focus on improving Edge Debug Helper rather than maintaining build infrastructure.

Conclusion: Is Xcode Cloud Right for Your macOS App?

For Edge Debug Helper—my macOS SwiftUI developer tool for debugging Ditto edge applications—Xcode Cloud has been a game-changer. After wrestling with GitHub Actions for months, the switch to Xcode Cloud felt like a breath of fresh air.

The key benefits for side projects:

Effortless setup: Configure workflows in minutes, not hours
Zero certificate management: Apple handles code signing automatically
Generous free tier: 25 hours/month is perfect for side projects
Cloud-based parallel testing: Test across multiple device configurations without tying up your Mac
Native integration: Everything works seamlessly with Xcode and App Store Connect

Is Xcode Cloud perfect for every project? No. If you're building cross-platform apps, need extensive customization, or require integration with non-Apple tools, GitHub Actions or other CI/CD platforms might be better choices.

But if you're a solo developer or small team working on an iOS or macOS app — especially a side project or developer tool — Xcode Cloud's simplicity and tight integration with Apple's ecosystem make it the obvious choice. It lets you focus on building your app instead of maintaining your build infrastructure.

And with 25 free compute hours per month now included with every Apple Developer Program membership, there's really no reason not to give it a try.

About Edge Debug Helper

Edge Debug Helper on GitHub is a free, open-source developer tool for debugging applications built with Ditto's offline-first database platform.

The tool helps developers working with edge computing challenges—whether you're building apps that use mesh networking, need to visualize CRDT-based data synchronization, or want to debug complex multi-device scenarios where data syncs peer-to-peer across Bluetooth and WiFi. I use Edge Debug Helper to help me see what's happening under the hood.

Frequently Asked Questions (FAQ)

How much does Xcode Cloud cost?

Xcode Cloud includes 25 compute hours per month for free with your Apple Developer Program membership ($99/year). If you need more capacity, paid plans start at $49.99/month for 100 hours, scaling up to $3,999.99/month for 10,000 hours. For most side projects and small teams, the free tier is sufficient.

Is Xcode Cloud better than GitHub Actions for macOS apps?

For macOS and iOS-only projects, Xcode Cloud is generally simpler and faster to set up. It automatically handles certificate management, code signing, and app notarization—tasks that require significant manual configuration in GitHub Actions. However, GitHub Actions offers more flexibility for cross-platform projects or complex custom workflows. According to 2025 developer statistics, 41% of iOS developers now use Xcode Cloud compared to 31% using GitHub Actions.

How do I set up Xcode Cloud for a macOS app?

Setting up Xcode Cloud takes just a few minutes:

Open your project in Xcode
Go to the Product menu and select "Xcode Cloud" → "Create Workflow"
Choose your triggers (branch pushes, pull requests, tags)
Configure build actions, testing, and distribution settings
Connect your source control repository (GitHub, GitLab, or Bitbucket)

No YAML files or custom scripts required—everything is configured through Xcode's interface.

Does Xcode Cloud automatically handle app notarization?

Yes, Xcode Cloud automatically notarizes macOS apps during the build process. This is a major advantage over GitHub Actions, where you would need to manually configure notarization scripts using notarytool or similar utilities. The notarized app is available as a downloadable artifact immediately after the build completes.

Can I use Xcode Cloud with SwiftUI apps?

Absolutely. Xcode Cloud works with all iOS, iPadOS, macOS, watchOS, and tvOS apps, regardless of whether they're built with SwiftUI, UIKit, or AppKit. It supports both Swift and Objective-C projects.

What are compute hours in Xcode Cloud?

A compute hour represents one hour of cloud execution time. For example, if your build and test workflow takes 10 minutes to complete, that consumes 0.17 compute hours (10/60). If you run 5 simultaneous tests that each take 12 minutes, that equals 1 compute hour total (5 × 12 minutes = 60 minutes).

Do I need to manage certificates and provisioning profiles with Xcode Cloud?

No, this is one of Xcode Cloud's biggest advantages. It automatically handles certificate management and code signing using your Apple ID credentials. You don't need to export certificates, store them as secrets, or use tools like Fastlane Match—Xcode Cloud manages everything for you.

Can Xcode Cloud run tests on multiple devices simultaneously?

Yes, Xcode Cloud can run your test suite in parallel across multiple iOS versions and device types (iPhone SE, iPhone Pro, iPad, etc.) simultaneously in the cloud. This helps catch device-specific bugs and significantly speeds up your testing workflow compared to running tests sequentially on a local machine.

How does Xcode Cloud compare to other CI/CD tools like Bitrise or CircleCI?

Xcode Cloud is the most tightly integrated solution for Apple platform development, with automatic certificate management and native Xcode integration. Tools like Bitrise offer more flexibility and cross-platform support, while CircleCI provides broader DevOps capabilities. The choice depends on your needs: choose Xcode Cloud for simplicity and Apple-ecosystem focus, or alternative platforms for more customization and multi-platform requirements.

What is Ditto and why would I use Edge Debug Helper?

Ditto is an offline-first database platform that enables apps to sync data peer-to-peer using mesh networking and CRDTs (Conflict-Free Replicated Data Types). It's used by companies like Alaska Airlines, Chick-fil-A, and the U.S. Air Force for mission-critical apps that must work reliably without constant connectivity. Edge Debug Helper is a developer tool that helps visualize and debug Ditto databases, making it easier to troubleshoot complex distributed data scenarios, mesh network synchronization, and edge computing challenges.

Sources

This article was informed by research from the following sources:

Hot Restart for iOS is not included in Visual Studio 2026: What .NET MAUI Developers Need to Know

Aaron LaBeau — Fri, 16 Jan 2026 16:03:23 +0000

If you're a .NET MAUI developer who's been enjoying the convenience of Hot Restart for iOS development on Windows, I have some bad news: this beloved feature didn't make it into Visual Studio 2026. For several developers, Hot Restart was one of the standout features that made mobile development accessible without the hassle of maintaining Mac hardware. Its removal has left many in the community frustrated and searching for alternatives.

What is Hot Restart?

Hot Restart was a game-changing feature that allowed developers to deploy and test .NET MAUI (and previously Xamarin) iOS apps directly to a physical iOS device from a Windows machine - no Mac required. Instead of going through the full build cycle that typically requires a Mac build host, Hot Restart streamlined the deployment process by pushing only code changes and resources to an existing app bundle already installed on your connected iPhone or iPad.

For Windows-based developers, this was huge. You could:

Test your app on real iOS hardware without owning a Mac
Avoid the complexity of setting up and maintaining a Mac build environment
Quickly iterate on your UI and business logic during development
Test hardware features like the camera, Bluetooth, and WiFi on actual devices

The traditional iOS development workflow requires you to pair Visual Studio with a Mac, ensure Xcode and all build tools are up to date, and maintain network connectivity between your Windows development machine and your Mac. Hot Restart eliminated all of that friction for day-to-day development tasks.

How React Native with Expo Go Works

If you're familiar with React Native development, Hot Restart worked similarly to Expo Go. Expo Go lets React Native developers test their apps on iOS and Android devices without owning a Mac or going through the full native build process. You simply scan a QR code, and your app loads on your device through the Expo Go client app.

However, both solutions share a critical limitation: they only work with certain types of apps. Expo Go can't handle third-party libraries that require custom native code - the moment you need to add a native module or framework that isn't already bundled with Expo, you have to switch to a development build, which requires the full native toolchain (including a Mac for iOS).

Hot Restart had a similar constraint. According to the official documentation, it didn't support static iOS libraries, certain frameworks, or XCFrameworks containing static libraries. This limitation is what ultimately led to its demise.

Why Did Microsoft Remove Hot Restart?

The short answer: XCFramework compatibility. As .NET MAUI matured, the team adopted XCFramework as the standard for packaging native iOS dependencies. The problem? Building with XCFramework requires macOS-specific build tools that simply aren't available on Windows.

In a GitHub discussion about the removal, developers pieced together the technical reasons. One contributor noted that "Building with XCFramework has never been supported in HotRestart due to the fact that some build tools are only available on MacOS." This architectural incompatibility meant Hot Restart couldn't evolve alongside the platform.

There's also an operational angle. Gerald Versluis, a Microsoft engineer, commented on a LinkedIn post about the feature's removal:

"I'm glad the experience was great for you! Unfortunately I don't think that many people were using it and the maintenance effort on it was pretty high. So that's not a great combination."

In other words, Hot Restart was expensive to maintain for what Microsoft perceived as a relatively small user base. The team had to make a tough call between continuing to support a feature with significant technical debt or focusing resources elsewhere.

Could Hot Restart have worked with XCFramework? Theoretically, yes - if Microsoft pre-built and packaged XCFrameworks with each .NET MAUI release. But as developers in the GitHub thread acknowledged, this would create a substantial maintenance burden and potentially introduce versioning and compatibility headaches.

What Does This Mean for .NET MAUI Developers?

If you're currently using Hot Restart, you have a few options:

Stay on Visual Studio 2022 - Hot Restart is fully supported in Visual Studio 2022 (version 17.3 and later). If this feature is critical to your workflow, you can simply avoid upgrading to Visual Studio 2026 for now. Several developers in the community have stated they're doing exactly this. My gut feeling is that eventually a XCode release will break this feature, but until then you can continue to use Hot Restart.
Invest in Mac hardware - The traditional "Pair to Mac" workflow is now the standard approach for iOS development in Visual Studio 2026. You'll need a Mac on your network (or use a cloud-based Mac service) to build and deploy iOS apps.
Consider cloud Mac solutions - If purchasing Mac hardware isn't feasible, services like MacStadium or MacinCloud offer cloud-hosted Mac build agents that can integrate with your Visual Studio workflow.
Use a Mac with JetBrains Rider - JetBrains Rider is a cross-platform IDE that supports .NET MAUI development and runs on the Mac. It allows you to develop on a Mac and deploy to iOS devices using Hot Restart. While this is not a perfect solution, it is a solution that will allow you to continue testing iOS apps with Maui. This is what I do - when I need to test MacOS and iOS I use a Mac with Rider. When I want to test PC I use Windows with Visual Studio 2022/2026.

The bottom line is this: if you want to continue developing .NET MAUI apps for iOS, having access to macOS is no longer optional - it's a requirement. The brief window where Windows-only developers could build for iOS without Apple hardware has closed.

Final Thoughts

The removal of Hot Restart is disappointing for developers who relied on it, especially those working in resource-constrained environments or teams without dedicated Mac hardware. While Microsoft's reasoning makes sense from a technical and resource perspective, it does raise the barrier to entry for .NET MAUI development. When I worked at EY this was pretty amazing for developers because we didn't need to have two laptops to do development - one for Windows and one for Mac.

If Hot Restart was a critical part of your workflow, I'd encourage you to make your voice heard in the upcoming .NET MAUI community surveys. Microsoft has indicated they're open to feedback, and if enough developers demonstrate the value of this feature, there's a chance - however slim - that a solution could be reconsidered.

For now, though, if you're serious about .NET MAUI development for iOS, it's time to add a Mac to your development toolkit.

Sources

The Cascading Complexity of Offline-First Sync: Why CRDTs Alone Aren't Enough

Aaron LaBeau — Tue, 06 Jan 2026 16:32:39 +0000

Picture this: Three warehouse workers standing less than 400 feet apart, each holding a smartphone thousands of times more powerful than the computers that landed astronauts on the moon. They need to share inventory updates with each other to coordinate shipments. But the WiFi access point just went down, and there's no cellular signal inside the metal building. They can't share a single piece of data.

In 1969, NASA successfully transmitted telemetry data 238,900 miles through the vacuum of space to astronauts on the lunar surface. The communications equipment was primitive by today's standards—the entire Apollo Guidance Computer had less processing power than a modern calculator. Yet we solved that problem.

So why, in 2026, can't three people standing in the same building share data between devices that are literally millions of times more capable?

The answer isn't technological capability—it's architecture. We built cloud-dependent systems that require internet connectivity for everything. When that connectivity fails, our applications stop working, even though the devices themselves are perfectly functional.

After 30 years of building software systems, I've learned that every complex problem is solvable. But here's the catch: every solution introduces new complexity. The offline data synchronization problem isn't a single challenge—it's a cascade of interconnected problems where each solution reveals the next layer of difficulty.

This is the story of that cascade, and what it takes to truly solve it.

The Solution Cascade: How Each Fix Creates New Problems

Problem #1: The Cloud Dependency Trap

Modern mobile applications are built on a simple assumption: the cloud is always reachable. When a user updates data, it goes to a server. When another user needs that data, they fetch it from the server. The server is the single source of truth, the arbiter of conflicts, the coordinator of everything.
This architecture works beautifully—until it doesn't.

Airlines ground flights when connectivity fails. Healthcare workers can't access patient records in basements or rural clinics. Construction managers lose hours of productivity when they move between sites. Retail workers can't process transactions when the network goes down.

The problem isn't just complete outages. It's the "janky" networks—connections that drop every few minutes, bandwidth that fluctuates wildly, or latency that makes applications feel broken even when technically connected.

The Solution: Hardware First... Then Reality Sets In

The obvious answer is to throw hardware at the problem: deploy local servers at each site, add redundant network infrastructure, install cellular backup connections. You're essentially replicating your cloud infrastructure on-premises.

But this "solution" creates its own cascade of problems:

Capital costs: Servers, networking equipment, and redundant systems for every location
Operational burden: Each site needs monitoring, maintenance, updates, and eventual hardware replacement
Expertise requirement: Local IT staff or expensive managed services contracts
Single points of failure: The local server becomes the new bottleneck—if it fails, you're back to square one
Synchronization complexity: Now you need to sync between local servers and the cloud, managing conflicts at a new architectural layer

You've just traded one dependency for another, more expensive one.

The Better Solution: Offline-First Databases

Instead of fighting the hardware battle, move the database to where your users already are: on their devices. Let users read and write data locally with zero latency, regardless of network conditions. Sync changes peer-to-peer or through the cloud when connectivity is available.

This isn't just about adding a local cache—it's about architectural inversion. The device becomes the source of truth, not a mirror of the cloud. Your application works the same whether you're connected or not.

The New Problem: Sync Conflicts

But now you've introduced a new fundamental challenge: what happens when two devices edit the same data while offline, then try to sync?

Consider our warehouse scenario. Worker A marks a pallet as "shipped" on their device. Worker B, unable to reach the server, marks the same pallet as "damaged" on their device. Two hours later, when WiFi comes back online, which change wins?

Traditional database replication uses locks and transactions to prevent this—but locks require coordination, and coordination requires connectivity. You can't lock what you can't reach.

Problem #2: The Conflict Resolution Challenge

This isn't a theoretical problem. I've seen production systems lose data, duplicate orders, and corrupt inventory counts because they didn't properly handle offline conflicts. The naive solution—"last write wins"—loses data. And prompting users to manually resolve conflicts creates terrible user experiences. As developers we all know how bad it feels to try and merge a complex conflict with git - now think about how an average end user must feel and then you add on to this problem the UI designer needs to design something that is usable. Sigh. This is a bad experience.

The Solution: CRDTs (Conflict-Free Replicated Data Types)

CRDTs are mathematically-sound data structures designed for distributed systems. They have a beautiful property: replicas can be updated independently and merged automatically, with guaranteed convergence to the same state.

The key is that CRDTs use deterministic merge rules based on data type semantics and causal ordering, not arbitrary timestamps. A counter CRDT knows how to merge increments. A set CRDT knows how to merge additions and removals..

Typically developers use business logic on top of CRDTs—perhaps a LWW-register with vector clocks, or a workflow state machine that respects causal dependencies. The CRDT guarantees the underlying data merges correctly; your application logic defines what "correct" means for your business case.

The New Problem: Getting Data to Sync More Often

Here's where most teams discover that solving conflict resolution doesn't mean you've solved sync. Your CRDTs can perfectly resolve conflicts—but only when devices actually connect and exchange data.

In our warehouse scenario, workers might spend 15 to 20 minutes offline before WiFi comes back. By that time, they've made dozens of decisions based on stale data. The CRDT will eventually make everything consistent, but "eventual" can mean "too late for business needs."

Problem #3: The Single Transport Limitation

The typical approach is to wait for a stable WiFi or cellular connection. But what if we could make devices sync more frequently by using whatever connectivity is available?

Modern smartphones have multiple radios: WiFi, cellular, and Bluetooth Low Energy. Tablets and IoT devices have similar capabilities. Why not use them all?

The Solution: Multi-Transport Mesh Networking

Instead of depending on a single transport, build a mesh where devices communicate directly with each other using whatever works: Bluetooth LE when devices are close, peer-to-peer WiFi when available, LAN when on the same access point, or cellular/internet when connected to infrastructure.

I wrote about this extensively in my article on transport multiplexing, but the key insight is simple: decentralized mesh networks offer multiple pathways for communication, eliminating single points of failure.

In the warehouse, even with WiFi down, workers can sync directly device-to-device via Bluetooth LE or peer-to-peer WiFi. Data flows through the mesh, hopping from device to device until it reaches everyone who needs it.

The New Problem: Intelligent Transport Selection

But now you face a new challenge: how do you decide which transport to use, and when?

Each transport has different characteristics:

WiFi: 50-100+ Mbps, but requires access points and different devices might have different versions of WiFi which can limit distance and speeds (WiFi 5, 6, 6e, 7, etc)
Bluetooth LE: ~2 Mbps, works peer-to-peer, lower power
Peer-to-Peer WiFi: High bandwidth, no infrastructure needed, but platform-specific (Apple AWDL vs WiFi Direct )
Cellular: Variable bandwidth, requires subscription, costs money

Your mesh networking solution needs to constantly evaluate: Which transport is available? Which offers the best performance right now? How do you handle transitions when a transport fails mid-sync?

Problem #4: Network Instability and Transport Switching

Networks in the real world aren't clean. Connections don't just work or fail—they degrade. You get the "janky" networks I mentioned earlier: a Bluetooth connection that drops packets, a WiFi signal that fluctuates, a cellular connection that's technically up but practically unusable.

The Solution: A Transport Multiplexer

You need intelligence sitting between your sync engine and the various transports—a multiplexer that can:

Monitor the health of each transport in real-time
Dynamically switch between transports based on conditions
Fragment data across multiple transports simultaneously
Reassemble packets that arrived via different paths

Ditto calls this the "Rainbow Connection" because each transport is like a different color of the rainbow, all working together to move data.

The New Problem: Bandwidth Constraints

Now you can use multiple transports and switch intelligently between them. But you've just surfaced another problem: Bluetooth LE operates at roughly 2 Mbps, while WiFi can handle 50-100+ Mbps. That's a 25-50x difference.

If your sync protocol tries to send too much data, Bluetooth becomes a bottleneck. The mesh might technically work, but performance becomes unacceptable for business operations.

Problem #5: The Document Flooding Disaster

Here's where most CRDT implementations hit a wall. The typical approach is to sync entire documents whenever any field changes.

Let's do the math. Say you have:

Documents averaging 100KB each
50 devices in the mesh
10 updates per minute across the mesh

If every field change triggers a full document broadcast, you're looking at:

100KB × 50 devices × 10 updates/min = 50MB/minute = 3GB/hour

Over Bluetooth LE at 2 Mbps, 50MB takes over 3 minutes to transfer. Your mesh can't keep up. Updates queue behind each other, lag compounds, and the system grinds to a halt.

This isn't a theoretical problem. I've seen this exact scenario kill production deployments. The CRDT works perfectly in the lab with a few devices, but collapses under real-world load.

The Solution: Property-Level Diffs (Delta Sync)

The answer is to sync only what changed. If a document has 20 fields and only the status field changed, send only that one property update—not the entire 100KB document.

This is harder than it sounds. You need to:

Track changes at the property level within your CRDT
Calculate diffs efficiently
Maintain causality across partial updates
Handle cases where different properties on the same document change on different devices

State-based CRDTs traditionally sync full state. Some research papers discuss "delta-state CRDTs" that send incremental changes, but implementing them correctly is complex. You need version vectors, hybrid logical clocks, or similar mechanisms to track causality at the property level.

When implemented well, property-level sync reduces bandwidth by orders of magnitude. That 100KB document? Maybe you're now sending 200 bytes. Suddenly Bluetooth LE looks much more viable.

The New Problem: Broadcast Storm Inefficiency

But even with property-level diffs, you're still broadcasting. Every update goes to every device in the mesh, whether they need it or not.

In an enterprise deployment, this gets expensive fast. A retail chain might have thousands of stores, each with dozens of devices. Not every device needs every piece of data.

Problem #6: Indiscriminate Data Propagation

Broadcasting everything creates several problems:

Bandwidth waste: Sending data that recipients don't need
Storage waste: Devices store data they'll never use
Security concerns: Devices see data they shouldn't access
Battery drain: Radios constantly active processing irrelevant updates

The Solution: Query-Based Subscriptions

Instead of broadcasting everything, let devices declare what they want using queries:

SELECT * FROM inventory
WHERE storeId = 'store-seattle-42'
  AND status IN ('active', 'pending')
  AND lastUpdated >= '2025-01-01'

Now your sync engine only sends documents matching the subscription. When a document stops matching (because status changed to archived, for example), it's automatically removed from the device.

This is a fundamental architectural shift. You're moving from "sync everything and let the application filter" to "sync only what's needed." The database itself becomes aware of what data should exist on which devices.

The New Problem: Data Lifecycle and Eviction

Query-based subscriptions solve propagation, but introduce yet another challenge: how do you safely delete data?

In a distributed system with CRDTs, deletion is complex. You can't just remove a document—other devices might still have operations referencing it. If Device A deletes a document while Device B is offline, then Device B comes back online with an update to that "deleted" document, what happens?

The standard CRDT solution is "tombstones"—you mark documents as deleted but keep metadata around so you can resolve conflicts. But tombstones accumulate forever, consuming storage.

Problem #7: Safe Data Eviction

You need to safely remove data—both documents that no longer match queries and deleted documents—without breaking causality or losing conflict resolution capabilities.

The Solution: Query-Driven Eviction

The elegant solution is to make eviction a natural consequence of subscriptions rather than a separate garbage collection problem:

Subscription-Based Lifecycle: Documents are automatically removed from a device when they no longer match any active subscription query
Automatic Cleanup: Once a deleted document stops matching subscription queries (because it's marked deleted), it's automatically evicted from devices

For example, if your subscription is:

SELECT * FROM orders
WHERE status != 'completed' AND storeId = 'store42'

When an order's status changes to completed, it automatically evicts from your device—no separate garbage collection needed. The same principle works for deletions: mark the document as deleted, and if "deleted" documents don't match your queries, they evict automatically.

This approach requires:

Hybrid Logical Clocks (HLC) to track causality even when device clocks drift
Incremental query evaluation to detect when documents stop matching
Grace periods to account for devices that might be offline temporarily

The key insight: instead of building a separate eviction protocol, let the query subscription system handle it. Data lifecycle becomes declarative—you specify what you want, and the system manages what stays and what goes.

The New Problem: Implementation Complexity

And here's where we arrive at the final challenge: building all of this correctly is incredibly hard.

Why This Is Hard to Build

Let me be direct: after three decades of building distributed systems I can confidently say that implementing this stack correctly is a multi-year engineering effort.

Here's what you're really signing up for:

Multi-Transport Networking

Each transport has platform-specific APIs and quirks:

iOS uses Apple Wireless Direct Link (AWDL) for peer-to-peer WiFi
Android uses WiFi Aware or WiFi Direct
Bluetooth LE behaves differently across platforms and OS versions
Discovery protocols (mDNS, BLE advertising) need tuning for battery life vs responsiveness

You need to handle graceful degradation, automatic reconnection, and intelligent fallback between transports.

CRDT Implementation and Optimization

State-based CRDTs are conceptually simple but have serious practical challenges:

Metadata overhead: Version vectors grow with the number of devices
Merge complexity: Combining states efficiently at scale
Property-level granularity: Most academic papers describe document-level CRDTs, not field-level
Tombstone accumulation: Growing garbage that impacts performance

You need a production-grade CRDT implementation optimized for mobile constraints.

Sync Protocol Design

Your protocol needs to:

Calculate diffs efficiently between device states
Compress payloads for bandwidth-constrained transports
Handle partial sync over unreliable connections
Resume interrupted transfers
Avoid thundering herd problems when many devices sync simultaneously

Query Engine Integration

Query-based subscriptions require:

A query parser and optimizer
Incremental view maintenance algorithms
Indexing for efficient query evaluation
Integration with the CRDT layer so updates trigger query re-evaluation

Testing at Scale

You can't just unit test this. You need:

Network simulation with realistic latency, packet loss, and bandwidth constraints
Large-scale mesh simulations with hundreds of devices
Chaos testing—randomly disconnecting devices, corrupting data, simulating clock drift
Platform-specific testing across iOS, Android, and other targets
Performance benchmarking under load

I've seen teams underestimate this by 10x or more. What looks like a few months of work turns into years.

The NASA Analogy: Systematic Problem Solving

The Apollo program faced similar cascading complexity. Getting to the moon wasn't a single problem—it was a stack of interconnected challenges where each solution revealed new obstacles.

They needed rockets powerful enough to escape Earth's gravity.

Solution: staged rockets. But now they needed to figure out how to rendezvous in orbit.

Solution: the Lunar Orbit Rendezvous approach. But now they needed a way for astronauts to survive re-entry heat.

Solution: heat shields. But now they needed guidance systems accurate enough to navigate in space. And so on.

NASA succeeded not by finding one brilliant solution, but by systematically working through each layer of complexity. They built subsystems, tested them independently, integrated them carefully, and refined relentlessly.

Offline-first data sync requires the same systematic approach. You can't just drop in a CRDT library and call it done. You need the full stack:

Offline-first database
CRDT-based conflict resolution
Multi-transport mesh networking
Intelligent transport multiplexing
Property-level delta sync
Query-based subscriptions
Causality tracking and safe eviction

Each component must work correctly in isolation and integrate seamlessly with the others.

What Complete Solutions Look Like

This is why comprehensive platforms have emerged. Building this stack from scratch takes years and specialized expertise. But the good news is that the problem is solved—you can use platforms that have done the engineering work.

Let me show you what a complete solution looks like, using Ditto as a concrete example (since it's the platform I work with daily and know inside-out).

Architecture: Edge P2P Query-Correct Sync

The fundamental shift is from "server-controlled sync" to "edge P2P query-correct sync."

Traditional architecture:
Device -> WiFi/Cellular -> Server -> WiFi/Cellular -> Device

Edge-first architecture:
Device -> Direct P2P -> Device
Device -> Mesh Network -> Device (with optional server sync)

The database lives on the device. Sync happens peer-to-peer using whatever transport works. The server (if present) is just another peer, not a required coordinator.

Multi-Transport Mesh with Multiplexer

Ditto's mesh automatically uses:

Bluetooth LE: For close-range, low-power connectivity
Local Area Network (LAN): When devices share a WiFi access point
Peer-to-peer WiFi: Platform-specific (AWDL on iOS, WiFi Aware on Android)
WebSockets/Internet: For connecting to servers or remote peers

The multiplexer (Rainbow Connection) intelligently switches between transports and can even fragment data across multiple simultaneous connections.

Property-Level CRDT Sync

Instead of syncing 100KB documents, Ditto syncs field-level changes. A document with 20 fields where one field changed? You're syncing just that field's update—typically hundreds of bytes instead of kilobytes.

The CRDT implementation uses:

MAP types for objects (add-wins semantics)
REGISTER types for simple values (last-write-wins)
Counters and other specialized types as needed

Each field is independently tracked, so concurrent updates to different fields on the same document merge cleanly.

Query-Based Subscriptions with Incremental View Maintenance

Here's what it looks like in practice:

// Register a subscription - determines what data syncs to this device
const subscription = ditto.sync.registerSubscription(
  `SELECT * FROM orders
   WHERE storeId = 'store-seattle-42'
     AND status != 'completed'`
)

When an order's status changes to completed, it automatically evicts from devices that have this subscription. The sync engine evaluates queries incrementally—updates trigger query re-evaluation without full table scans.

This solves multiple problems at once:

Bandwidth efficiency: Only sync relevant data
Storage management: Devices don't accumulate irrelevant documents
Security: Devices only receive data matching their authorization scope
Automatic cleanup: Documents evict when they stop matching

Query-Driven Data Lifecycle

Ditto takes a unique approach to eviction by making it a natural consequence of query subscriptions rather than a separate garbage collection process:

Automatic Eviction: When a document no longer matches any active subscription on a device, it's automatically removed. This works for both state changes (like an order moving to "completed" status) and deletions.

Deletion Handling: When you delete a document in Ditto, it's marked as deleted in the CRDT. If your subscription queries exclude deleted documents (which is typical), the deleted document automatically evicts from devices that don't need it.

Causality Tracking: Ditto uses hybrid logical clocks (HLC) to maintain causality, ensuring that late-arriving updates are handled correctly even after eviction. The system tracks enough metadata to resolve conflicts without keeping full document tombstones forever.

This happens automatically—you don't manually manage data lifecycle. You just define what data each device needs via subscriptions, and Ditto handles the rest.

The Path Forward

Here's what I tell teams evaluating offline-first solutions:

Don't underestimate the complexity. This isn't just "add a CRDT library and you're done." Each layer of the problem is harder than it first appears, and the integration between layers is where most of the difficulty lies.

Decide: Build or Buy. If you have a multi-year timeline, deep expertise in distributed systems, and can dedicate a team to this problem, building from scratch is possible. Most teams should use a comprehensive platform—the engineering effort saved is enormous.

Think Edge-Native. The future of computing is increasingly decentralized. IoT devices, mobile workers, autonomous systems—these all need to operate independently and sync opportunistically. Architecting for edge-native scenarios now positions you better for what's coming.

Test Realistically. Whatever solution you choose, test it under realistic conditions: flaky networks, limited bandwidth, devices coming online and offline at random, simultaneous updates across many peers. Lab tests don't surface the hard problems.

Conclusion: Engineering Is About Tradeoffs

The warehouse problem I started with—three workers 400 feet apart who can't share data—is completely solvable. So is the broader challenge of offline-first data sync. We have the technology, we understand the mathematics, and we've built production systems that work at scale.

Ditto has solved these problems comprehensively with its offline-first architecture that keeps applications working regardless of network conditions, peer-to-peer mesh networking that intelligently multiplexes across multiple transports, and CRDT-powered conflict resolution that automatically handles concurrent updates. The platform combines property-level delta sync, query-based subscriptions, and automatic data lifecycle management into a production-ready system that developers can integrate in days rather than years.

But it's not simple. Like NASA's moon missions, success requires systematically solving each layer of cascading complexity. You need offline-first databases, CRDT-based conflict resolution, multi-transport mesh networking, intelligent multiplexing, property-level sync, query-based subscriptions, and safe eviction protocols—all working together.

Every solution creates new problems. That's not a bug; it's the nature of complex engineering. The question is whether you're prepared to solve all the problems, not just the first few.

After 30 years of building distributed systems, I've learned that the teams who succeed are the ones who understand this complexity upfront, respect the engineering effort required, and choose their battles wisely. Sometimes that means building from scratch. More often, it means leveraging platforms that have already done the hard work.

The offline-first future is here. The question is whether your architecture is ready for it.

Frequently Asked Questions

Why can't devices sync data without WiFi or cellular?

Devices absolutely can sync without WiFi or cellular—using technologies like Bluetooth LE and peer-to-peer WiFi. The limitation isn't hardware; it's architecture. Most applications are built assuming cloud connectivity and don't include peer-to-peer mesh networking capabilities. Modern smartphones have multiple radios (Bluetooth, WiFi Direct, etc.) that enable direct device-to-device communication, but applications need to be specifically designed to use these capabilities.

What are CRDTs and why aren't they enough for offline sync?

CRDTs (Conflict-Free Replicated Data Types) are data structures that automatically resolve conflicts when multiple devices edit the same data offline. They guarantee eventual consistency using mathematical properties. However, CRDTs alone don't solve the complete sync problem because they don't address: when and how data syncs (transport layer), bandwidth efficiency (most implementations send full documents), what data each device should receive (subscription management), or when to safely delete data (eviction protocols). CRDTs are the foundation, not the complete solution.

How does mesh networking solve connectivity problems?

Mesh networking creates multiple pathways for data to flow between devices. Instead of all devices connecting to a central hub (like a WiFi access point), devices connect directly to nearby peers. Data can "hop" from device to device until it reaches its destination. If one connection fails, data routes through alternative paths. This eliminates single points of failure and enables operation even when infrastructure (WiFi, cellular) is unavailable. Modern mesh implementations use multiple transports simultaneously—Bluetooth LE, peer-to-peer WiFi, and LAN connections—maximizing resilience.

What is a transport multiplexer?

A transport multiplexer is an intelligent switching layer that manages multiple network transports (WiFi, Bluetooth LE, cellular, etc.) simultaneously. It monitors the health and performance of each available transport in real-time, dynamically routes data through the best available option, and can even fragment data across multiple transports at once. Think of it like a smart router at the device level—it ensures data flows using whatever connectivity is available, automatically failing over when transports become unavailable or degraded.

Why do most CRDT implementations have bandwidth problems?

Traditional CRDT implementations sync entire document states when any field changes. If you have a 100KB document with 20 fields and one field update, most systems broadcast the full 100KB to all peers. In bandwidth-constrained environments (Bluetooth LE operates at ~2 Mbps), this creates bottlenecks. With many devices and frequent updates, the math breaks down: 100KB × 50 devices × 10 updates/minute = 50MB/minute, which exceeds the capacity of low-bandwidth transports. This "document flooding" problem makes naive CRDT implementations impractical at scale.

What are property-level diffs and why do they matter?

Property-level diffs (also called delta sync) means sending only the changed fields rather than entire documents. If a document has 20 fields and one field changes, you transmit just that field's new value—typically a few hundred bytes instead of kilobytes. This reduces bandwidth by 10-100x or more, making sync practical over constrained transports like Bluetooth LE. Implementing this correctly requires tracking causality at the field level, calculating diffs efficiently, and maintaining CRDT semantics for partial updates.

How does query-based sync differ from full replication?

Full replication broadcasts all data to all devices, letting applications filter what they need. Query-based sync inverts this: devices declaratively specify what data they want using queries (e.g., SELECT * FROM orders WHERE storeId = 'seattle'), and the sync engine only sends matching documents. When a document stops matching (because a field changed), it's automatically removed from that device. This reduces bandwidth (only send relevant data), manages storage automatically (devices don't accumulate irrelevant documents), improves security (devices only receive authorized data), and enables automatic cleanup (documents evict when they stop matching).

What is causality tracking in distributed systems?

Causality tracking means recording the order of operations across distributed devices so you can determine which updates happened before others, even when clocks aren't synchronized. This is critical for conflict resolution and safe data deletion. Common techniques include vector clocks (each device maintains a counter of operations from all known peers) and hybrid logical clocks (combining physical timestamps with logical counters). Causality tracking lets you say "Device A's update happened before Device B's update" even if Device A's clock was wrong, ensuring correct conflict resolution and safe eviction of old data.

What makes offline-first sync implementation difficult?

The difficulty comes from the intersection of multiple complex problems: distributed systems theory (CRDTs, causality, consistency), networking (multi-transport protocols, discovery, NAT traversal), platform-specific APIs (iOS vs Android vs web), performance optimization (minimizing bandwidth, battery, storage), and security (distributed authorization without central authority). Each problem alone is manageable, but they interact in complex ways. Additionally, testing requires simulating realistic network conditions at scale, which most teams aren't equipped to do. The full implementation is typically a multi-year engineering effort requiring specialized expertise.

How does Ditto's approach differ from other CRDT implementations?

Ditto provides a complete integrated stack rather than just CRDT primitives. Key differentiators include: property-level delta sync (most implementations sync full documents), query-based subscriptions with automatic eviction (most broadcast all data and require manual data lifecycle management), multi-transport mesh with intelligent multiplexing (most use single transports), and cross-platform device discovery and connection management. The integration between layers—how the query engine triggers sync, how subscriptions control data lifecycle, how the multiplexer optimizes for bandwidth constraints—is where much of the value lies.

When should you use an offline-first database?

Use offline-first databases when:

1 - Users need to work in environments with unreliable or absent connectivity (field work, healthcare, aviation, retail, construction)

2 - Your application requires low-latency interactions even when cloud-connected

3 - Data must sync peer-to-peer without routing through servers

4 - High availability is critical—the app must keep working regardless of network conditions

5 - You need eventual consistency across distributed devices. Don't use offline-first when you have no offline use case, or can tolerate application unavailability during network outages.

About Me

I am a Developer Advocate at with over 30 years of experience building distributed systems, mobile applications, and developer tools currently working as a Developer Advocate @ Ditto.

Previously I was an Associate Director/Tech Lead of Client Technologies - Mobile Technologies @ EY and Senior Developer Advocate/Principal Software Engineer @ Couchbase.

The .NET Cross-Platform Showdown: MAUI vs Uno vs Avalonia (And Why Avalonia Won)

Aaron LaBeau — Mon, 22 Dec 2025 15:42:04 +0000

I've been writing .NET code since the first beta. Over three decades of professional development, I've seen the good, the bad, and the abandoned. I love C#—it remains one of the most elegant languages for building production software. But Microsoft's UI framework strategy? That's been a different story.

Recently, I needed to port a tool I'd built in SwiftUI to Windows. What started as a simple requirement turned into a deep dive through Microsoft's fragmented ecosystem and ultimately led me to abandon MAUI entirely. Here's what I learned.

The Project: Edge Debug Helper Needs Windows Support

In my current role as a Developer Advocate at Ditto, I work with developers building applications using Ditto—an offline-first mobile database platform that enables peer-to-peer mesh networking and real-time data synchronization. Ditto solves a critical problem: applications that need to function reliably regardless of network connectivity. Using Conflict-Free Replicated Data Types (CRDTs), Ditto automatically handles data synchronization across devices via Bluetooth, Wi-Fi, or LAN without requiring constant cloud connectivity. It's particularly valuable for field operations, collaborative applications, and scenarios where internet access is unreliable or unavailable.

I wrote Edge Debug Helper to debug Ditto apps when working with the MongoDB Connector. SwiftUI let me prototype quickly—within days I had a functional macOS tool. But as I started working with developers on Windows, the limitation became obvious: I needed cross-platform support.

My first instinct was Rust. I'm learning the language, and it offers genuine cross-platform capabilities. But the learning curve was steeper than I anticipated with limited UI libraries, and I was spending more time fighting the borrow checker than building features.

Then I thought: why not return to .NET? I've used it throughout my entire career. Like SwiftUI, I should be able to get something running quickly. C# is a joy to work with. The question wasn't whether to use .NET—it was which .NET UI framework to use.

Microsoft's Platform Abandonment Problem

Here's where things get frustrating. Microsoft has a terrible track record with UI frameworks. Let me count the casualties:

Windows Forms - Still technically supported, but ancient
WPF - 20 years old, Windows-only
Silverlight - Abandoned, leaving countless developers stranded
UWP - Dead, officially discontinued after promising write-once, run-everywhere
WinUI - Uncertain future
Xamarin - Forcibly migrated to MAUI with support ending May 2024
MAUI - The latest attempt, and spoiler: it's not great for desktop apps

This pattern represents millions in wasted development effort across the industry. Every few years, Microsoft pivots to a new framework, and developers are left rewriting applications or maintaining legacy code. It's exhausting.

I stumbled across this blog post from Avalonia comparing WinUI, WPF, and UWP. Reading their analysis of Microsoft's broken strategy made me smile—finally, someone saying what we've all been thinking. The constant churn isn't sustainable. Microsoft cannot be trusted with long-term UI framework investment.

But I still needed to build my app. So I started with the obvious choice: MAUI.

MAUI: The Choice That Disappointed

MAUI is Microsoft's official cross-platform framework, so naturally, I tried it first. The experience was terrible when using it to target desktop apps.

macOS Performance Was Abysmal

MAUI on macOS uses Mac Catalyst, not native AppKit. The performance was horrible. This isn't a full macOS application—it's an iOS app awkwardly shoehorned onto the desktop. For a developer tool that needs to feel responsive, this was unacceptable.

Theming Was Painful

Getting a Windows app to look decent took far too much work. Making the same app look nice on macOS? Even worse. The default controls feel out of place on every platform.

Signing and Packaging Was a Nightmare

To ship a proof-of-concept to a colleague's Windows machine—without requiring dev tools—I needed to sign the application. The process was painful.

I get it: Apple requires signing too. But Xcode Cloud auto-signs builds and makes this essentially a non-issue for macOS/iOS developers. Microsoft provides no equivalent service. You can cobble together GitHub Actions workflows, but they're complex, especially for someone who hasn't done full-time .NET development since 2019.

The Jank Persists in .NET 9

Even in the latest stable release, MAUI has rough edges. I tried the .NET 10 beta hoping CollectionView improvements would help, and they did—but relying on beta releases for basic functionality isn't acceptable.

Linux Support? Forget About It

MAUI's Linux support is effectively non-existent. This became critical when I bought a uConsole—a portable Linux device perfect for testing Ditto's peer-to-peer mesh networking. The moment Linux became a requirement, MAUI was out.

MAUI isn't ready for production cross-platform development that need to target MacOS, Windows, and Linux . Maybe it'll improve, but I've heard that promise before with Silverlight, UWP, and every other framework Microsoft has abandoned.

Uno Platform: Impressive DevTools, But Still Some Jank

Next, I explored Uno Platform. This framework impressed me immediately.

The Developer Tools Are First-Class

Uno's tooling is everything MAUI should be but isn't. Hot Design with AI assistance, real-time XAML updates, Figma integration—these features make writing XAML applications genuinely enjoyable. I can't emphasize enough how good Uno's developer experience is compared to MAUI. They're leading the industry in making XAML development productive.

The Project Structure Is Complex

Despite the excellent tooling, Uno's project structure left something to be desired. For someone returning to full-time .NET development after several years, the complexity was daunting. Multiple projects, conditional compilation, platform-specific implementations—it all felt heavier than necessary.

Linux Support Was Better, But Still Not Great

Uno supports Linux, which put it ahead of MAUI. But the support isn't quite production-ready. I needed something more mature.

There Was Still Some Jank

I documented issues I encountered during livestreams on my YouTube channel. To Uno's credit, the team released updates that resolved some of these problems. They clearly care about the developer community, and my interactions with the team have been extremely positive.

Uno Platform is impressive. If Avalonia hadn't worked out, Uno would have been my choice. But then I discovered something that changed everything.

The Game Changer: Avalonia's Packaging Solution

I shelved the project for a few months—my wife and I had a baby in September. When I picked it back up in October, I was nearly ready to commit to Uno. Then I saw this LinkedIn post from Mike at Avalonia about their new packaging solution.

This was like Xcode Cloud, but for .NET. You can tell an AI assistant: "Package my Avalonia app for macOS as a signed DMG," and two minutes later, you have a production-ready, signed application. No certificate wrangling. No build scripts. No wasted afternoons.

Here's the kicker: you can build and sign macOS DMG files from Windows. This is typically impossible through conventional methods.

I got excited. Really excited. Excited enough to try Avalonia for the first time, even though I was nearly finished with my Uno POC.

Building with Avalonia: Fast and Productive

I started with two screens: a login screen and a main UI displaying connected Ditto SDK peers. If Avalonia worked well for these screens and the packaging was solid, I'd migrate from Uno.

Documentation Was Clear and Comprehensive

Both screens came together fast. Avalonia's documentation is excellent—clear, comprehensive, with good examples. Controls worked as expected. Everything felt solid.

The First UI Wasn't Pretty

My initial attempt didn't look great. I explored theming options and found Material Design support. But it wasn't complete Material Design—it was an older version with glitches like outline text not rendering properly.

I tried Fluent Design next, but it looks terrible on macOS. Nothing close to the polished UI that SwiftUI provides out of the box.

I was getting discouraged. Then I discovered SukiUI.

SukiUI: The Missing Piece

SukiUI is an incredible project—a comprehensive desktop UI library specifically for Avalonia. With minimal setup (just following the installation instructions), my app immediately looked more attractive.

I switched to their GlassCard control, and suddenly my app looked really nice. Professional. Polished. Modern.

Next, I refactored my navigation to use SukiUI's Side Menu. The transformation was remarkable. My app went from "functional but ugly" to "something I'd actually want to use."

Not Everything Was Perfect

The Dock control had some issues. I posted in their forums, and they recommended upgrading to a nightly build. Since I wanted to stay on stable releases, I simply removed the Dock code temporarily. This is active development—issues get fixed quickly.

Performance: Avalonia Edges Out Uno

I didn't see massive performance differences between Uno and Avalonia. Both render quickly on my target platforms. But Avalonia seemed slightly better in memory usage, and from a UI standpoint, I loved how my app looked and felt with SukiUI more than my Uno implementation.

Performance on Windows, macOS, and Linux was solid across the board.

Avalonia's Bright Future

Two developments have me particularly excited about Avalonia's roadmap:

Next-Generation Rendering

Avalonia is exploring new rendering with Impeller, the rendering engine that Google wrote for Flutter. Impeller delivers smooth, consistent performance, higher average frame rates, and reduced VRAM use. It is unapologetically GPU-first, making it ideal for modern hardware where predictable performance and power efficiency are essential.

This isn't ripping out the stable SkiaSharp backend. Avalonia is taking a measured approach, offering multiple rendering backends so developers can choose what works best for their use cases. Stability first, with experimental options for those who need cutting-edge performance.

MAUI Linux Rendering

Avalonia is now providing the rendering layer for MAUI on Linux. Read that again: Microsoft's own framework is depending on Avalonia for Linux support. That's a remarkable validation of Avalonia's technical foundation.

The Verdict: Avalonia Won

After building POCs in MAUI, Uno, and Avalonia, I chose Avalonia. Here's why:

SukiUI Makes My App Beautiful

The transformation SukiUI provides is remarkable. My app looks professional with minimal effort, and working with the component library has been smooth.

Documentation and Community Are Strong

Avalonia's documentation is comprehensive and clear. The community is active and helpful. When I have questions, I get answers quickly.

DevTools and Parcel Are Essential

Avalonia's DevTools and Parcel are game-changers. I'll admit Uno's designer tools are better than Avalonia's DevTools in some ways, but Parcel—especially the packaging and signing automation—more than makes up for it.

The subscription cost is affordable, even for small teams. If it means I don't have to deal with signing and packaging nightmares, it's worth every penny.

Performance Is Solid Across All Platforms

Windows, macOS, and Linux all perform well. No Mac Catalyst compromises. No platform-specific jank. Just consistent, responsive applications.

I'm Past the POC Phase

With Avalonia, I moved from proof-of-concept to feature development quickly. Good documentation and extensive example code mean I'm productive, not fighting the framework.

What About Uno?

Uno Platform is genuinely impressive. Their developer tooling is industry-leading, and the team clearly cares about developers. If you're heavily invested in the Microsoft ecosystem or need the specific features Uno provides, it's a solid choice.

For my project, Avalonia was the better fit. But Uno deserves recognition for pushing the entire .NET UI ecosystem forward with their tooling innovations.

What About MAUI?

I can't recommend MAUI for serious cross-platform development that need desktop support for MacOS, Linux, and Windows. The macOS performance is poor, Linux support is essentially non-existent, and the rough edges suggest it's not production-ready. Maybe Microsoft will fix these issues, but I've been a .NET developer for three decades. I've seen this pattern before. In my humble opinion Microsoft is not investing enough in Maui when you see small companies like Uno and Avalonia making better solutions than the huge company that is Microsoft. How serious is Microsoft about Maui when Uno and Avalonia are just SO much better?

Avalonia works today. I'm not waiting for Microsoft's next pivot.

Moving Forward

I'm excited to finish my app over the holiday break. Avalonia has proven to be fast, stable, and genuinely cross-platform. The documentation is excellent, the community is strong, and the tooling removes the pain points that have plagued .NET desktop development for years.

After 30 years of .NET development—through Windows Forms, WPF, Silverlight, UWP, Xamarin, and MAUI—I've finally found a framework I can trust for the long term. It's not from Microsoft, and maybe that's exactly why it works.

If you're building cross-platform .NET applications, give Avalonia a serious look. It's what MAUI should have been.

Transport Multiplexing in Mobile Sync: Why Multi-Transport Beats Single-Transport Systems

Aaron LaBeau — Wed, 29 Oct 2025 19:28:26 +0000

Building reliable data synchronization in distributed systems is one of the toughest challenges for mobile developers. The core problem: most synchronization systems rely on single-transport architectures—typically WiFi or cellular alone—creating fundamental limitations that cause failures when network conditions change.

The solution is transport multiplexing: intelligently switching between multiple network transports (WiFi, Bluetooth LE, peer-to-peer WiFi, and cellular) based on real-time conditions. This approach, combined with mesh networking, transforms rigid single-transport systems into adaptive, resilient architectures that maintain connectivity regardless of environmental challenges.

This matters every day in airline operations, healthcare facilities, construction sites, and retail environments where field workers need reliable data access. Traditional cloud-first architectures break down at the edge when connectivity is intermittent, expensive, or unavailable. Transport multiplexing solves this by using whatever connectivity is most efficient at any given moment, automatically adapting without application intervention.

Network Transport Comparison: Why Single-Transport Systems Fail

Most synchronization systems rely on a single network transport – typically TCP/IP over WiFi or cellular. This creates a fundamental problem: no single networking technology excels in all environmental conditions. Each transport has distinct tradeoffs between range, bandwidth, power consumption, cost, and infrastructure requirements. By committing to one transport, systems become brittle; they work well in specific scenarios but fail or perform poorly when conditions change.

Here's how each transport stacks up:

Transport	Range	Bandwidth	Power	Best For	Limitations
WiFi Infrastructure	30-45m 5 GHz, 50m-1.5km 2.4 GHz	50-100+ Mbps	Medium	High-bandwidth sync	Single point of failure, requires access point
Bluetooth LE 5.2	30-100m (up to 400m)	2 Mbps	Low	Wearables, close-range comms	Limited bandwidth
WiFi P2P (AWDL, WiFi Direct, WiFi Aware)	30-100m	50-100+ Mbps	High	Direct device communication	Platform-specific, complex setup
Cellular	Broad	Variable (5-100 Mbps)	Medium	Geographic coverage	Expensive, latency issues, coverage gaps
Wired Ethernet	Wired	1Gbps+	N/A	Infrastructure deployments, IoT	Requires cabling and hardware

Single-Transport vs. Multi-Transport Mesh: A Critical Distinction

Before diving into individual transport details, it's important to understand a fundamental architectural difference. Single-transport mesh systems—even those supporting WiFi-based peer-to-peer networks—remain constrained to one transport layer.

For example, WiFi-only mesh implementations using DNS-SD (Bonjour) for peer discovery require all devices to be on the same WiFi network. When that network becomes unavailable or a device moves out of range, synchronization stops entirely.

Multi-transport mesh systems take a fundamentally different approach. They maintain simultaneous connections across multiple transports and automatically fail over between them based on real-time conditions. A device might sync over WiFi infrastructure, then seamlessly switch to peer-to-peer WiFi, then fall back to Bluetooth LE as it moves between environments—all without interrupting the application or requiring manual reconfiguration.

This architectural difference determines whether your system can truly adapt to unpredictable network conditions or remains dependent on a single transport's availability. Let's take a closer look at each of the individual transports now.

WiFi Infrastructure Mode: The Access Point Bottleneck

In standard WiFi networks, all traffic routes through an access point. When two devices are physically close but both distant from the access point, their data must travel the combined distance to and from the access point. This introduces latency and creates a single point of failure. If the access point goes down, nearby devices can't communicate even though they're within direct radio range of each other.

Bluetooth Low Energy: Range and Bandwidth Constraints

Bluetooth Low Energy (BLE) offers excellent power efficiency and works well for wearables and personal devices, but it's fundamentally limited by its short range—typically 30-100 meters depending on the device and environment (theoretically allows for ranges up to 240 meters). The bandwidth is also constrained compared to WiFi; Bluetooth LE 5.2 achieves maximum speeds around 2 Mbps, while WiFi typically delivers 50-100+ Mbps or higher depending on the standard. This significant speed difference makes Bluetooth unsuitable for syncing large datasets or multiple files within reasonable timeframes. Additionally, Bluetooth requires pairing and can support only a limited number of simultaneous connections, making it impractical for scenarios where many devices need to coordinate together. In crowded environments with multiple Bluetooth devices, interference and connection instability become significant problems.

Peer-to-Peer WiFi Protocols: Platform Fragmentation Challenges

Peer-to-peer WiFi technologies like AWDL, WiFi Direct, and WiFi Aware enable direct device-to-device communication without requiring an access point, eliminating the latency and single point of failure inherent in infrastructure mode. However, these technologies are highly platform-specific—WiFi Direct works differently on Android versus iOS, and WiFi Aware has limited availability across devices. Setup complexity is another challenge; establishing P2P connections often requires manual user intervention or complex background negotiation. Battery drain can also be significant since devices must maintain active WiFi radios even when not connected to a traditional network.

Cellular Networks

Cellular networks provide broad geographic coverage and work reliably in many environments, but they come with substantial limitations for distributed systems. Cellular connectivity is expensive, especially for high-volume data sync, and isn't always available in remote areas or indoors where signal is weak. The latency on cellular networks can be higher than local options, and metered data plans create cost concerns for applications that need frequent synchronization. Additionally, cellular connectivity depends on external infrastructure and carrier policies, making it unsuitable as a primary sync mechanism for devices that need to communicate independently.

Wired LAN (Ethernet)

While wired LAN (Ethernet) connections offer excellent reliability and bandwidth, they're impractical for most mobile and distributed scenarios. Devices require physical cabling, network switches, routers, and proper infrastructure setup—an overhead that makes LAN unsuitable for field operations, remote locations, or dynamic environments where devices are constantly moving. LAN is also limited by distance; cables can only extend so far without additional infrastructure investment. For truly distributed systems where devices need mobility and flexibility, LAN represents a rigid solution that conflicts with the need for adaptability.

The reality: No single transport is optimal for all scenarios. The ideal solution adapts to whatever connectivity is available.

Beyond Single Transport: The Case for Intelligent Multiplexing

The fundamental insight that solves the single-transport problem is deceptively simple: run multiple transports simultaneously and intelligently select which one to use. This approach, called transport multiplexing, isn't new to networking. In the early days of the internet, hardware multiplexers from companies like Cisco were expensive, specialized devices that could cost tens or hundreds of thousands of dollars. These devices occupied entire racks and required dedicated teams to manage, making them accessible only to large enterprises with substantial infrastructure budgets.

Today, the same principle is being reimplemented in software, eliminating the cost barrier that once made multiplexing an exclusive luxury. Modern applications can now dynamically select among multiple transports—WiFi, Bluetooth LE, peer-to-peer WiFi, and cellular—making intelligent decisions about which to use at any given moment based on real-time network conditions.

How Intelligent Transport Multiplexing Works: Dynamic Transport Selection

At its core, intelligent transport multiplexing operates on a simple premise: establish connections across all available transports simultaneously, then prioritize the best performer for each data transfer. The system continuously monitors metrics like bandwidth, latency, packet loss, and connection stability across all active transports. When conditions change—a device moves out of WiFi range, a peer comes within Bluetooth distance, or cellular signal strengthens—the system automatically adapts without requiring application intervention.

This approach transforms the tradeoffs inherent in individual transports from hard constraints into soft preferences. Bandwidth limitations on Bluetooth LE no longer prevent synchronization; they just mean the system will prefer WiFi when available. Platform-specific quirks with peer-to-peer WiFi become non-issues when Bluetooth LE provides a reliable fallback. The brittleness of single-transport systems gives way to resilience.

Practical Implementation: Ditto's Mesh Networking

A concrete example of intelligent transport multiplexing in action is Ditto's mesh networking approach. When peers with the same database ID connect to form a mesh network, they automatically use a mixture of communication transports, with Ditto prioritizing WiFi for its high bandwidth and falling back to Bluetooth LE when needed due to poor connectivity. This isn't a manual configuration—it happens automatically based on real-time network assessment.

The key advantage of this approach is that unlike typical home networks with a star topology where all devices connect to a central access point, a peer-to-peer mesh network offers multiple pathways for communication. This architectural difference matters profoundly: when one transport becomes unavailable or degrades, alternative paths remain open. Data continues flowing through whatever transport remains most effective.

For platform-specific implementations, Ditto leverages the best transport available on each operating system. On Apple devices, this includes Apple Wireless Direct Link (AWDL), while Android devices gain access to WiFi Aware—technologies that would be unavailable to single-transport applications.

Beyond Transport Selection: The Mesh Coordination Problem

Intelligent transport multiplexing alone isn't sufficient. Once a mesh network is established, three additional challenges must be solved: discovering other nodes without complex configuration, determining what data each device should sync, and minimizing the amount of data transferred over bandwidth-constrained connections like Bluetooth LE.

Automatic Node Discovery with Zero Configuration

Node discovery must happen automatically. Without it, users would need to manually configure which devices join the mesh—an operational burden that defeats the purpose of building resilient systems for field operations. Effective mesh implementations use multicast DNS (mDNS) and similar zero-configuration technologies to automatically detect peers on local networks, allowing devices to form meshes organically without administrative overhead.

Conflict Resolution with CRDTs

Data conflicts present another challenge in distributed systems. When devices in a mesh edit the same data independently, conflicts arise. Conflict-Free Replicated Data Types (CRDTs) solve this by ensuring that concurrent updates can be merged deterministically without explicit conflict resolution logic. Every peer converges to the same final state regardless of the order in which updates arrive—a property essential for maintaining consistency across a mesh without central coordination.

Subscription-Based Syncing with Delta Updates

Data synchronization efficiency requires subscription-based syncing and delta updates. Rather than synchronizing entire datasets, devices declare interest in specific data through subscription queries. When data changes, only the deltas—the actual changes—are transmitted across the network. This is critical for Bluetooth LE and other bandwidth-constrained transports; syncing only relevant changes rather than full documents can reduce traffic by orders of magnitude.

Ditto: A Complete Platform Solution

Ditto provides a unified platform that solves all these coordination challenges through a mobile database with built-in edge device connectivity and resiliency. Rather than requiring teams to implement discovery, subscription-based syncing, delta replication, and conflict resolution from scratch, Ditto bundles these capabilities into SDKs across all major platforms: Swift for iOS and macOS, Kotlin and Java for Android and JVM environments, JavaScript and TypeScript for Node.js and web browsers, React Native for cross-platform mobile development, Flutter and Dart, C# and .NET across iOS, Android, Windows, Linux, and macOS, Kotlin Multiplatform, Java for server-side applications, C++ for Linux, Android, iOS, and embedded systems, and Rust for all platforms.

This breadth of language and platform support means teams can build resilient, mesh-enabled applications using their existing technology stacks without learning entirely new frameworks or imposing constraints on their technology choices. Data synchronization, node discovery, selective subscription queries, delta updates, and CRDT-based conflict resolution all work consistently across these diverse environments, enabling truly platform-agnostic mesh networking that keeps mission-critical systems online when connectivity is unpredictable.

The Economics of Software-Based Multiplexing

The shift from hardware multiplexers to software-based transport selection represents more than just a technical evolution; it's an economic transformation. What once required six-figure capital expenditure and specialized expertise is now built into the application layer. Development teams can implement intelligent transport selection without purchasing specialized hardware, and the logic can adapt to new transports and conditions through simple software updates.

This democratization means that applications serving airline operations, healthcare facilities, construction sites, and retail environments—scenarios where connectivity is unpredictable—can now have infrastructure-grade resilience without infrastructure-grade costs. By combining intelligent transport multiplexing, automatic node discovery, subscription-based syncing with delta updates, and CRDTs for conflict resolution, modern distributed systems can operate reliably in environments where traditional architectures fail.

Frequently Asked Questions

Q: What's the difference between mesh networking and WiFi mesh systems like Eero or Netgear?

A: Traditional WiFi mesh systems extend coverage through repeaters connected to infrastructure and a cloud backend. Mesh networking in distributed systems (like Ditto) is peer-to-peer without requiring any infrastructure or central server—devices communicate directly across multiple transports, making them suitable for offline scenarios.

Q: Can I implement intelligent transport selection without a platform like Ditto?

A: Yes, but it requires implementing multiple complex systems from scratch: automatic peer discovery (mDNS), subscription query logic, delta sync algorithms, transport selection heuristics, and CRDT data structures for conflict resolution. Most teams find this represents months of engineering effort, and years of maintenance costs which is why dedicated platforms exist.

Q: Why is CRDT important for distributed systems?

A: CRDTs eliminate the need for central coordination when resolving data conflicts. Without them, distributed systems need to either lock data during edits (eliminating offline capability) or implement complex manual conflict resolution logic. CRDTs make eventual consistency practical and predictable.

Q: Which transport should I prioritize for my application?

A: Start with WiFi for high-bandwidth scenarios, but always have Bluetooth LE as a fallback. If your users operate in cellular-only regions, add cellular as a third transport. The beauty of intelligent multiplexing is that you don't need to choose—the system adapts automatically.

Q: Is mesh networking more secure than cloud-based sync?

A: Security depends on implementation, not topology. Mesh networks can be as secure as cloud systems when properly encrypted. The advantage is privacy—data stays on-device by default, only syncing between authorized peers.

Next Steps: Implementing Multi-Transport Sync

For teams building applications that operate in unpredictable network environments, transport multiplexing isn't a luxury—it's a necessity. Here's how to get started:

Evaluate your connectivity requirements. Map out where your users operate and which transports they'll encounter. Warehouse workers might need WiFi and Bluetooth LE, while field technicians require cellular fallback.
Choose a platform that handles the complexity. Implementing transport multiplexing, automatic node discovery, delta sync, and CRDT conflict resolution from scratch represents months of engineering effort. Platforms like Ditto provide these capabilities out of the box across iOS, Android, web, and embedded systems.
Design for offline-first from day one. Assume connectivity will fail and architect your application so data remains accessible locally. Your sync strategy should be invisible to users—data should always be available whether they're online or offline.
Test across all transports in production-like conditions. Validate behavior on WiFi, Bluetooth LE, and cellular to ensure graceful degradation. Monitor which transports your application uses in production to optimize performance.

Start building resilient distributed systems today. The technology to implement efficient transport multiplexing now exists, making infrastructure-grade resilience accessible to organizations of any size without infrastructure-grade costs.

Forem: Aaron LaBeau

Porting a SwiftUI App to Avalonia: How does Cross-Platform .NET hold up

The Three-Pane Layout: Sidebar + Detail + Inspector

SwiftUI: The Frictionless Version

Avalonia: Assembling the Ikea Version

What I Lost (Being Honest)

What I Gained

The Presence Viewer: SpriteKit vs. SkiaSharp

SwiftUI: SpriteKit Does the Heavy Lifting

Avalonia: Hello, Skia

The Honest Trade-Off

So, Should You Use Avalonia?

Links

Claude Mythos and the Mobile App Security Wake-Up Call: Why Mobile Developers Can't Afford to Wait

An AI model just rewrote the threat model

Why mobile developers need to take this seriously

The mobile threat landscape, in plain terms

What mobile app security actually looks like

How AppSweep fits in: shift security left, catch issues before release

Yes, these are the ProGuard people

The Claude Mythos lesson for mobile teams

Research mobile app security before you ship another release

Frequently Asked Questions

Simplifying macOS App Deployment with Xcode Cloud: A Developer's Guide

What is Xcode Cloud?

My Use Case: Edge Debug Helper

Xcode Cloud vs GitHub Actions: Why Make the Switch?

The iOS/macOS Certificate Management Challenge

Custom Scripts and YAML Configuration

The Simplicity Trade-off

Xcode Cloud in Action

Setup Right from Xcode

Web Dashboard for Monitoring

Free Tier That Actually Works for Side Projects

Parallel Testing Across Multiple Simulators

My macOS App Deployment Workflow with Xcode Cloud

1. Automatic Builds on Push

2. Wait for the Build

3. Download the Notarized Build

4. Create a Distributable DMG

5. Create a GitHub Release

Conclusion: Is Xcode Cloud Right for Your macOS App?

About Edge Debug Helper

Frequently Asked Questions (FAQ)

How much does Xcode Cloud cost?

Is Xcode Cloud better than GitHub Actions for macOS apps?

How do I set up Xcode Cloud for a macOS app?

Does Xcode Cloud automatically handle app notarization?

Can I use Xcode Cloud with SwiftUI apps?

What are compute hours in Xcode Cloud?

Do I need to manage certificates and provisioning profiles with Xcode Cloud?

Can Xcode Cloud run tests on multiple devices simultaneously?

How does Xcode Cloud compare to other CI/CD tools like Bitrise or CircleCI?

What is Ditto and why would I use Edge Debug Helper?

Sources

Hot Restart for iOS is not included in Visual Studio 2026: What .NET MAUI Developers Need to Know

What is Hot Restart?

How React Native with Expo Go Works

Why Did Microsoft Remove Hot Restart?

What Does This Mean for .NET MAUI Developers?

Final Thoughts

Sources

The Cascading Complexity of Offline-First Sync: Why CRDTs Alone Aren't Enough

The Solution Cascade: How Each Fix Creates New Problems

Problem #1: The Cloud Dependency Trap

The Solution: Hardware First... Then Reality Sets In

The Better Solution: Offline-First Databases

The New Problem: Sync Conflicts

Problem #2: The Conflict Resolution Challenge

The Solution: CRDTs (Conflict-Free Replicated Data Types)

The New Problem: Getting Data to Sync More Often

Problem #3: The Single Transport Limitation

The Solution: Multi-Transport Mesh Networking

The New Problem: Intelligent Transport Selection

Problem #4: Network Instability and Transport Switching

The Solution: A Transport Multiplexer

The New Problem: Bandwidth Constraints

Problem #5: The Document Flooding Disaster

The Solution: Property-Level Diffs (Delta Sync)

The New Problem: Broadcast Storm Inefficiency