Project Ideas for GSoC 2025

This page contains a non-exhaustive list of potential project ideas that we are keen to develop during Google Summer of Code 2025. If you would like to apply to GSoC as a contributor, please follow these steps to get started:

  1. Read through this page and the Google Summer of Code guides,
  2. Identify, or come up with your own project ideas you find interesting.
  3. Check out the Development forum to connect with potential mentors.
    • Feel free to mention the project mentors on the forums, when starting a thread about your interest in participating in a specific project they are offering to mentor.

When posting on the forums about GSoC this year, please use the gsoc-2025 tag, so it is easy to identify.

Tips for contacting mentors

The Swift forums are powered by discourse, a discussion forums platform with spam avoidance mechanisms built-in. If this is your first time joining the forums, you may not be able to send mentors a direct message, as this requires a minimum amount of prior participation before the “send private message” feature is automatically enabled.

To start things off, we recommend starting a new thread or joining an existing discussion about the project you are interested in on the dedicated GSoC forums category. You should also tag your thread with the gsoc-2025 tag. It is best if you start a thread after having explored the topic a little bit already, and come up with specific questions about parts of the project you are not sure about. For example, you may have tried to build the project, but not sure where a functionality would be implemented; or you may not be sure about the scope of the project.

Please use the forums to tag and communicate with the project’s mentor to figure out the details of the project, such that when it comes to writing the official proposal plan, and submitting it on the Summer of Code website, you have a firm understanding of the project and can write a good, detailed proposal (see next section about hints on that).

If you would like to reach out to a mentor privately rather than making a public forum post, and the forums are not allowing you to send private messages yet, please reach out to Konrad Malawski at ktoso AT apple.com directly via email with the [gsoc2025] tag in the email subject and describe the project you would like to work on. We will route you to the appropriate mentor. In general, public communications on the forums are preferred though, as this is closer to the normal open-source way of getting things done in the Swift project.

Writing a proposal

Getting familiar with the codebase you are interested in working on during GSoC helps to write a good proposal because it helps you get a better understanding of how everything works and how you might best approach the project you are interested in. How you want to do that is really up to you and your style of learning. You could just clone the repository, read through the source code and follow the execution path of a test case by setting a breakpoint and stepping through the different instructions, read the available documentation or try to fix a simple bug in the codebase. The latter is how many open-source contributors got started, but it’s really up to you. If you do want to go and fix a simple bug, our repositories contain a label “good first issue” that marks issues that should be easy to fix and doable by newcomers to the project.

When it comes to writing the proposal, the Google Summer of Code Guide contains general, good advice.

Potential Projects

We are currently collecting project ideas on the forums in the dedicated GSoC category.

Potential mentors, please feel free to propose project ideas to this page directly, by opening a pull request to the Swift website.

You can browse previous year’s project ideas here: 2024, 2023, 2022, 2021, 2020, 2019.

Re-implement property wrappers with macros

Project size: 350 hours (large)

Estimated difficulty: Intermediate

Recommended skills

Description

Property wrappers feature is currently implemented purely within the compiler but with the addition of Swift Macros and init accessors it’s now possible to remove all ad-hoc code from the compiler and implement property wrappers by using existing features.

This work would remove a lot of property wrapper-specific code throughout the compiler - parsing, semantic analysis, SIL generation etc. which brings great benefits by facilitating code reuse, cleaning up the codebase and potentially fixing implementation corner cases. Macros and init accessors in their current state might not be sufficient to cover all of the property wrapper use scenarios, so the project is most likely going to require improving and expanding the aforementioned features as well.

Expected outcomes/benefits/deliverables

The outcome of this project is the complete removal of all property wrappers-specific code from the compiler. This benefits the Swift project in multiple areas - stability, testability and code health.

Potential mentors

Improve the display of documentation during code completion in SourceKit-LSP

Project size: 175 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

The Language Server Protocol (LSP) offers two rich ways of displaying documentation while invoking code completion: Every code completion item can have documentation associated with it and while completing a function signature, the editor can display the available overloads, parameter names and their documentation through signature help. Currently, SourceKit-LSP only displays the first line of an item’s documentation in the code completion results and does not provide any signature help.

