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.
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.
Swift Caching Compiler - https://github.com/jrz/tools
Or am I going to have to vibe-code one.
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.
Also I build extra tooling to facilitate iOS development in VSCode https://github.com/sweetpad-dev/sweetpad
A blessing, some might argue.
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.
[1]: https://plugins.jetbrains.com/plugin/22150-noctule-the-swift...
Otherwise swift works just like any other clang/llvm project and the tooling is basically the same.
How do I call this function in swift?
SDL_AudioSpec* SDL_LoadWAV_RW(SDL_RWops * src, int freesrc, SDL_AudioSpec * spec, Uint8 * * audio_buf, Uint32 * audio_len);
“You’re looking at a multi-week refactor” aaaaand it’s done
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.
Nice catch.
edit: you are right. The binary version will result in a different argv[0]. Not sure what'd the best solution would be. Hardcoding doesn't make sense, as symlinks also change argv[0], so overriding is not the way to go.
I hate vibecoding. The cognitive toll is higher than you expect, the days feel fast, but the weeks move slowly.
With that said, these are the new compilers. Hopefully they make some software better[1] even with the massive increase in slop.
[0]https://gist.github.com/jumploops/b8e6cbbce7d24993cdd2fe2425...
It’s a nice tool, nothing more, nothing less. Anything else is marketing nonsense.
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.
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...
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
That aside, there was a larger point I was making that was lost in the forest because you poking at a tree. iOS apps are more than Swift. Metal was one example, there are plenty of other tooling components that absolutely suck to use in vim, or just missing support entirely. Bundle management, plist files, custom build phases, code signing, asset previews, canvas previews, interface builder, profiling, and unit testing UI is a bunch of stuff that has nothing to do with swift, sucks in vim, and integral to application development.
Found a bug while backpacking Sardinia? Edit the GitHub repo source on your phone, commit... hey, new build shipped.
See the App Store Connect mode: https://developer.apple.com/xcode-cloud/
https://developer.android.com/studio#command-line-tools-only
So my options are a 40gb compilation runtime, or a cloud build that bills me by the hour to avoid the 40gb compilation runtime.
You gotta hand it to Apple, any other audience would just call this "enshittification" and be done with it.
Tracy is a member of the Build and Packaging Workgroup and works on Swift tooling at Apple.
April 8, 2026
You can now write Swift in a broader range of popular IDEs, including Cursor, VSCodium, AWS’s Kiro, and Google’s Antigravity. By leveraging VS Code extension compatibility, these editors tap directly into the Open VSX Registry, where the official Swift extension is now live.
Swift has long supported development using multiple IDEs including VS Code, Xcode, Neovim, and Emacs. Swift is also compatible with editors that implement the Language Server Protocol (LSP). This growing ecosystem of editor support is particularly significant as Swift continues to show its versatility across platforms and development environments, including agentic IDEs.
The Swift extension for VS Code is now officially available on the Open VSX Registry, the vendor-neutral, open source extension registry hosted by the Eclipse Foundation. The extension adds first-class language support for projects built with Swift Package Manager, enabling seamless cross-platform development on macOS, Linux, and Windows. This milestone brings Swift support, including code completion, refactoring, full debugging support, a test explorer, as well as DocC support, to a broader ecosystem of compatible editors and allows agentic IDEs like Cursor and Antigravity to automatically install Swift, with no manual download required.

Swift in Cursor, powered by the Swift extension on Open VSX.
To start using the Swift extension in any Open VSX-compatible editor, simply open the Extensions panel, search for ‘Swift’ and install the extension.
If you’re using Cursor, getting started is easier than ever. Check out our new dedicated guide: Setting up Cursor for Swift Development. It walks you through the setup, features and includes how to configure custom Swift skills for your AI workflows.
Swift now has support for a wider range of modern editors and IDEs to meet developers where they are. Download the extension, try it out in your editor of choice, and don’t forget to share your feedback!
March 31, 2026
Welcome to “What’s new in Swift,” a curated digest of releases, videos, and di..