Один код — три интерфейса: опыт сборки приложения под macOS, Windows и Linux
Один код — три интерфейса: опыт сборки приложения под macOS, Windows и Linux
Разработчик поделился опытом создания одного и того же приложения PullYard сразу в трёх нативных версиях — на SwiftUI, WinUI 3 и GTK 4. Это редкий случай, когда автор отказался от кросс-платформенных фреймворков вроде Electron или Tauri и объяснил, почему.
PullYard начинался как «GitHub Lite» — быстрый способ проверять комментарии к pull request’ам, потому что браузер слишком нагружал компьютер. Затем появилась функция «Fix with agent»: она читает комментарии ревью, формирует из них промпт и запускает агентную сессию для исправлений. Постепенно весь цикл — открыть PR, отревьюить, исправить, запросить повторное ревью — переехал внутрь приложения.
Три версии и их цифры
Сегодня приложение существует трижды: Swift/SwiftUI для macOS, C#/WinUI 3 для Windows и Rust/GTK 4 для Linux. Общего кода между ними нет. Запустить версии для Windows и Linux удалось за один день, но это касалось только запуска и минимальной функциональности — дальше пришлось серьёзно работать над безопасностью, утечками памяти и множеством исправлений.
Масштаб сопоставим: около 35 тысяч строк Swift (123 файла), примерно 38 тысяч строк C# плюс XAML и веб-ассеты (142 файла), и порядка 54 тысяч строк Rust, включая встроенные тесты (124 файла). Размеры дистрибутивов тоже различаются: DMG для macOS — около 10 МБ, .deb для Linux — около 5 МБ, а установщик для Windows — примерно 63 МБ, потому что он самодостаточен и включает рантайм .NET 8 и Windows App SDK.
Автор честно признаёт: «нативность» местами означает веб-вью. На macOS diff — это AppKit NSTableView, а беседы и отрендеренный Markdown — WKWebView. На Windows diff и чат с агентом — HTML в WebView2, а список файлов — WinUI ListView. На Linux diff — gtk::ListView с кастомной отрисовкой строк, а HTML беседы — WebKitGTK. Выбор WebView2 для diff на Windows объясняется необходимостью подсветки синтаксиса для многих языков и скорости на больших файлах.
Почему не кросс-платформенный фреймворк
Автор не считает кросс-платформенные фреймворки ошибочными, но для этого приложения причины были конкретными: главный экран — гигантский прокручиваемый diff, и плавность зависит от родного списка и рендеринга текста. Кроме того, у каждой платформы свои представления о том, где что живёт: бейдж в меню-баре на macOS, иконка в трее на Windows, заголовочные панели libadwaita в GNOME, а также Keychain, Credential Manager и Secret Service. Имитировать это из общего слоя можно, но платформенный код всё равно придётся писать. Цена решения очевидна: втрое больше кода для написания и поддержки.
Полный разбор с цифрами и деталями доступен в материале автора — подробности на DEV Community.
Что это значит
Для команд, выбирающих между «одним кодом на всех» и нативными версиями, этот опыт — полезный ориентир. Кросс-платформенный подход экономит ресурсы, но нативные интерфейсы дают контроль над производительностью и системной интеграцией. Решение зависит от того, насколько критичны для продукта плавность работы со сложными списками и глубокое погружение в каждую ОС.
Изучение разных подходов к построению интерфейсов помогает принимать более осознанные архитектурные решения — узнайте больше.
📌 Чтобы не пропустить новые публикации, подписывайтесь там, где вам удобнее: Дзен или MAX.
💛 Если статья оказалась полезной, поддержите автора донатом.
Материал подготовлен на основе информации из открытых источников. Все права на исходные материалы принадлежат их авторам. Если вы являетесь правообладателем и возражаете против использования, свяжитесь с нами по адресу info@11st.press.