This project would implement functionality to return the entire documentation for all code completion items and also implement the LSP signature help request. Both of these will require functionality to be added in SourceKit-LSP and the compiler’s code base, which determines the list of feasible code completion results.

Expected outcomes/benefits/deliverables

SourceKit-LSP will display more information and documentation about the code completion items it offers, allowing developers to pick the item that they are interested in more easily.

Potential mentors

Refactor sourcekitd to use Swift Concurrency

Project size: 175 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

sourcekitd is implemented in the Swift compiler’s repository to use the compiler’s understanding of Swift code to provide semantic functionality. It is currently implemented in C++. By refactoring its request handling and AST manager to Swift, we can take advantage of Swift’s concurrency safety, improving its data race safety, making it easier to reason about and maintain.

On macOS, sourcekitd is run as an XPC service, while on all other platforms, sourcekitd is run in the sourcekit-lsp process. As a stretch goal, refactoring the request handling would allow us to run sourcekitd in a separate process on Linux and Windows as well improving SourceKit-LSP’s resilience as crashes inside sourcekitd would not cause a crash of the LSP process itself.

Expected outcomes/benefits/deliverables

Improved concurrency-safety of sourcekitd and better maintainability.

Potential mentors

Add more refactoring actions to SourceKit-LSP

Project size: 90 hours (small)

Estimated difficulty: Intermediate

Recommended skills

Description

Refactoring actions assist a developer by automatically performing repetitive and mechanical tasks, such as renaming a variable. SourceKit-LSP already provides refactoring actions and this project would add new actions to SourceKit-LSP. A few new refactoring actions have already been proposed but this project is not necessarily limited to those ideas.

Expected outcomes/benefits/deliverables

A richer set of refactorings in SourceKit-LSP that aid developers in performing mechanical tasks.

Potential mentors

Qualified name lookup for swift-syntax

Project size: 350 hours (large)

Estimated difficulty: Intermediate

Recommended skills

Description

Qualified name lookup is the process by which a compiler resolves a reference A.f into a lookup for entities named f within A. In Swift, this can mean looking into the type A and all of its extensions, superclass, protocols, and so on to find visible members. The project involves building a new library to be integrated into the swift-syntax package that implements Swift’s qualified name lookup semantics, making it easy to build source tools that resolve names. The library will likely include a symbol table implementation that provides efficient lookup of a given name within a given type. It should also integrate with last year’s unqualified name lookup library project, to provide complete support for name lookup on Swift code processed with swift-syntax.

Expected outcomes/benefits/deliverables

Potential mentors

Swiftly Integration in VS Code

Project size: 175 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

Swiftly is a toolchain manager written in and built for Swift. In order to aid adoption in the Swift community, it would be beneficial to provide a rich editor integration with the existing Swift extension for VS Code. This editor integration should aid the user in installing Swiftly itself as well as with installing and selecting Swift toolchains. This will require some effort in Swiftly itself to provide a machine readable interface that any editor could use to manage Swift toolchain installations.

Expected outcomes/benefits/deliverables

Potential mentors

DocC Language Features in SourceKit-LSP

Project size: 90 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

SourceKit-LSP has recently added a feature to support DocC Live Preview for editors such as VS Code. This feature could be further improved by providing language features such as go to definition as well as diagnostics for invalid/missing symbol names.

Expected outcomes/benefits/deliverables

Potential mentors

Tutorial mode for the VS Code Swift extension

Project size: 90 hours (small)

Estimated difficulty: Intermediate

Recommended skills

Description

This project can possibly be combined with the Swiftly Integration in VS Code project and the Tutorial mode for Swift project. When submitting project application for both together, please then mark it as a medium (175 hours) project.

