Unfortunately, it took me some digging to realise that this extension is primarily built for packages, not XCode-managed .xcodeproj projects [1].
This means that, unless I'm missing something, you can't open your existing project in VSCode like you could with AppCode.
Overall, I'm unhappy with the tooling around Swift. The compiler is slow, the formatters and linters are worse than in the javascript-ecosystem, and since AppCode is sunset, there's only a single supported IDE which I dislike. I frequently run into issues where the compiler won't give me a useful error message until I simplify my code, and the SwiftUI previews don't seem to work at all.
I wonder how big the market is for this. Despite being an actually nice language, Swift is not that popular outside Apple's ecosystem, so I guess most developers would use XCode for it's integration (with Apple Developer, SwiftUI/preview etc).
I don't think XCode is exactly popular or viewed as anything other than necessary evil by many Swift app developers. Like a sibling comment mentioned, many people already use other IDEs to write the code and just use XCode to compile stuff because it is just so ass. Get the compiler invocation experience and maybe even the Apple Developer integration to a decent enough shape in a VS Code extension and XCode can start counting its days methinks.
> many people already use other IDEs to write the code and just use XCode to compile stuff
I've never met anyone who actually does this. JetBrains is even discontinuing AppCode, which as far as I know was the only real alternative IDE (and it had a lot of holes in its functionality).
Xcode lacks decent refactoring tools but otherwise it's a perfectly fine IDE, and has some really powerful debugging abilities. Don't get me wrong, I don't think Apple is giving it the attention it deserves, but in my experience most people hate it just because it isn't IntelliJ or VSCode.
I’ve only started learning Swift, so I don’t know how it performs on bigger projects, but so far I’ve been loving playgrounds, if not for the dog-slow compilation, but that’s in-character for all LLVM-based compilers, so maybe not exactly XCode’s fault.
Slowly but surely things are getting better in terms of cross-platform, with the latest in that realm being Apple itself committing to an open source rewrite of Foundation, which will fill in some holes and improve consistency on non-apple platforms.
Swift on server has been usable for a while now too.
I think the next big bottleneck on popularity will be tooling, and a solid VS Code extension is a small step forward in addressing that issue.
As someone who’s been using Swift for years on iOS/macOS, I’d love to use it for desktop development on Windows and Linux. I think the language is well suited for that purpose, and it strikes a nice balance between safety, speed, features, ease of writing, and clean syntax which isn’t matched by too many other languages.
Well, with WASM everywhere I think that it might realize some of its potential as tooling improves. Don't you want to write your algorithms and data structures in such a nice language? Slap the native UI, when in iOS its SwiftUI and when on the web its ReactJS or something and when its on Android its whatever Android uses but have your actual processing of the user inputs in Swift.
The traditional cross platform approach is to write it in JS and use the native UI framework API, which works but its not native anywhere and you have to write JS.
So instead of doing that, you can start with Apple platforms and port to the other platform where porting would mean just UI and device specific API implementation as the Swift can be portable. You wouldn't be trying to build native UI with Swift but you would use the Swift code as a service which handles everything except the UI where the UI implementation will communicate with your Swift code.
The advantages are:
1) Working with Swift, which is pleasant to work with.
2) Apple's all platforms are on the same architecture and as a result, running your code for mobile on your dev machine works at full speed. This means, even the cheapest Apple Silicon device provides great performance on your workflow. No more sluggish emulators.
3) Preserve the data structures across all platforms and these data structures are not JS data structures. You have integers for example :). Categories of bugs and work to make things fit vanish.
I agree. I personally find XCode absolutely bewildering.
The several times I've tried to do anything with it, I just gave up and found an alternative. My guess is that if you've been using Apple tools for years, then it makes sense, but to me it's indecipherable. The menu options don't seem to match with the GUI, resource views don't seem to match the files, random panels appear with unnecessary information, resources are needed for unclear reasons and more.
It's all very Apple, but in the worst way possible. It's like the IDE version of AppleScript - seemingly useable but based on a logic which totally escapes me.
The use case is mainly for writing packages, command line tools or server side components where the Swift toolchains are quite nice to work with. The experience is very much like using Rust or Go.
It’s such a shame, i really envy some of the features in Swift but I just can’t justify the risk with how Apple-centric it is. Too many times I’ve been bitten by ducks that quacked just like that one, I suppose.
I’d love to see like a gccSwift the way there’a a gccRust coming together. I think that would be really cool.
You can already develop Swift code on non-Apple equipment
You can’t develop for iOS as their frameworks are as of now (this is changing, they’re rewriting Foundation) tied to macOS, so this doesn’t change much
Both things the original Visual Studio had over a decade ago.
I think the new generics system is finally making the language more usable for the typical scenarios I like to tackle with it. What still baffles me is that it's impossible to create protocols that have stuff like @Published in them. Massively decreases / complicates / uglifies reusability opportunities in ViewModels.
My brain and fingers hurt using the vim keybindings in Xcode. Looking forward to trying this extension out in VSCode which has far superior vim keybindings.
The vim keybindings that Xcode has implemented work fine for me, but some omissions like using the period character to repeat the last action are quite debilitating.
I wish there is something like this for Kotlin and Android development. One of these I might Android development just because of the shit its development and build environment is — Android Studio, Gradle etc. What a glorious mess!
And in December an effort was started to get Copilot in Xcode[1] when it was previously limited to only in Jetbrains AppCode. Now we have two options for Swift Copilot.
Readit News
This means that, unless I'm missing something, you can't open your existing project in VSCode like you could with AppCode.
Overall, I'm unhappy with the tooling around Swift. The compiler is slow, the formatters and linters are worse than in the javascript-ecosystem, and since AppCode is sunset, there's only a single supported IDE which I dislike. I frequently run into issues where the compiler won't give me a useful error message until I simplify my code, and the SwiftUI previews don't seem to work at all.
[1]: https://github.com/swift-server/vscode-swift/issues/128#issu...
I've never met anyone who actually does this. JetBrains is even discontinuing AppCode, which as far as I know was the only real alternative IDE (and it had a lot of holes in its functionality).
Xcode lacks decent refactoring tools but otherwise it's a perfectly fine IDE, and has some really powerful debugging abilities. Don't get me wrong, I don't think Apple is giving it the attention it deserves, but in my experience most people hate it just because it isn't IntelliJ or VSCode.
If by many, you mean less than 1%, then yes. :)
Swift on server has been usable for a while now too.
I think the next big bottleneck on popularity will be tooling, and a solid VS Code extension is a small step forward in addressing that issue.
As someone who’s been using Swift for years on iOS/macOS, I’d love to use it for desktop development on Windows and Linux. I think the language is well suited for that purpose, and it strikes a nice balance between safety, speed, features, ease of writing, and clean syntax which isn’t matched by too many other languages.
The traditional cross platform approach is to write it in JS and use the native UI framework API, which works but its not native anywhere and you have to write JS.
So instead of doing that, you can start with Apple platforms and port to the other platform where porting would mean just UI and device specific API implementation as the Swift can be portable. You wouldn't be trying to build native UI with Swift but you would use the Swift code as a service which handles everything except the UI where the UI implementation will communicate with your Swift code.
The advantages are:
1) Working with Swift, which is pleasant to work with.
2) Apple's all platforms are on the same architecture and as a result, running your code for mobile on your dev machine works at full speed. This means, even the cheapest Apple Silicon device provides great performance on your workflow. No more sluggish emulators.
3) Preserve the data structures across all platforms and these data structures are not JS data structures. You have integers for example :). Categories of bugs and work to make things fit vanish.
The several times I've tried to do anything with it, I just gave up and found an alternative. My guess is that if you've been using Apple tools for years, then it makes sense, but to me it's indecipherable. The menu options don't seem to match with the GUI, resource views don't seem to match the files, random panels appear with unnecessary information, resources are needed for unclear reasons and more.
It's all very Apple, but in the worst way possible. It's like the IDE version of AppleScript - seemingly useable but based on a logic which totally escapes me.
It’s just “dnf install swift” and you’re all set.
I would love to see more Swift adoption, I know at one point IBM was investing in it for server-side programming, but I think they’ve abandoned that.
It seems to be a nice sweet spot of relatively easy to code, expressive, powerful, memory safe, and performant.
I’d love to see like a gccSwift the way there’a a gccRust coming together. I think that would be really cool.
It also opens up the potential for development on non-Apple equipment if the CI can handle builds.
You can’t develop for iOS as their frameworks are as of now (this is changing, they’re rewriting Foundation) tied to macOS, so this doesn’t change much
* Smarter refactoring like "extract protocol"
* Detection of unused imports and dead code
Both things the original Visual Studio had over a decade ago.
I think the new generics system is finally making the language more usable for the typical scenarios I like to tackle with it. What still baffles me is that it's impossible to create protocols that have stuff like @Published in them. Massively decreases / complicates / uglifies reusability opportunities in ViewModels.
[1] https://news.ycombinator.com/item?id=33994406
[1] https://github.com/intitni/CopilotForXcode
Link 2: It has release notes with no new information.
Link 3: Available here:
https://marketplace.visualstudio.com/items?itemName=sswg.swi...