Expanding Swift's IDE Support
swift.org102 points by frizlab 11 hours ago
102 points by frizlab 11 hours ago
This is a very welcome improvement but I should note the title is a bit clickbaity: using Swift on e.g. Cursor was always possible, it's just that after Microsoft banned forks from accessing the official VSCode marketplace last year you started having to workaround it by downloading and installing the .vsix file manually. Having the extension on the Open VSX Registry sorts this out so you can now install it via the proper way once more. Very happy this finally happened!
But can I develop iOS apps with vim? As in, easy to execute commands for debugging, running app and tests?
I think swift is a really great language from the design perspective.
What makes it unusable outside the apple ecosystem imho is that while the C interop is amazing on paper, it sucks hard in practice due to the abomination of pointer types they build in.
The "all pointers are evil" attitude doesn't help when you want to use a C library and noone will write rewrite all these libraries.
Some recent fixes went into 6.2.3 which really help with C interop, this post shows what that looks like in practice https://www.swift.org/blog/improving-usability-of-c-librarie...
Not to be that agentic coding guy, but I think this will become less of a problem than our historic biases suggest.
For context, I just built a streaming markdown renderer in Swift because there wasn’t an existing open source package that met my needs, something that would have taken me weeks/months previously (I’m not a Swift dev).
Porting all the C libraries you need isn’t necessarily an overnight task, but it’s no longer an insurmountable mountain in terms of dev time.
My favorite part is the AI will still estimate projects in human-time.
“You’re looking at a multi-week refactor” aaaaand it’s done
Yeah lol. “I estimate this will take 15-20 days” I do it in like 5 hours lol
Very high quality comment that is being downvoted unfairly because it defends AI. HN is on the wrong side of history on this one.
This is huge, long time coming. Interested to see if there is SwiftUI support.
This extension is for "pure" Swift development, not iOS development. I doubt the latter will ever officially happen. It's possible to make it work for iOS at an unofficial capacity though by hooking into the extension's LSP support. We did this at Spotify to enable iOS development in Cursor for Bazel iOS projects: https://github.com/spotify/sourcekit-bazel-bsp
You also can't do Android (app) development outside Android Studio.
As others have stated it's possible, but might be cumbersome.
I made an example of an iOS/Android monorepo with a shared Rust core a few months ago: https://github.com/Antonito/bazel-app-core-native-example/
You do need the Android SDK to build, Android Studio makes things easier (even though the Bazel IDE plugin is a whole other topic itself..) but isn't mandatory to develop or run your app.
Are you sure about that? Flutter development for Android works great in VS Code/Codium. The Android extension [0] for VS Code has also worked fine in the past on a small Java-based App for me.
Android Studio is a probably the best IDE for this usecase but is not the only way.
[0]: https://marketplace.visualstudio.com/items?itemName=adelphes...
That's just untrue on the face of it. All of the build tools are open and cross-platform. Is there a specific piece of Android Studio that you require for Android app development?
Not certain if this answers the question, but it seemed like you're generally expected to install Android Studio to get the correct build versions of all of the tools and libraries. I guess theoretically you could repackage them yourself, but also not entirely clear why you would—other than perhaps download size. The tools can be driven externally, once installed, but so could XCode projects (with `xcodebuild`).
This is not an expectation, no. Libraries are managed via Gradle or whatever build system you use. Android-specific host tools are Gradle-managed, installed via the sdkmanager tool, or managed via other means; I maintain a repository to install them via Nix [0], and many Linux distributions package them. The Android Studio IDE is not required, and doing so would pretty much break everyone's CI setup.
They've always offered a bundle of the command line tools separately to Android Studio:
https://developer.android.com/studio#command-line-tools-only
Incorrect. You can (if you really want to) build an Android app without having any Google tools.
But even if you don't want to do any crazy stuff, Android SDK itself is just a bunch of Gradle scripts and Java apps. You can download and install them without any GUI in the way.
This is very common in CI/CD environments. Google provides a handy tool for that: https://developer.android.com/tools
Sorry, but Android and iOS are simply incomparable in their quality. Android SDK is a high-quality tool for developers that provides all the expected interfaces.
iOS SDK is a lock-in GUI hell that requires you to use a shitty macOS-only tool to even _upload_ apps to Apple Store. Never mind doing headless builds in CI/CD. Why that tool is shitty? It uses its own protocol for upload and doesn't do proper PMTU, so if you have a misconfigured MTU somewhere in the chain between you and Apple, uploads will just silently hang.
Edit: D'Oh, the correct URL for the sdkmanager is: https://developer.android.com/tools/sdkmanager
Just to nit pick a bit, that link is for Android Studio and downloads from the "Google for Developers" website, then instructs how to install and manage the the command line tools using the GUI
Not trying to argue but you can indeed pretty much completely avoid Xcode at this point. I’ve been doing it the past few weeks, including pushing to my phone and AppStore connect
What's the point then? Because nobody use Swift outside of iOS app development.
> Because nobody use Swift outside of iOS app development
Because that isn't true, people do use it outside of iOS app dev, and is becoming more true as time goes on to boot.
It's also a chicken-and-egg problem: no one will use Swift for non-iOS tasks if the tooling support isn't there. The more investment into it, the more it will be picked up for other tasks.
But it's been used outside of Apple-specific things since the early days in various niches.
I've been migrating my DikuMUD (originally C) to Swift for years! It's been pretty fun and Swift is a great language for it
No so straightforward, but there is project that parses xcodebuild logs and pass them to lsp to provide LSP for SwiftUI projects https://github.com/SolaWing/xcode-build-server
Also I build extra tooling to facilitate iOS development in VSCode https://github.com/sweetpad-dev/sweetpad
Thanks for your great work on sweetpad. I’ve always been a bit curious where the name came from though.
i was hoping this was going to be AppCode rising from the grave but nah it's just more rebranded versions of VSCode. nothing new here
Use swift as a scripting language without the slow start time:
Swift Caching Compiler - https://github.com/jrz/tools
Everyone should post to open-vsx by default.
I recently started to enjoy working in Xcode more than before, using Swift. Not sure what changed, but it seems more responsive for lack of a better expression.
Is there an open—source Swift IDE that can modify itself without restarting? (written in Swift) I loved Oberon µSystems Oberon/F aka Component Pascal for that capability.
Or am I going to have to vibe-code one.
Now if only they'd open up iOS development so we can get AppCode back.
The primary thing keeping me away from trying it again is I have to use Xcode instead of my beloved JetBrains IDEs where I know all the keyboard shortcuts.
The loss of AppCode from Jetbrains was a huge blow to my motivation to continue working with Swift. Xcode just can't compare.
I've recently been using this plugin [1], which is still under development but is an adequate stopgap until a better solution comes along.
[1]: https://plugins.jetbrains.com/plugin/22150-noctule-the-swift...
[flagged]
What the heck type of software are you shipping that you can just avoid looking at the slop the LLM serves you?
The person you are replying to lives in the best of all possible worlds. I'm sure all is for the best within the code his LLM generates.
We’ve used SweetPad and it worked fine for us, so this doesn’t change much.
TLDR: same VScode extension now listed on OpenVSX registry, for Eclipse Theia et al.
But it's unclear if they tested it. For me, it fails basic configuration steps on the simplest project. Plugin compatibility between VSCode and others seems iffy.
Couple this with Xcode 26.4 AI lacking agentic features and you get Swift programmers being left behind.