My name is Jascha and I'm effectively the BDFL of SoftOmni.
At SoftOmni, one of our two main projects is SwiftRD.
We've been working hard (well mostly me on this one since most other contributors and maintainers eye our much bigger flagship project) at it since the late summer of 2025.
SwiftRD is an open-source ReSharper based Swift implementation.
This means bringing full-support for Swift to modern IntelliJ-based IDEs and full Visual Studio users.
This support will have day-1 support for full bidirectional interoperability with R# C++ which is JetBrains's own C++ language frontend. This support is NOT based on SourceKit but on a distinct Swift language frontend written in C# (as all are all R# frontends) from scratch. There will also be a matching Objective-C and Objective-C++ frontend. The Objective-C++ frontend will take advantage of our own Objective-C engine and JetBrains's own C++ frontend. Now due to https://youtrack.jetbrains.com/issue/RSCPP-37222/Support-R-C-Plugins-in-CLion-and-IntelliJ currently we are limited to releasing specifically to Rider and Visual Studio but the hope is we will be able to expand that to CLion and IntelliJ users in the future. JVM interoperability is not on our roadmap yet for these reasons. Luckily now C++ Rider support is cross-platform.
We're aiming to make this support truly first-class including native support for frameworks, the kind of support you'd expect for a top-tier language in IntelliJ. There is a roadmap of things planned.
We suffered a big refactor which costs us quite a few months of time so we haven't made as much progress as hoped but right now it seems the core Swift engine will be ready around the end of the year aside for its own data-flow analysis which will be Q1 2027 work. End-user features based on the core engine will be 2027 work. We might bring in inspections and quick fixing from SourceKit and formatting from swift-format at that time on-top of our own builtin formatting engine.
Now I was initially planning on not revealing this project more to the Swift community until its early access sometime next year but I thought perhaps some of you would be eager to help us out on this truly truly herculean effort. It's also because for some things that are ahead, I'd be helpful for me to be able to interact more directly with the Swift community so I'll use this discussion to do this effect. Questions to ask and whatnot. And as I said it's all open-source though since it's been a solo project mostly with a big refactor, the git history is a bit of a mess. Still I'd be very open to help if you want to help. The new architecture was finalized in March and the AST has been transformed to this new AST API as a process that is still ongoing at around 65% and a decent number of semantics are already coming in. Keep in mind a lot of that time, most of it was spent until June working on our flagship project. So I was able to do around 50% of the refactor in a month and it seems I must halt most work for the present month due to more urgent things on my side, I'd expect a completed refactored AST that is merged around early September
We also notified the ecosystem-steering committee of this work one month ago privately.
The early access will likely be in Q2 2027 and an initial release in the Q3-Q4 2027 range
now this separate post is about our overall roadmap
the swift frontend work including data-flow-analyser is expected to be fully complete in Q1 of 2027 (though without the DFA, end of 2026).
The project models that will be supported by this frontend are first SPM based projects. Xcode support is something we are eyeing for mid-2027 work
Main Roadmap:
First, we'll work out the basics based on this for all editors:
semantically aware syntax highlighting
code formatting that is full of options and thorough
luxurious autocomplete that is fast, relevant as well as fast type-matching completion. These completions will be syntactically and semantically aware of your code (for instance, adding a colon automatically and putting you right in for the next argument for positional arguments if that argument is not the last one).
a TON of inspections and quick fixes. We'll first go through every single lexical, syntactical and semantic issue that can arise and brainstorm and implement every possible and reasonable quick fix we can muster. For inspections, I will be relying a lot on what you guys consider code smells.
Debugging, of course
Go to definition, Find references. Code vision (summaries for usages on top of declarations)
parameter hints when positional parameters are used and not obvious
code generation of boilerplate
lots of code-snippets
simple to advanced refactorings
Intelligent and full DocC support and integrations with documentation.
Project Wizards for SPM projects and full Swift version management with Swiftly integration
past that we'd like to...these features are not for a 1.0 release for a lot of them but the earlier items will make it for 1.0:
integrate into the test runner facilities and provide out of the box support for XCTest and Swift Testing. Code coverage as well, allow debugging or running a single test.
Profiler integrations for CPU and Memory alongside dynamic program analysis for warning about hot spots.
Smart keys. When you join lines, move things around, those actions are completely semantically aware of your code.
Supporting Xcode as a project model fully
Integrate directly into the package manager, so that you can manage dependencies from a dedicated tool window.
Provide a decompiler with possible compiler explorer style things (the R# engine already has facilities for this).
Vulnerable dependencies tracking.
More deep IJ find window, call hierarchies, inheritance hierarchies as well as structural search and replace (SSR)
Integrating with UML diagrams and providing project dependency diagrams
Full Vapor and Kitura support which starts with Leaf support, more deep ORM integrations, endpoints registration and completion by registering the endpoints with IJ's endpoints subsystem.
A Predictive Debugger and more advanced debugging features tailored to profiling, parralelism and asynchronous programming, OpenTelemetry integrations and web-frameworks in general.
Providing a UI for editing dependencies when in the relevant file that is pretty dope.
An interface builder for libadwaita projects and SwiftUI
Dedicated Apple Frameworks support
Allow all of the above with a remote toolchain over SSH
Use internals to offer up a REPL and support Swift playgrounds.
There will be more and we don't expect to have this full feature set for over a few years but we are committed and we hope this will help Swift out a ton.
JetBrains seemingly might also help me with Objective-C directly since it benefits both parties.
I can tell you it was one of the main reasons for the push. To get IDE tooling for Swift on Windows and Linux more on par with macOS.
Another thing that is worth mentioning is already with the core AST API refactor, in a few months there will be a phenomenal AST API and semantically aware API to allow you to author plugins without having to reimplement swift as a frontend. Let us tame the beast for you and allow you to easily add warnings or issues and AST modifications for quick fixes or other ideas you might have.
The architecture allows you to modify almost anything with or without semantical checks turned on for these modifications. For building new nodes, using the construction APIs explicitly disallows introducing syntactically invalid pieces of code. The only construct allowed to do so are parsers. Now you can add a node that was generated by the Parser that contains erroneous variants of normal Swift nodes.
Looks great! I just have one small suggestion:
Kitura is barely maintained these days. I'd recommend dropping Kitura and supporting Hummingbird instead.
I am unaware of the frequency of updates you folks want here, I will only share probably the most important news items here so that folks can find information. I'm not sure on policy regarding to linking to external places. I'll put it this way: if you're interested in our work or helping out, we primarily operate out of a discord community. There is a reddit thread with the name of our org and you will find details and a link to the community somewhere over there.
For you Swift developers who want to use Swift within your stacks on CLion and regular IntelliJ (opening the door for us to add JVM interoperability on IntelliJ specifically) on top or Rider and full Visual Studio or simply want to see Java community support added to Rider so that we have that other path forward, I would love if you could upvote or drop a respectful comment on https://youtrack.jetbrains.com/issue/RSCPP-37222/Support-R-C-Plugins-in-CLion-and-IntelliJ and https://youtrack.jetbrains.com/issue/RIDER-141373/Java-and-Kotlin-support-from-IntelliJ-community telling JetBrains you would like to see this happen. I don't think I could argue for IntelliJ Ultimate in Rider (so web frameworks namely) so I do think the R++ plugins within CLion and IntelliJ is the one everyone should be championing for if they want a pathway for us to give you bidirectional Swift-Java support because most Swift-Java projects are server side projects (IntelliJ has access to R# C++ and full C++ support from like in CLion since 2025.3 as well).
I want to make something clear: at the present this item is much lower on our priority list. We don't consider it a 1.0 release feature. That would most likely be in our second or third or forth major version where we'd be trying to add Swift WASM, JS and Java interoperability stories.
PS: A final note that is more of an update, we've essentially finalised the refactor. Only 2 extremely minor bits and bobs left which means we have gone back to working on finishing the nearly complete lexer and trying to complete the parser work sometime next month. These are not your ordinary lexers and parsers. They have configurable recovery settings, like swift-syntax. More importantly they are engineered to make even broken code work well. They have an enormous amount of attention put into their recovery and they are hand-written.
I'm reaching out based on my experience building developer tools, language tooling, and complex software systems where clean architecture, performance, and long-term maintainability are just as important as delivering new features.
My approach is to contribute by implementing well-structured compiler or IDE components, improving language analysis, diagnostics, and tooling while keeping the codebase modular and easy to evolve as SwiftRD grows toward full production support.
The most important part of this project is building a reliable Swift language engine that provides accurate analysis and a first-class development experience across supported IDEs.
For developers, that means faster code navigation, dependable refactoring, accurate inspections, and seamless interoperability with C++ projects, making Swift development significantly more productive within the JetBrains and Visual Studio ecosystems.
I'm comfortable collaborating in open-source projects, discussing architectural decisions, reviewing code, and helping move ambitious long-term projects forward with practical, high-quality contributions.
Thank you for your time, and I'd be excited to discuss how I can contribute to SwiftRD and support its roadmap toward early access and beyond.
Hello folks! First of all an update on progress: the giant AST API refactor was mostly finalized and the parser has been advancing nicely. There are 5 main parsers that are involved. Attributes and Attribute Groups have their own parser (though it does not parse specific attribute structures, leaving mistakes in that department for a semantic walk step), types have their own parser, expressions, declarations and statements have their own parser (one parser for all 3). Finally Swift RegEx and DocC are their own languages with their own parsers and these get automatically injected as sub-ASTs into the upper Swift AST. Attributes and Types are about 70% done (remember this is not strictly following the grammar as it is designed to handle erroneous code as best as I can muster (invalid code is still flagged as invalid, valid is valid, just the AST nodes differ and a lot of errors which would be dealt at the parser level are dealt at the semantic analysis level instead)). The reason I decided to write this message though is the following:
Since SwiftRD is R#-based, R# is of course born out of a Visual Studio centric model, even for non-CLR languages like C and C++. Now like in CLion for project models like Xcode and SPM projects as well as C-family project models like CMake, Meson and Makefile which are now higher up on the roadmap due to wanting to appeal to C/C++ users even more, there is a way to make the internals work for non solution-file based projects. With that said, I was curious if Swift users would be interested in a proposal to introduce a .swiftproj XML file akin to .csproj (C#), .vbproj (Visual Basic), .fsproj (F#) and .vcxproj (C++) for Swift that would enable you to plug in Swift code directly into MSBuild based projects you might already have. This solution has the potential of increasing fragmentation of the ecosystem but on the flip-side, it could make adopting Swift even easier and allow it to even more easily fit-in to said projects. I am not that experienced in writing proposals (not at all for Swift) so if this is something the community would be interested in, I'd like to team up on this one.
I don't fully understand this. A swiftproj file is nothing particularly interesting. MSBuild doesn't really look at the extension. The piece that is needed is the target rule definition (.target files). The general structure is that you would need to simply define a <PropertyGroup>...</PropertyGroup> for any flags, any appropriate <ItemGroup> or (multiple if you like), so that the target is given the sources. I had looked at implementing swift.targets a long time ago, but it didn't make as much sense at that time.
Right well I was simply thinking having a dedicated .swiftproj project file would be consistent with other core languages that use MSBuild and a Visual Studio like model, also from a user's perspective since most users are used to project files alongside their solution file. Yeah knew about the structure, didn't know as much about the target files but it makes sense. Well if you'd be up for teaming up on something like adding a Swift MSBuild and Visual Studio project harness/solution/implementation, I'd be up for working on a proposal in that direction and then if it gets accepted, add it as a project model to SwiftRD. Given it is R#-based, there is already an enormous amount of infrastructure for doing this.
Folks as you know SwiftRD is ran out of the SoftOmni organization I am the BDFL of. If you want more frequent and a bigger insight into the day to day, I post daily end of day updates on our discord server which I will link to. I will still share big updates here when we hit major milestones or require your feedback.
Additionally, I'd like to state SwiftRD's policy for accepted Swift proposals. Parser work is going smoothly and we are getting it done. First order of business is to catch-up with a Swift 6.4 language level and validate the implementation for that language level... this will start with lexical and syntactic validation for SwiftRD and then of course semantics will follow. SwiftRD minor builds will have lexer, parser and core semantics up and ready for Swift features that were accepted as part of a future version of the language. This will make it so that you won't get red squiggles and things like syntax highlighting will still work. More comprehensive support for new features will arrive in subsequent major updates. We are thinking of timing these with the Swift version release cadence past initial release.
Can't wait to try this out, especially for cross-platform SPM projects.