Swift 6 was released about a month ago and according to the language matrix, there isn’t support for Swift 6 yet, with only partial support for Swift 5.9 and full support for 5.8 and older. SonarCloud is a key part of our build pipeline - so is there a roadmap available for when support for the latest version will be added, to help guide our own timelines to update our applications to Swift 6?
Hi Darrell,
Thanks for bringing this up, and welcome to the Sonar Community.
We have planned work on the remaining parts of Swift 5.9 and Swift 6.0 for this quarter.
However, there are complex new semantics, and there is some risk that we will not fully support both this year. We’ll do our best to unlock users like you so that you can use the latest version of Swift.
thanks Gabriel! any updates on this?
Hi Gabriel
I was wondering if you have any update on Swift 6.0 support (and also 6.1 which was recently released).
Are there any new status updates on modern Swift support? As of today, applications must be submitted to Apple with Xcode 16, which means a minimum Swift version of 5.10. There is no version of Sonarqube that can successfully parse even Swift 5.10 syntax, and at our company that means a significant number of our files have parsing errors on what has become standard and best practice Swift syntax over the past few years.
We’ve also had to disable a large number of rules that do not work in a SwiftUI world due to the number of false positives. We’d continue to use this without issue if we could only use it for coverage data and import third-party analysis issues, but it seems that the static analysis and the coverage portions are tightly coupled, so we have no choice but to manually work around these issues until Sonarqube’s Swift support is brought up to date.
any timelines for Swift 6 support would be greatly appreciated
or another thought: we turned on ‘Default Internal Imports’ in Build Setting section ‘Swift Compiler - Upcoming Features’, so we had to add a bunch of ‘public import’ statements in our code, but that’s breaks SonarQube parsing.
Is there a way to avoid parsing errors for ‘public import’?
Is Swift support in SonarQube totally abandoned?
Something as basic as SwiftUI previews have been around since iOS 13/Swift 5.1 and there is still no way to make SonarQube disregard any code inside the preview (which is to be considered mock/test code that is only used by the preview and is never built into the app itself).
In case you didn’t know: Main problem here is that for the SwiftUI preview to have any value at all, it must be located in the same file as the view that it is previewing, so you can’t make a file mask to ignore.
Hello,
Thanks for your patience. First of all, I want to confirm that Swift support is not abandoned at all. These days, we are focusing on Kotlin and Dart, the other mobile languages. Some news will come soon about that.
This is true that not enough love was given to Swift in the past months. This is in our roadmap to restart our efforts for Swift in Q3 2025 to bring to you security rules. The results of this effort is expected to be available in Q4.
I’m aware that some rules are noisy on SwiftUI code. I would like to get from you the list of rules that you consider as not relevant on SwiftUI code so that we can fix that. If one of you can share this, that would be really appreciated. Normally it should be rules about function’ complexity and number of arguments.
@sri_sundhed I would like to have a call with you to dig into this topic of SwiftUI+Preview to be sure to understand the problem. If you can book a meeting with using this link, that would be great.
To all users having trouble with the current Swift support, I would like to see this live during a call, so don’t hesitate to book a meeting with me.
My current plan is to:
- collect all the pains from you
- prioritize the quick-win fixes
- release them ASAP
- work in peace in Q3 on security rules (on the related new Swift analyzer)
Regards
Alex
Hey @Alexandre_Gigleux , is Swift support still within the plan in Q3 and Q4? We’ve been watching SONARSWIFT-617, SONARSWIFT-619, and SONARSWIFT-620 as well as other things in the SonarSwift backlog, and while it’s great that we’re getting security rules, we’re wondering if that at least starts to fix some parsing rules as well since that’s our highest priority.