DEV Community: KnieLemon

Porting a .NET desktop app to macOS and Linux, and the bugs a VM didn't show me

KnieLemon — Sat, 10 Oct 2026 00:00:08 +0000

Filee is a file converter you use with a drag gesture. You hold a key, drag files, and a ring of formats opens at the cursor. Drop the files on one and the converted copies land next to the originals. It's C# on .NET 10 with Avalonia for the UI, MIT-licensed, and until last week it ran only on Windows.

Avalonia is cross-platform, so the port looked like a packaging job. It wasn't. Here is what broke, roughly in the order I found it.

I don't own a Mac

My test setup was a macOS 15 VM in VMware on Windows, plus GitHub's macOS runners. The VM built and ran the tests fine. The app itself died on start:

Avalonia.Native was not able to start the RenderTimer. Native error code is: -6661

Avalonia drives its render loop from macOS's display link, and a VMware macOS guest without 3D acceleration has none. Turning on "Accelerate 3D graphics" in the VM settings fixed it, even though System Information still shows no Metal support. Before I found that, I made Filee show a system alert in that case instead of quitting silently.

A crash caused by a null tooltip

On the GitHub runners, which do have a display, the app also quit right after starting:

System.ArgumentNullException: Value cannot be null. (Parameter 'chars')
   at Avalonia.Native.Interop.Impl.__MicroComIAvnTrayIconProxy.SetToolTipText(String text)

The tray icon was attached before its tooltip was set. Windows doesn't mind a null tooltip; the macOS backend passes it to native code. One line fixed it:

_tray = new TrayIcon
{
    Icon = new WindowIcon(iconStream),
    // Set before the icon is attached: on macOS the tooltip goes to native code, which can't take null.
    ToolTipText = "Filee",
    Menu = new NativeMenu { Items = { _open, _pause, new NativeMenuItemSeparator(), _quit } },
    IsVisible = true,
};

The workflow that caught it now runs on every pull request. It installs the package on Intel and Apple silicon runners, starts the app, and saves a screenshot with screencapture -x. Those screenshots are the closest I have to a real Mac.

English on a Korean Mac

Started from my SSH session, Filee came up in Korean. Started from Finder, it came up in English. An app launched from Finder gets no LANG variable, so .NET's CultureInfo.InstalledUICulture has nothing to go on. macOS keeps the user's languages elsewhere, and CoreFoundation hands them out:

[DllImport("/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation")]
private static extern nint CFLocaleCopyPreferredLanguages();

The first entry is something like ko-KR or zh-Hans-CN. I also had to list the app's localizations in Info.plist (CFBundleLocalizations) so the system panels follow the same language.

The Dock was under every drag

The gesture only fires over the file manager. To check that, Filee asks which app owns the window under the cursor, walking CGWindowListCopyWindowInfo from front to back. On macOS the answer was always "Dock", so Option+drag never did anything.

The Dock keeps a transparent window over the whole screen. App windows sit at layer 0 and the desktop below it, so the fix is to skip everything above:

var layerValue = CFDictionaryGetValue(window, LayerKey);
if (layerValue != 0 && CFNumberGetInt(layerValue, 3, out var layer) && layer > 0)
    continue;

I found it by adding a FILEE_TRACE_GESTURES=1 switch that logs each press, its modifiers and the window it landed on. The modifiers were right; the window was the Dock.

Finder's right-click menu: Automator didn't run

My first "Convert with Filee" entry was a Quick Action: an Automator workflow with a shell script that started a second Filee process to hand over the files. The menu item showed up. Clicking it did nothing. A workflow made in Automator itself didn't run either, and its runner processes piled up.

Instead of debugging Automator, I made Filee.app provide the service itself. Info.plist declares it:

<key>NSServices</key>
<array>
    <dict>
        <key>NSMenuItem</key><dict><key>default</key><string>Convert with Filee</string></dict>
        <key>NSMessage</key><string>convertFiles</string>
        <key>NSPortName</key><string>Filee</string>
        <key>NSRequiredContext</key><dict/>
        <key>NSSendFileTypes</key><array><string>public.item</string></array>
    </dict>
</array>

and at start the app registers an object that answers convertFiles:userData:error:. There's no Objective-C in the project, so the class is made at run time from C#:

var type = objc_allocateClassPair(objc_getClass("NSObject"), "FileeServicesProvider", 0);
class_addMethod(type, sel_registerName("convertFiles:userData:error:"),
    Marshal.GetFunctionPointerForDelegate(Method), "v@:@@^@");
objc_registerClassPair(type);

macOS now hands the selected files straight to the running app. No shell, no second process.

Signing a .NET app bundle

