Swift Good First Issues

Leonid Bugaev
|
(Updated August 31, 2026)
|
8 min read
swift beginners good-first-issue contributing

Swift labels the same string on two SDKs that are not the same sitting. A Package.swift whose README never swift builds. A Linux CI / Foundation ticket that already runs without Xcode. A UIKit or SwiftUI leaf that needs a simulator. Same badge. Different boot. The Swift hub is one feed; you still pick the SDK you can actually start tonight.

Generic hunting: how to find good first issues. Multi-language picking: best open source projects for beginners. Merge checks: how to pick an issue that will get merged. This URL is the Swift filter.

Open the Swift hub

Swift hub

Labeled good-first and help-wanted issues on active GitHub repos whose language is Swift. SPM libraries, Linux Foundation work, and Apple-SDK apps sit in the same list. On 2026-08-31: about 467 labeled issues at 10+ stars. Snapshot. It moves. The list does not tell you which SDK you can boot.

Not writing Swift? The homepage is the language switch.

Read the body. Skip stale, claimed, and repos that have not merged lately. I am not listing famous iOS apps or SPM names. A leftover label on a well-known package is still leftover. The feed is the hub, ticket by ticket.

SPM: a Package.swift that actually swift builds

In Swift the real first sitting is often swift build. The README still shows swift package resolve against a layout that never shipped. Package.swift still lists a dependency URL that 404s. // swift-tools-version is a souvenir someone left at 5.5. The issue already named that hole.

Shapes that merge:

Done is: a newcomer can follow that page, swift build, and get the same products the project ships. Done is not a souvenir tools-version bump, a dependency rewrite you were not asked for, or migrating to a newer PackageDescription API because you like it.

Do not bump tools-version while you are here. Do not bump a dependency, the Swift language version, or a related package as a drive-by. Version bumps review as policy and stall the build fix.

CONTRIBUTING will name swift build and swift test. Run them on the default branch first. If the package cannot boot on your machine, pick another ticket. Debugging their toolchain is two projects.

A green swift build on main is the gate. The code change comes after.

Linux vs Apple SDKs: they are different first evenings

Be honest about this. A Linux CI / Foundation ticket is not a UIKit or SwiftUI leaf. The badge is the same string. The evening is not.

Linux / Foundation-shaped. swift test on a Linux box, or a Foundation / swift-corelibs ticket that CI already runs without Xcode. No simulator. No import UIKit. That is the only reason they look easier — and only if the surface is small. A Linux CI README that names the real swift test invocation is a real first PR.

Apple SDK-shaped. UIKit or SwiftUI. You boot Xcode, a simulator or a device, and whatever scheme CONTRIBUTING names. A first PR is a leaf: one view, one modifier the issue quoted, a string, a preview. Not the navigation stack. Not a rewrite of UIKit into SwiftUI because you prefer it.

Skip the Apple-SDK ticket if you cannot boot the simulator tonight. No Xcode, no runtime image, a scheme that never launches — that is two projects. Take an SPM library or a Linux Foundation ticket instead. Do not plan to install Xcode later on issue one.

Do not pick a UIKit/SwiftUI ticket because you know Swift if you cannot boot that SDK tonight. Do not pick a Linux CI ticket and pretend it is the same as a SwiftUI screen. They are not the same.

I am not listing famous iOS apps or Apple sample names. Filter the Swift hub and judge the SDK, not the brand.

After a merge on the SDK you can boot, issue two can cross. Not before.

Docs: DocC or a broken README example

DocC is compiled docs. The source is ///, a .docc catalog, and sometimes Examples/. A ticket that says the README snippet does not compile is asking you to fix the comment so swift test or the DocC preview is green. It is not asking for a book.

Shapes that merge:

Done is: swift test / swift build passes for that example, or the project’s DocC command builds the named article. Done is not a new DocC theme, a whole-catalog rewrite, or reordering modules because you would have named them differently.

Match their loop. CONTRIBUTING often names swift test, swift package generate-documentation, or a specific example. Run that on the default branch before you edit. If you cannot get DocC running, pick another issue. Debugging their DocC plugin is a second project.

A DocC-only merge counts. An unasked guide does not.

swift-format and SwiftLint: the hunk

swift-format will rewrite the file because the editor offered. SwiftLint will open findings you did not cause.

Rules:

A formatted test is hygiene. A package-wide swift-format is a closed PR.

Compiler and SwiftUI/UIKit internals wait

The Swift compiler, SwiftUI/UIKit internals, and the insides of a huge Apple-SDK framework look labeled and are still issue two. Those files have implicit contracts. The badge means they want help. It does not mean the patch is first-timer sized.

Issue one is a leaf: a Package.swift that swift builds, a DocC or README example, a Linux Foundation test, a UIKit/SwiftUI leaf you can actually boot — not the compiler, not SwiftUI/UIKit internals.

After a merge in that repo, you can go inward.

Ship one ticket

  1. Filter on the Swift hub. Drop stale and claimed. Confirm recent merges. Pick Linux or Apple SDK — the one you can boot tonight.
  2. Read CONTRIBUTING.md for swift build / swift test, the SDK note, and swift-format / SwiftLint. Get default branch green, or the example actually built.
  3. Comment on one issue.
  4. Diff stays on the ticket. SPM manifest, DocC/README example, Linux Foundation test, or a UIKit/SwiftUI leaf. Hunk-only swift-format/SwiftLint. No tools-version bump. Fixes #123. Say which command you ran. Stay for review.

Git: first pull request guide. Week-1: how to contribute to open source.

FAQ

Is a Package.swift or README that actually swift builds a real first PR?

Yes. Manifest metadata and a snippet that swift build can follow is a real merge. Bumping tools-version or a dependency as a souvenir is not.

Linux CI and UIKit/SwiftUI all say Swift. Can I pick any of them?

No. They are different first evenings. A Linux CI / Foundation ticket is not the same as a UIKit or SwiftUI leaf. The Swift hub is one feed; you still pick the SDK you can boot tonight.

Is a DocC or broken README example a real first Swift merge?

Yes. One DocC article, a /// example that compiles again, or a README snippet the ticket named is a real merge. A volunteer rewrite of the catalog is not. Do the ticket.

Should I run swift-format or SwiftLint on the whole package?

No. Format the hunk you touched. A whole-package swift-format / SwiftLint rewrite is a style diff. Leave .swiftlint.yml alone unless that file is the ticket. If CI formats the package, let CI.

Where do I find live Swift good first issues?

On the Swift hub. Filter, skip stale and claimed threads. Read CONTRIBUTING for swift build, the SDK (Linux / Apple), and swift-format / SwiftLint. Other languages: the homepage.

Start here

Open the Swift hub. Pick one unclaimed ticket on the SDK you can boot: a Package.swift that actually swift builds, a DocC or README example, a Linux Foundation test, or a UIKit/SwiftUI leaf — not compiler internals, not SwiftUI/UIKit internals, not a tools-version souvenir. Comment once, format only what you touched, keep the diff on that job, and stay for review. Not writing Swift tonight? The homepage is the language switch.

Back to all articles Find projects that need your help