Request for your feedback / current status

[jansorg]

Request For Your Feedback

I'd like to ask for your feedback.

For example, what's the missing feature you need the most to work with the plugin?
Or, what is biggest limitation of the currently available version of Swift Support?

Below, there's a list of features I'm considering to add. What's your favorite?

• Basic support for XCode projects, most likely with the help of xcode-build-server 
• Debugging of Swift binaries using the IDE's debugger user interface, based on Swift's lldb-dap
• Integrating a test runner, supporting XCTest and the new Swift Testing of Swift 6.0
• Additional formatter options based on nicklockwood/SwiftFormat
• Try to make use of sourcekit-lsp's experimental support for building in the background to provide up-to-date results in the editor during editing

Status of Development

The development has been slower and more difficult than I expected.
There are several reasons:

• I'm not an experienced Swift developer myself and I don't know what's really needed to make this a great tool
• It's a complex ecosystem. There are several project models (Swift PM, XCode), there are several test frameworks, there are several platforms and SDKs to support and so on.
• sourcekit-lsp has limitations and doesn't always provide what an integration into JetBrains IDEs needs. The most problematic limitation is that a "swift build" is required before features like code completion or rename work. 

In the meantime, I've rewritten the Language Server integration library for a better integration into the IDE. For example, this will add support for formatting with sourcekit-lsp, which is based on swift-format. The next major update of the plugin will include this feature.

Thank you for your support!

[JohanVase]

I could not get the plugin to work for my iOS project, so support for iOS will receive my vote. It is likely that this is due to the missing "Basic support for Xcode projects", but I honestly do not know if this is the only/easiest way to get iOS projects working...?

[jansorg]

When you write code, do you use AppCode's formatter or do you rely on an external formatter and/or linter?

Based the tooling provided by Apple (i.e. sourcekit-lsp), "Find usages" relies on an up-to-date build. There's a "build while editing" thing now in the later versions, but it's only for current versions of the toolchains and experimental. Hopefully I'll find a way to make this work better...
AFAIK JetBrains implemented their own "Find Usage". If you used XCode's find usages (if there's one), do you think AppCode is providing better or worse results?

[JohanVase]

I think AppCode provides much better results than Xcode's "Find usages". There are many places where Xcode do not provide a "Find usages" option, for example on init() method and on classes and protocols. And the way usages are displayed in AppCode is also much easier to read for me (maybe because I used Jetbrains tools for 20 years - it is hard to teach an old dog new tricks 😉).

Also, AppCode has a very nice icon next to protocols and protocol implementations (incuding all its functions) that makes it easy to jump back and forth between the protocol and its implementation. This is also a much missed feature in Xcode.

I use AppCode's formatter for formatting, but I am trying to have approximately the same formatting setup in Xcode and AppCode such that they do not conflict when switching. Also we have SwiftLint to force specific formatting.

[ronniebarker]

For me, I use AppCode exclusively for formatting. We use multiple JetBrains products and try to maintain a consistent style across all projects

[brainray]

AppCode is much, much, much better in doing "Find usages" than Xcode. The funny thing is, that the most devs that not use AppCode don't seem to miss it, because they never knew it... I also love the Git conflict management of the Jetbrains products, but far better and faster than everything else.
Meanwhile I use Xcode most of the time, because AppCode really doesn't run nicely with our medium large project. But I'm looking for a solution like your plug-in.

[jansorg]

