docs/gsoc/Dart-GSoC-2026-Project-Ideas.md
[!info] Google Summer of Code 2026 is currently accepting applications until March 31st, 2026.
The list of accepted projects will be announced on summerofcode.withgoogle.com.
A list of Google Summer of Code project ideas for Dart.
For GSoC related discussions please use the dart-gsoc group.
Potential mentors
[email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected]All projects assume familiarity with Dart (and sometimes Flutter). Aspiring applicants are encouraged to learn Dart and try to write some code.
Applicants are welcome to find and fix bugs in Dart or some of the packages written by the Dart team. However, getting reviews can take a long time as code owners may be busy working on new features. So instead of requiring applicants to fix a good first bug, we suggest that applicants write a working code sample relevant for the proposed project.
The code sample can be attached to the application as a secret gist (please use secret gists, and do not share these with other applicants). Suggested ideas below includes proposed "Good Sample Projects".
Do not spend too much energy on this piece of sample code, we just want to see that you can code something relevant -- and that this sample code can run and do something non-trivial. Be aware that we have a limited number of mentors available, and will only be able to accept a few applicants.
Applications can be submitted through the summerofcode.withgoogle.com website. Applicants are encouraged to submit draft proposals, linking to Google Docs with permission for mentors to comment. See also the contributor guide on writing a proposal.
IMPORTANT: Remember to submit final proposals before the March 31st deadline.
[email protected], [email protected]Description:
When using the Dart debugger on Pointer<X> (where X extends Struct or Union or is a native type), the pointer itself is opaque. It would be extremely useful if the debugger could inspect the memory that the Pointer points to, effectively making .ref available as an inspectable getter.
For example, when debugging the following code:
import 'dart:ffi';
import 'package:ffi/ffi.dart';
final class MyStruct extends Struct {
@Int32()
external int a;
@Double()
external double b;
}
void main() {
final ptr = malloc<MyStruct>();
ptr.ref.a = 42;
ptr.ref.b = 3.14;
// Inspecting 'ptr' in the debugger should allow seeing 'a' and 'b'
// (either via the binary layout or a higher-level abstraction).
malloc.free(ptr);
}
Currently, ptr only shows its memory address in the debugger.
However, dereferencing invalid pointers leads to segmentation faults. While nullptr (address 0) is easy to check, user-created pointers might point to invalid memory, and dereferencing them during a debug session should not crash the application.
This project involves:
Instance type for Pointer so they are displayed properly across IDEs without an extension.Struct/Union layout and annotations if not already available.Good Sample Project:
Create a standalone Flutter app that demonstrates a custom view for a Pointer.
Pointer object (or a mock of one), compute the size of the data structure (the X in Pointer<X>), and display the memory contents. For the sample, you can assume valid pointers or mock the data retrieval to avoid crashes. Bonus: Implement this custom view directly in the DevTools codebase (e.g. in the Object Inspector) rather than as a standalone app.Expected outcome:
A working feature in Dart DevTools (and underlying VM support) that allows
developers to inspect the contents of Pointers safely during debugging.
Further reading:
Description:
C++ doesn't have a stable ABI (for example, it varies by compiler), so we can't directly interop with it. However, it would be possible to parse a C++ API, code-gen C compatible bindings for the API (using extern "C"), then generate Dart bindings that look like the C++ API, but actually invoke the C glue code.
Input Output Output
C++ API <-> C glue code <-> Dart bindings
The goal of this project is to add C++ as a new experimental language in FFIgen. FFIgen already uses libclang to parse C/ObjC APIs, so the parsing logic just needs to be extended to parse C++ APIs. Then the AST needs to be extended to be able to represent C++ language features. Finally, the code generator needs to be extended to support generating C code to wrap the C++ API, and Dart code to interact with the C API.
A good proposal for this project will explore the various language features of C++, describe how that feature can be most closely represented in Dart, and what the C glue code looks like to support that feature. The more language features we can translate, the better the final product will be.
A good sample project would be to add parsing logic to FFIgen to parse some simple C++ feature, such as a class with methods. Don't worry about code gen or representing the class in the AST yet, just write the parsing logic and print out some info about the class and its methods.
Tracking bug: https://github.com/dart-lang/native/issues/2644
[email protected], Helin Shiah [email protected]Description:
The current implementation of websocket connections in Intellij is out of date and conflicts with certain Anti-Virus software on Windows PCs. This needs to be updated to a more modern library and tested on various development platforms.
Tracking bug: https://github.com/flutter/dart-intellij-third-party/issues/208
[email protected], Helin Shiah [email protected]Description:
The Dart plugin communicates with the analysis server with a legacy custom protocol, but migrating to language server protocol (LSP) would enable more language analysis features for IntelliJ/Android Studio users with less IntelliJ-specific code.
Related to: https://github.com/flutter/dart-intellij-third-party/issues/207
[email protected], Samuel Rawlins [email protected]Description:
The Dart & Flutter DevTools Network panel currently only supports HTTP requests, but many developers use other types of connections between their applications and back end services. Adding support for these would dramatically increase the effectiveness of the Network panel for developers.
This project involves extending dart:io, dart:developer, and the VM Service to record and expose WebSocket traffic details, and updating the DevTools Network panel to display that information. Once WebSocket support is added, there is an opportunity to add the same support for gRPC traffic (which would likely make this a Large and not Medium project).
The expected outcome of the project is for WebSocket traffic details (and potentially gRPC traffic details) to be displayed in the DevTools Network panel.
Good Sample Projects:
Implement a ProfileableWebSocket wrapper and create a Dart CLI application that uses this wrapper to display real-time traffic logs.
Part 1: Create a ProfileableWebSocket wrapper class that implements dart:io's WebSocket interface. The wrapper should record network traffic by intercepting every add call and listen event. It should record the time, size, and type of each frame and store it in a local buffer that can be queried.
Part 2: Create a Dart CLI app that uses ProfileableWebSocket. It should connect to a public WebSocket echo server and allow users to send messages. After every message sent it should print to the console a formatted table of the last ten socket events captured by the wrapper.
Further reading:
dart:io documentation[email protected], Jonas Jensen [email protected]Description:
package:webcrypto provides a cross-platform implementation of the
Web Cryptography APIs. Outside the browser, it currently uses a native
implementation that embeds BoringSSL. This project is to create an experimental
branch of package:webcrypto, where Android uses package:jnigen to call
platform Java cryptography APIs instead of bundling a BoringSSL binary with
the package.
Good Sample Project:
Build a small Flutter app for Android that uses package:jnigen to call a
simple Java cryptography API from Dart, such as computing a digest or HMAC.
Expose the operation through a small Dart wrapper, compare the result with the
existing package:webcrypto API on Android, and document the data flow
between Dart, JNI, and the Java implementation.
Bonus: include a simple benchmark against a version using the current native backend.
Expected outcome:
A branch of package:webcrypto with an Android-specific backend implemented
through package:jnigen for an initial subset of primitives, together with
tests and documentation evaluating correctness, performance,
packaging constraints, and binary size tradeoffs.
A successful project may demonstrate that this approach is viable for future
integration into the main package.