Introducing LXC Build & Release Manager — a native macOS workspace for repository build scripts

Community Showcase
, ,
1

Hi everyone,

I’ve been building LXC Build & Release Manager, an open-source native macOS application for developers whose build and release workflows already live in shell scripts.

The idea came from a familiar problem: many projects have reliable build scripts, release commands, log folders, and conventions—but the complete workflow is often spread across terminal windows, documentation, and team knowledge.

LXC Build & Release Manager brings that workflow into one inspectable Mac workspace without replacing the scripts or hiding what they do.

What it does

Point the app at a local repository and it can:

  • Discover executable scripts under /build/scripts
  • Present available commands and their parameters
  • Run scripts from the correct repository working directory
  • Stream stdout and stderr in real time
  • Stop running processes while preserving partial output
  • Save logs and maintain per-repository build history
  • Display branches, repository status, build duration, and previous results
  • Help stage release artifacts through the repository’s existing scripts

GitHub repository URLs can also be inspected through the GitHub Contents API. Script execution remains local because a process needs a real working directory.

What it is—and what it isn’t

This is not intended to replace CI/CD.

It is a local control room for the scripts a project already trusts: a place to discover the workflow, run it visibly, preserve the evidence, and prepare a deliberate release.

Technical details

  • Native macOS application
  • macOS 15 or later
  • Swift 6
  • SwiftUI, AppKit, and Foundation
  • No third-party dependencies
  • MIT licensed
  • Build and test automation through GitHub Actions

The project also includes its architecture notes, requirements, release workflow, decision records, and delivery plans. I wanted the repository to preserve not only the source code, but also the reasoning behind the product.

Current status

The project is still in its early open-source stage. It can currently be built from source using Xcode, while I continue hardening the packaging, Developer ID signing, notarization, and public DMG release flow.

Repository:

Screenshot:

image
image1920×1155 248 KB

image
image1920×1201 299 KB

Feedback I would value

I’d especially appreciate feedback from developers who maintain shell-driven build or release workflows:

  1. How are build scripts organized in your repositories?
  2. What parameters, environment variables, or secrets must your workflows handle?
  3. What information would make local build history genuinely useful?
  4. Where should a local tool like this stop and hand work over to CI?
  5. What would you need before trusting it with a real project?

Contributions, issues, architecture feedback, and UI suggestions are all welcome.

Thanks for taking a look!

1 Like