1.4.2. (instructions at #48) allows for a xcode-build-server integration.
But may not solve the problem of "Find usages". If sourcekit-lsp provides better results than XCode, then it should help. AppCode had its own implementation to locate code usages, so there may be differences between XCode and sourcekit-lsp and AppCode.

[ronniebarker]

I'm trying to find a replacement to ios app development in AppCode. The most important feature is being able to work with xcode projects. Support for the old xcode project format for legacy apps - but, more importantly the new xcode format that AppCode doesn't support (hence the growing need for an alternative).

Generally:

• Language support
• Code style
• Refactorings

For me, debugging will be in xcode - so that's definitely not a priority.

We currently run the tests in xcode as well - mostly because AppCode is stuck at iOS15.2 / Xcode14.2 - but that makes it really hard to keep the cycle short and TDD almost impossible so running the

[jansorg]

Are you mostly using XCode as a replacement or have you tried an alternative like VSCode, for example?

JetBrains terminated AppCode for a reason and I need to find a way to make things work differently.

[ronniebarker]

I'm using AppCode as a replacement for XCode. I have never got on with VSCode - and as a long-ago Visual Studio user, kept away from it since Microsoft adopted it. We have always preferred JetBrains (even as far back as Resharper in Visual Studio) and spent most of our time in Rider so I am really looking for solutions to stay in JetBrains as much as possible. That helps us to have consistent styling and tooling across all of our projects.

It feels very hard to get away from Xcode when developing for ios. We find ourselves switching to xcode to build/run/debug and do the annoying apple-y plist things - but the developer experience is just terrible if you use any other tool ever for anything else. I imagine that people who only ever use xcode are fine with it...

[jansorg]

1.4.2, #48, now allows a xcode-build-server setup. I'm planning to integrate this in later versions, early testing of the integration seems promising to me.

[KotlinFactory]

Would love to see further focus on the serverside and improved support for frameworks like Vapor. A lot of people seem to use it for this: https://www.reddit.com/r/swift/comments/1imi03c/using_jetbrains_rider_with_swift_vapor/?tl=de

[jansorg]

Thanks for the feedback and the link!
I know that the current state of the plugin isn't very good, I'm working on it, but it's slow 😞

[KotlinFactory]

Thank you so much for working on it, I would love to see any JetBrains IDE support Swift development.

[jansorg]

Could you all comment which version of Swift you normally use?
The latest version (6.x) provides the best support (i.e. LSP-support), but I'm wondering if I could require or recommend this version or if most are usually on older versions.
Thanks!

[johan-mjolner]

On my project, we are still on Swift 5, but I personally think it would be ok to recommend (or maybe even require) Swift 6 if this makes development faster for you. Then we must "bite the bullet" and start the conversion (which Apple will likely require anyway at some point...)

[johan-mjolner]

As an additional comment: I think that if it makes it easier for you, it is OK to generally require and support only the latest features of Swift/Xcode (for example the latest Xcode Project format). All projects can be updated to use the new standards and features. And old standards can still be handled by AppCode.

Our problem is that AppCode is not updated anymore, meaning that, for example, we cannot convert our projects to the new Xcode project format. This is where your plugin will shine and help a lot of people.

[brainray]

We are also still on Swift 5 and I don't think we will change that soon, because this takes quite some attention. IMHO the most larger projects are still on Swift 5, maybe slowly evolving toward Swift 6.

[jansorg]

As an interim update, I've published version 1.3.0 (announcement).

Formatting can be controlled with a swift-format configuration file. I'm still considering better support for formatting in the future. The current state is what's provided out of the box by SourceKit-LSP.

[cbackas42]

Assuming I'm not too late for this thread, I'd like to throw in a vote for debugging. I'm writing Godot plugins using SwiftGodot, and currently using VSCode and its debugger to do it. But I'd much rather use Rider if I can. Launching the Godot process and attaching to it to debug my plugin is essential.

[strengthiness]

I think the best thing that could be done right now is a Getting Started guide.

I have a Swift project. How do I load it properly? Can I load a project started in Xcode or does it have to be a Swift Package Manager project? Do I open the folder/directory containing the project or a specific file to trigger the project load? Do I need to setup any Modules in Project Settings? What can and can't I do? What do I need to outsource to Xcode or the CLI compiler?

I want to use this, but I need to know how to use it and any conditions that must be met in order to use it. We know there will be limitations, as this is a solo passion project. List the limitations so we clearly know what to expect.

(You may also want to consider opening the project up, even if just to private contributors, in order to get a little more traction and momentum.)

[RowSalmon]

A getting started guide or getting started video !

[jansorg]

Version 1-6-0 has been released and hopefully address the lack of documentation, #53

[robmoore-i]

The one feature I really need is for show uses / jump to definition to work in an iOS project. (I'm using Swift 6.1). I used AppCode when it was up-to-date and since it left I've loathed working on my iOS app because I have to use XCode. All I want is the ability to navigate the codebase. I don't need any fancy refactoring or even the ability to rebuild the app. I just want to navigate and read my code without constantly using the mouse.

[jansorg]

I'm working on improved XCode support now.
I'm not sure yet how good it's possible to make such an integration, but hopefully usable.

[brainray]

The one feature I really need is for show uses / jump to definition to work in an iOS project. (I'm using Swift 6.1). I used AppCode when it was up-to-date and since it left I've loathed working on my iOS app because I have to use XCode. All I want is the ability to navigate the codebase. I don't need any fancy refactoring or even the ability to rebuild the app. I just want to navigate and read my code without constantly using the mouse.

This is the most desired feature any Appcode user wishes for Xcode. The funny thing is, that those who haven't worked with the Jetbrains platform don't know what they are missing.

[jansorg]

The solution will be based on xcode-build-server.
With manual setup and building in XCode (or via xcodebuild as shown in the Readme of xcode-build-server), navigation is already possible with the current version. SourceKit LSP is automatically picking up the buildserver.json file created by xcode-build-server.

I'm planning to allow to choose the current XCode project scheme/target (as in XCode) and to support building via xcodebuild in the IDE to update the build data needed by xcode-build-server (and SourceKit LSP) to provide navigation, etc.

If possible, I'll support running XCTest tests via xcodebuild test with a new XCode Test run configuration and expand the existing Swift Package Test to support XCTest output.

Ideally, launching a simulator etc. via the IDE will be possible, too. But that's likely to land after all the other work has been done.

[humblehacker]

Might be useful to check out xcede: Build, run, debug and test Xcode projects outside Xcode. It's working well for me in Zed.

[Miszo97]

Do breakpoints work for you as well?

[jansorg]

I wanted to post a quick update on the current progress.

I'm working on improved integration for and support with XCode.
Please share your comments to make XCode integration useful for your use-cases!

The development version can now parse XCode project files and XCode workspace files. This is needed to tell the IDE about the structure when a directory with an XCode workspace or XCode project is opened. This is also useful for the new XCode workspace project view (see the screenshot).

As next steps, I'm planning to provide a quick selection box (in the toolbar or similar) to choose the current XCode scheme and build target and to automatically build via xcode-build and then integrate with xcode-build-server to launch the sourcekit-lsp server.
This is likely to change as XCode integration is a huge piece of work. But I'm pretty sure that it'll be helpful enough.

The plan for project handling is that you can File > Open.. a .xcodeproj or a .xcworkspace directory and that Noctule takes care of the rest to setup XCode, xcode-build-server and so on.

The new project view is similar to JetBrains' KMP view, but it's not overriding the main project view with XCode elements.
This is still a very early state. I'm planning to show package dependencies and more of the project structure.

Noctule XCode project view:

XCode with the same project:

[jansorg]

As a quick status update on Xcode support.
With the in-development version, you can now

• open a directory with an Xcode workspace and/or project to import it.
• choose scheme and location in the main toolbar, as in Xcode
• build with xcodebuild using the Build menu actions
• configure a project with xcode-build-server with a dedicated action (clean, build, xcodebuildserver config, restart LSP)
• configure default settings for xcodebuild

A major change is that it's now also possible to use Xcode support in remote development mode, i.e. the build log, scheme selector, etc. all work if you're running the IDE backend remotely on macOS, but the frontend on Windows, Linux or others

Before the first release, I'll

• add run configurations for xcodebuild
• make the test runner work with Xcode projects
• stabilize the whole thing

[KotlinFactory]

Thanks for the update, this is moving in a very useful direction.

The pieces that stand out most to me are scheme/location selection in the toolbar, xcodebuild integration, the dedicated xcode-build-server action, and especially remote development support with a macOS backend. That combination covers most of the practical pain around using Xcode projects outside Xcode.

Once the run configurations and test runner pieces are in, I'm happy to try it on a real workspace and report back with concrete friction points.

[jansorg]

Thanks!
I hope to have something to test soon. I'll post an update here when there's a version to test.

The xcodebuild run configuration is implemented, I'm working on simulator handling atm (simulator run configuration, simulator tree toolwindow). It's all remote capable, but I'm not aware of a way to proxy the simulator output window. For now, a screen sharing is needed to view the simulator on the remote host (if remote development is used).

[Miszo97]

When are you planning to release this version? @jansorg
Are going to implement debugging iOS SwiftUI code directly inside JetBrains IDE
Are you going to bring Previews to the IDE too?

[jansorg]

I‘m hoping next week, perhaps the week after. Don‘t expect a complete solution, although it‘s working well here so far.

Debugging is planned, but not for the next update. AFAIK debugging is supported outside Xcode and thus can be supported.
Previews, on the other hand, are not supported outside of Xcode, if I‘m not mistaken. It won‘t be possible to support this.

Noctule has always been promoted a freemium/paid, even though everything is still free to use. Xcode support will be part of the freemium/ paid features, but the next update will still provide it unlocked.

[jansorg]

fyi, I published an eap release of Noctule 2.0. There's more information at #84

I'd be glad for your testing and feedback!

I'll polish 2.0 and hope to release a stable version soon.