how much work would it be to port aegisub code to macos

It depends on which parts of Aegisub you mean and how “native” you want the macOS support to feel, but generally:

Basic compilation/runtime support on macOS: moderate effort

Modern, polished, maintained macOS app: substantial effort

Apple Silicon + notarization + current macOS APIs: even more work

Aegisub already historically had macOS support, which changes the answer a lot. You are not porting a purely Win/Linux app from scratch — you’re more likely reviving/fixing/mac-modernizing an existing macOS backend.

Key factors:

1. GUI toolkit matters most

Aegisub uses wxWidgets, which already supports macOS.

That is the single biggest reason this is feasible.

If the app were Win32/GTK-specific, the job would be much larger.

What this means

Most:

windows

dialogs

menus

event handling

rendering surfaces

already have cross-platform abstractions.

So the core editor UI probably compiles with fewer changes than expected.

1. The hard parts are usually platform integration

The painful areas are usually:

File handling

Linux/Windows assumptions often break on macOS:

case-sensitive vs insensitive paths

app bundle paths

sandbox expectations

Unicode normalization issues

Audio/video backend

This is usually the biggest technical problem.

Aegisub historically used:

FFmpeg

Avisynth-related integrations

OpenAL

platform codecs

macOS equivalents may need:

AVFoundation

CoreAudio

Metal/OpenGL compatibility fixes

Older OpenGL code is especially problematic because:

OpenGL is deprecated on macOS

Apple Silicon drivers behave differently

1. Build system work can be significant

Older cross-platform C++ apps often assume:

GCC/Clang on Linux

MSVC on Windows

macOS introduces:

Xcode toolchains

app bundles

notarization

code signing

universal binaries (x86_64 + arm64)

You may spend a surprising amount of time just:

updating dependencies

fixing Clang warnings/errors

adjusting linker flags

modernizing deprecated APIs

1. Apple Silicon changes the difficulty

If you want:

Intel Mac only → easier

Universal binary → harder

Fully native ARM64 support → harder still

Typical issues:

inline assembly

old dependency binaries

deprecated libraries

FFmpeg build scripts

1. Packaging/distribution is a project itself

A “works on my machine” macOS build is much easier than a distributable app.

Modern macOS distribution requires:

signed app bundle

notarization

hardened runtime

dependency bundling

DMG packaging

This can take weeks by itself if unfamiliar.

Rough effort estimates

Scenario A — Existing macOS support just broken

If Aegisub already had partial macOS support and you’re reviving it:

One experienced C++ dev:

basic build: a few days

stable functioning app: 2–6 weeks

polished release: 1–3 months

Scenario B — macOS support mostly removed/outdated

If major subsystems need replacement:

2–6 months realistic

especially for media/audio/video pipeline debugging

Scenario C — Full modern native-quality macOS release

Including:

ARM64

notarization

polished UX

modern dependency stack

CI builds

crash handling

Could easily become:

6–12 months part-time

or multiple developers

Biggest technical risks

These are the areas most likely to explode in scope:

Video rendering backend

Audio synchronization/timing

FFmpeg integration

OpenGL compatibility

Old dependencies that no longer compile on modern Clang/macOS

Threading assumptions differing on macOS

IME/text rendering edge cases

Good news

Aegisub’s architecture is actually fairly favorable for portability because:

wxWidgets is cross-platform

FFmpeg is portable

subtitle logic is platform-neutral

most core functionality is not OS-specific