Right now there isn’t a whole lot of guidance on how to use the Swift extension for VS Code once it is installed. Apart from reading an article about it and the “Details” tab of the Swift extension in VS Code it’s up to the user to realize that a Swift toolchain will have to be installed and figure out the workflow to Build, Run, Test and Debug code. As well, people who are installing the extension could be new to programming and Swift in general. A tutorial mode that will show the features of the extension will be greatly beneficial for first time users.

The feature can possibly be implemented with VS Code Walkthrough mode or something similar to the CodeTour extension.

Expected outcomes/benefits/deliverables

Potential mentors

Tutorial mode for Swift in the VS Code Extension

Project size: 90 hours (small)

Estimated difficulty: Intermediate

Recommended skills

Description

This project can possibly be combined with the Swiftly Integration in VS Code project and the Tutorial mode for VS Code Swift project.

Many users who install the VS Code swift extension could be new to Swift and programming in general. A tutorial mode that will show features of the programming language could allow users to experiment with their programs interactively and greatly enhance their learning experience. This tutorial mode can include examples from the Swift Book, a VS Code version of the DocC tutorials, swift-testing tutorials and code formatting tutorials using swift-format.

The feature can possibly be implemented with VS Code Walkthrough mode or something similar to the CodeTour extension.

Expected outcomes/benefits/deliverables

Potential mentors

Improved console output for Swift Testing

Project size: 175 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

Enhance Swift Testing’s reporting of test results to the console/terminal. Consider adding features like live progress reporting, nested output reflecting suite hierarchy, test metadata (display names, tags), parameterized test arguments, and more terminal colors. Perhaps include user-configurable options. If time allows, implement several alternatives and present them to the community (and the Testing Workgroup) for consideration. Factor code as portably as possible to support many platforms, and so it could be incorporated into a supervisory “harness” process in the future.

Expected outcomes/benefits/deliverables

Potential mentors

Improved command line tool documentation

Project size: 175 hours (medium)

Estimated difficulty: Intermediate

Recommended skills

Description

Swift Argument Parser recently added a command plugin to generate documentation markup for a command line tool. This plugin could be improved by providing support for generating separate pages for each command and by leveraging additional markdown syntax to organize command line flags into sections and display possible values and default values.

Beyond the markdown output, this plugin could be further improved by generating a “symbol graph” that describe each command and its flags, options, and subcommands. By describing the commands’ structure, tools like Swift DocC can further customize the display of command line tool documentation, support links to individual flags, and allow developers to extend or override the documentation for individual flags in ways that isn’t overwritten when regenerating the documentation markup from the plugin. If time allows, prototype some enhancement to command line documentation in Swift DocC that leverage the information from the command symbol graph file.

Expected outcomes/benefits/deliverables

Potential mentors

Documentation coverage

Project size: 90 hours (small)

Estimated difficulty: Intermediate

Recommended skills

Description

Enhance Swift DocC’s experimental documentation coverage feature to write coverage metrics in a new extensible format that other tools can read and display. Define a few types of metrics—for example Boolean (has documentation: true/false), Fraction (2/3 parameters are documented), Percentage, etc.—for this format. Explore ideas for what documentation coverage information would be useful to emit. Explore ideas for how another tool could display that coverage information.

Expected outcomes/benefits/deliverables

Potential mentors

OpenAPI integration with DocC

Project size: 350 hours (large)

Estimated difficulty: Intermediate

Recommended skills

Description

OpenAPI is a standard for documenting HTTP services. It allows creating documents in YAML or JSON format that can be utilized by various tools to automate workflows, such as generating the required code for sending and receiving HTTP requests.

OpenAPI is known for its tooling to generate documentation, but in the Swift ecosystem, developers are already familiar with how DocC renders documentation for Swift and Objective-C APIs. To enhance consistency and improve the developer experience, we aim to extend DocC’s support to OpenAPI documents.

Expected outcomes/benefits/deliverables

As part of the Google Summer of Code project, the student will develop a library/tool that can generate DocC documentation from an OpenAPI document.

Strech goals:

Potential mentors

Example project name

Project size: N hours

Estimated difficulty: ???

Recommended skills

Description

Description of the project goes here.

Expected outcomes/benefits/deliverables

Potential mentors