4 ms·

Thank you for the compliment! We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cas

Thank you for the compliment! We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support. We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6]. Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive. [1] https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md https://github.com/apple/swift-evolution/blob/main/visions/e... [2] https://www.swift.org/blog/sswg-update-2024/ https://www.swift.org/blog/sswg-update-2024/ [3] https://www.swift.org/blog/mlx-swift/ https://www.swift.org/blog/mlx-swift/ [4] https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/ [5] https://www.swift.org/blog/swift-everywhere-windows-interop/ https://www.swift.org/blog/swift-everywhere-windows-interop/ [6] https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...

airstrike 2y ago
I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO
serial_dev 2y ago
That's great and appreciated, and hopefully will have an impact in a couple of years. Today if I search for Swift jobs, it's a list of exclusively iOS app developer jobs.
terhechte 2y ago
Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes. The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it. If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).
- userm0d 2y ago
  We already have a NeoVim plugin [0] that makes replacing Xcode somewhat possible. It's not perfect and requires that you have Xcode around for certain scenarios but I have been using it as my daily driver for the last month. I think you would only need xcode-build-server [1] in order to get autocompletion in VSCode. [0] https://github.com/wojciech-kulik/xcodebuild.nvim https://github.com/wojciech-kulik/xcodebuild.nvim [1] https://github.com/SolaWing/xcode-build-server https://github.com/SolaWing/xcode-build-server
  - terhechte 2y ago
    Thank you! Personally I actually prefer Neovim over vscode, so this is awesome. will try it out.
- Zanfa 2y ago
  What works quite well for iOS/macOS apps is breaking the project into a barebones Xcode project plus a Swift package that contains all of the code. SPM projects work well with VSCode and you get full auto-complete support with the official Swift plugin.
  - terhechte 2y ago
    Thanks for the suggestion, I'll give that a try. Obviously this will not work with large existing codebases; but for new projects I'll try how well it works.
ziziman 2y ago
It was pretty great to see an official swift support for playdate
pjmlp 2y ago
Overall it should provide a better experience than Objective-C even with GNUStep, never managed to offer without the NeXT or Apple's frameworks and IDE tooling. So far, every time I play a bit with it, the experience doesn't seem much better, as naturally most packages assume Apple platforms, and VSCode isn't XCode. Has the issue with manually reaching out for OS APIs instead of Foundation already been fully sorted out? Having samples directly referring to Glib and similar, instead of standard Swift, wasn't that interesting. Also the lldb issue with Python bindings not being found seems to still exist, even on the container images. However, I also acknowledge that many things seem to have improved, so there are also quite a few positives.
Decabytes 2y ago
I’d love if Swift supported easy cross compilation in the same way that Zig does. The fact that I can just download Zig and everything will just work without tinkering is nice

airstrike 2y ago

I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO

serial_dev 2y ago

That's great and appreciated, and hopefully will have an impact in a couple of years. Today if I search for Swift jobs, it's a list of exclusively iOS app developer jobs.

terhechte 2y ago

Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes. The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it. If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).

userm0d 2y ago
We already have a NeoVim plugin [0] that makes replacing Xcode somewhat possible. It's not perfect and requires that you have Xcode around for certain scenarios but I have been using it as my daily driver for the last month. I think you would only need xcode-build-server [1] in order to get autocompletion in VSCode. [0] https://github.com/wojciech-kulik/xcodebuild.nvim https://github.com/wojciech-kulik/xcodebuild.nvim [1] https://github.com/SolaWing/xcode-build-server https://github.com/SolaWing/xcode-build-server
- terhechte 2y ago
  Thank you! Personally I actually prefer Neovim over vscode, so this is awesome. will try it out.
Zanfa 2y ago
What works quite well for iOS/macOS apps is breaking the project into a barebones Xcode project plus a Swift package that contains all of the code. SPM projects work well with VSCode and you get full auto-complete support with the official Swift plugin.
- terhechte 2y ago
  Thanks for the suggestion, I'll give that a try. Obviously this will not work with large existing codebases; but for new projects I'll try how well it works.

ziziman 2y ago

It was pretty great to see an official swift support for playdate

pjmlp 2y ago

Overall it should provide a better experience than Objective-C even with GNUStep, never managed to offer without the NeXT or Apple's frameworks and IDE tooling. So far, every time I play a bit with it, the experience doesn't seem much better, as naturally most packages assume Apple platforms, and VSCode isn't XCode. Has the issue with manually reaching out for OS APIs instead of Foundation already been fully sorted out? Having samples directly referring to Glib and similar, instead of standard Swift, wasn't that interesting. Also the lldb issue with Python bindings not being found seems to still exist, even on the container images. However, I also acknowledge that many things seem to have improved, so there are also quite a few positives.

Decabytes 2y ago

I’d love if Swift supported easy cross compilation in the same way that Zig does. The fact that I can just download Zig and everything will just work without tinkering is nice