Skip to content

Contributing

Jump to bottom
Gil Burns edited this page Jun 27, 2026 · 2 revisions

Contributing

Contributions to Third Party Patcher are welcome. This page describes how to report issues, suggest features, and submit pull requests.

License

Third Party Patcher is released under the MIT License. By contributing, you agree that your contributions will be licensed under the same terms.

Reporting Issues

Use GitHub Issues to report bugs or request features.

Before opening an issue:

  1. Search existing issues to avoid duplicates.
  2. Collect relevant log output from /Library/Logs/Patcher/ (enable LogVerbose if needed).
  3. Note the macOS version, Patcher version (AppConstants.patcherVersion), and whether you are using Managed Labels.

Good bug reports include:

  • Steps to reproduce reliably.
  • What you expected to happen vs. what actually happened.
  • Relevant log lines (redact any sensitive hostnames or internal URLs).
  • The label name(s) involved, if applicable.

Suggesting Features

Open a GitHub Issue with the enhancement label. Describe:

  • The IT admin workflow or problem you're trying to solve.
  • How you'd expect the feature to behave.
  • Any edge cases you've considered.

Pull Requests

Prerequisites

  • Xcode 15 or later.
  • macOS 14 Sonoma or later (for building and testing).
  • Familiarity with Swift and the ArgumentParser framework.

Development Setup

git clone https://github.com/<your-fork>/patcher.git
cd patcher
open patcher.xcodeproj

The project contains three targets: patcher, patcherscheduler, and patcherreport. Tests are in patcherTests and patcherschedulerTests.

Running Tests

xcodebuild test -project patcher.xcodeproj -scheme patcher
xcodebuild test -project patcher.xcodeproj -scheme patcherscheduler

Or run tests from within Xcode using ⌘U.

All tests should pass before submitting a PR. The test suites use an in-memory preference system (Preferences(testPrefs: [:])) and the PATCHER_DATA_DIR environment variable to redirect file I/O to a temporary directory — no root access or real system state is required.

Code Style

  • Swift standard formatting (no third-party formatter required).
  • No comments explaining what the code does — name things clearly instead.
  • Comments only for non-obvious why — hidden constraints, workarounds, invariants.
  • No half-finished implementations or feature flags.

PR Guidelines

  1. Fork the repository and create a branch from main.
  2. Keep PRs focused — one logical change per PR.
  3. Update any relevant wiki pages if your change affects IT-admin-visible behavior.
  4. Add or update tests for new behavior.
  5. Describe the why in the PR body, not just the what.

Installomator Labels

Third Party Patcher does not maintain Installomator labels. If an app is missing from Installomator or a label is incorrect, please contribute upstream:

https://github.com/Installomator/Installomator

For labels specific to your organization that are not appropriate for the public Installomator repository, use Managed Labels instead.

Clone this wiki locally