codesign on the main executable failed with "code object is not signed at all" pointing at Microsoft.CSharp.dll. A .NET app keeps its assemblies next to the executable in Contents/MacOS, and codesign treats every file there as code. Signing every file first (non-Mach-O files get their signature in extended attributes), then the executable, then the bundle, works.

A smaller one: my entitlements file came out of git archive on Windows with CRLF line endings, and codesign refused to parse it. *.plist text eol=lf in .gitattributes settled that.

Files nobody locks

Filee can watch a folder and convert what lands in it, but only once a file is complete. On Windows the check is easy: a file still being written can't be opened exclusively. macOS and Linux don't lock it, so a copy that paused for a few seconds got converted half-written, then again when it finished.

There the watcher now waits longer for a file to stop changing. On macOS it also skips files whose creation date is 24 January 1984, the date Finder gives a file while it's still copying it.

Linux and Wayland

Linux went more smoothly: Ubuntu 24.04, an install.sh that puts the app in the menu and adds file-manager actions for Nautilus, Nemo, Thunar and Dolphin. The drag gesture needs X11, though. Wayland doesn't let one app watch another's input, so there you use the drop window and the right-click action. I haven't found a good Wayland answer yet.

Where it stands

macOS and Linux are previews in 1.7. The macOS build isn't notarized yet, and everything I know about real Macs comes from CI screenshots and bug reports. If you try it on one and something breaks, the issues are open.

I wrote this article with help from an AI assistant, which I also used while writing the code. The bugs, logs and fixes above are from the project's history.

Confirming bank transfers from Android notifications with 15 lines of Python

KnieLemon — Fri, 09 Oct 2026 23:58:02 +0000

Small shops that take bank transfers usually confirm them by hand: the bank app shows "deposit received", someone opens the order list and marks the order paid. Banks do offer APIs for this, but they come with contracts and fees that a small shop doesn't want.

The phone already gets the information for free, as a notification. So I wired the notification straight into code.

The setup

I used Droidline, an open source tool I've been building. It has two parts:

an Android app that reads the screen and notifications through Android's accessibility and notification access, using only permissions an ordinary app can get
a server on the PC (droidline serve) that the app connects to over Wi-Fi

There's no ADB, no USB debugging and no root. You pair the phone once by scanning a QR code from droidline pair.

The code

The same two steps in every language: tell the phone which app's notifications to forward, then react to each one.

Python

from droidline import connect

d = connect("s23")
d.notify_filter(["com.example.bank"])   # only pass this app's notifications to the PC

def paid(n):
    if n["text"].startswith("[Deposit]"):
        mark_paid(n["text"])            # your own order system

d.on_notification(callback=paid)
input()

Node.js

import { connect } from "droidline";

const d = await connect("s23");
await d.notifyFilter(["com.example.bank"]);

await d.onNotification({ package: "com.example.bank" }, (n) => {
  if (n.text.startsWith("[Deposit]")) markPaid(n.text);
});

C

using Droidline;

await using var d = await DroidlineClient.ConnectAsync("s23");
await d.NotifyFilterAsync(new[] { "com.example.bank" });

using var stop = await d.OnNotificationAsync(n =>
{
    if (n.Text.StartsWith("[Deposit]")) MarkPaid(n.Text);
}, package: "com.example.bank");

Console.ReadLine();

Shell

droidline notify_filter com.example.bank
droidline on_notification --package com.example.bank

The second command prints each notification as a JSON line until you stop it, so you can pipe it into anything.

notify_filter matters: by default nothing leaves the phone, and you choose which apps' notifications are forwarded. Replace com.example.bank with your bank app's package name, and the [Deposit] check with your bank's wording, since every bank phrases the notification differently. mark_paid stands for your own order system.

Install: pip install droidline, npm install droidline or dotnet add package Droidline. The droidline command and the Android app are on the releases page.

Things to know

The phone has to stay on and connected. An old phone on a charger works fine for this.
The connection is encrypted end to end (P-256 and AES-256-GCM), so the notification text never crosses the network in the clear.
Android 15 and later hide one-time codes inside notifications from apps. Deposit notifications are not affected, but if you try the same trick for verification codes, it only works on Android 14 and earlier.

Beyond notifications

The same connection can tap, type, swipe, take screenshots and run OCR, and there's an MCP server so AI agents can use the phone. On a Galaxy S23 Ultra, finding an element by its text takes 16 ms (median of 10 runs), against 100 ms for Appium UiAutomator2 and 2,368 ms for adb plus uiautomator. The benchmark script is in the repo under scripts/bench.

GitHub: https://github.com/KnifeLemon/Droidline (MIT)
Docs: https://droidline.dev/docs/

I wrote this post with help from an AI assistant and checked every command against the project.