26 ms·

Expanding Swift's IDE Support

138 points by frizlab 6mo ago

jgbuddy 6mo ago
This is huge, long time coming. Interested to see if there is SwiftUI support.
- nielsbot 6mo ago
  What type of support do you mean? Language checking? Live previews?
- rockbruno 6mo ago
  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 https://github.com/spotify/sourcekit-bazel-bsp
  - worldsavior 6mo ago
    You also can't do Android (app) development outside Android Studio.
    - tadfisher 6mo ago
      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?
      - manwe150 6mo ago
        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`).
        tadfisher 6mo ago
        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. [0]: https://github.com/tadfisher/android-nixpkgs https://github.com/tadfisher/android-nixpkgs
        daveoc64 6mo ago
        They've always offered a bundle of the command line tools separately to Android Studio: https://developer.android.com/studio#command-line-tools-only https://developer.android.com/studio#command-line-tools-only
    - cyberax 6mo ago
      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 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 https://developer.android.com/tools/sdkmanager
      - manwe150 6mo ago
        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
      - thejazzman 6mo ago
        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
      - Terretta 6mo ago
        On the contrary, commit your code to your GitHub repo, triggering Xcode cloud build to take it from there, build, test, deploy to TestFlight or store. 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.apple.com/xcode-cloud/
        cyberax 6mo ago
    - Antonito 6mo ago
      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/ 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.
    - c0balt 6mo ago
      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.android-dev-ext https://marketplace.visualstudio.com/items?itemName=adelphes...
    - myko 6mo ago
      what? this is super easy with vim and gradle CLI
  - QQ00 6mo ago
    What's the point then? Because nobody use Swift outside of iOS app development.
    - girvo 6mo ago
      > 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.
    - myko 6mo ago
      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
- hyzyla 6mo ago
  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 https://github.com/SolaWing/xcode-build-server Also I build extra tooling to facilitate iOS development in VSCode https://github.com/sweetpad-dev/sweetpad https://github.com/sweetpad-dev/sweetpad
  - sunnybeetroot 6mo ago
    Thanks for your great work on sweetpad. I’ve always been a bit curious where the name came from though.
    - wiseowise 6mo ago
      Sweet=sweeft=swift+pad?
- pezgrande 6mo ago
  I hate that I need to create an Apple account (with email and phone verification) just to be able download the sdk to use MacOS APIs. To make things worse I tried for like one hour to create an account and couldn't because for some reason I was no receiving the verification email.
rockbruno 6mo 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!
MaysonL 6mo ago
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.
- rafram 6mo ago
  That is a very specific set of requirements. I doubt it.
- mckn1ght 6mo ago
  If you could reimplement Emacs in Swift that’d be great
castral 6mo ago
The loss of AppCode from Jetbrains was a huge blow to my motivation to continue working with Swift. Xcode just can't compare.
- doctorpangloss 6mo ago
  [flagged]
  - Tostino 6mo ago
    What the heck type of software are you shipping that you can just avoid looking at the slop the LLM serves you?
    - georgemcbay 6mo ago
      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.
  - Sardtok 6mo ago
    I don't even see the code. All I see is blonde, brunette, redhead.
- bmc7505 6mo ago
  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-ide https://plugins.jetbrains.com/plugin/22150-noctule-the-swift...
- pjmlp 6mo ago
  Apparently most folks were happy enough with XCode and didn't bother to buy AppCode licenses, hence why JetBrains gave up on it.
hbn 6mo ago
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.
randomNumber7 6mo ago
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.
- tracymiranda 6mo ago
  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-libraries-in-swift/ https://www.swift.org/blog/improving-usability-of-c-librarie...
  - frizlab 6mo ago
    yup, it got much better recently
  - randomNumber7 6mo ago
    These look mostly like toy examples where the type of the pointer can be inferred from the return values of the functions. 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);
    - jumploops 6mo ago
      It's ugly[0] and I haven't checked it deeply for correctness, but you should get the gist (: 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/b8e6cbbce7d24993cdd2fe24258aaf39 https://gist.github.com/jumploops/b8e6cbbce7d24993cdd2fe2425... [1]https://red.anthropic.com/2026/mythos-preview/ https://red.anthropic.com/2026/mythos-preview/
vyr 6mo ago
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
- bartekpacia 6mo ago
  The free Kotlin Multiplatorm plugin provides 1st class Swift support in IntelliJ IDEA. It’s heavily based on old AppCode codebase.
  - pharaohgeek 6mo ago
    As I understand it, though, it's really not well suited to server-side Swift development. Doesn't leverage SPM, requires Xcode, etc. I'd LOVE a revival of AppCode (or Swift support in CLion) that would facilitate server-side Swift development.
jbverschoor 6mo ago
Use swift as a scripting language without the slow start time: Swift Caching Compiler - https://github.com/jrz/tools https://github.com/jrz/tools
- frizlab 6mo ago
  Is “$0” (`argv[0]`) correct when the pre-compiled binary is launched instead of the script?
  - jbverschoor 6mo ago
    Ahh good question. I had to think a while before I understood what you meant. Let me check when I can. 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.
    - philkrylov 6mo ago
      bash, zsh, and ksh93 support `exec -a` especially for this case.
aabhay 6mo ago
We’ve used SweetPad and it worked fine for us, so this doesn’t change much.
inatreecrown2 6mo ago
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.
- frizlab 6mo ago
  Little by little, Xcode is making progress. Probably a lot of the improvements come from the open-source and actual work on its build system… It’s still far from perfect, but at least it’s getting better.
w10-1 6mo ago
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.
- rescripting 6mo ago
  In what way does it fail?
  - w10-1 6mo ago
    Package introspection fails with an error that there are other swiftpm processes running when there aren't in a clean project with no .folders - probably a race with itself. That means no automatic configuration for tests or executables, debugging, etc. Just "build all"
    - rescripting 6mo ago
      Thats... not great. I wonder if its https://github.com/swiftlang/vscode-swift/pull/2174 https://github.com/swiftlang/vscode-swift/pull/2174, which I was running in to sporadically a few weeks ago and was fixed in the latest release.
- inunuftbkj 6mo ago
  > Couple this with Xcode 26.4 AI lacking agentic features A blessing, some might argue.
wiseowise 6mo ago
Everyone should post to open-vsx by default.
eptcyka 6mo ago
But can I develop iOS apps with vim? As in, easy to execute commands for debugging, running app and tests?
- micampe 6mo ago
  If you’re willing to try Neovim I’ve been using xcodebuild.nvim for a couple of years (for macOS not iOS, but they’re both supported). https://github.com/wojciech-kulik/xcodebuild.nvim https://github.com/wojciech-kulik/xcodebuild.nvim
- pjmlp 6mo ago
  Yes, provided you are running vim on macOS, and calling into the xcode command line tooling.
- fingerlocks 6mo ago
  Yes, But an iOS app requires a helluva lot more than just the Swift language. For example, Metal has zero support so you have to use ft=cpp and disable lsp diagnostics. And you can completely forget Xcode’s wonderful Metal debugger entirely. Otherwise swift works just like any other clang/llvm project and the tooling is basically the same.
  - jadar 6mo ago
    Yes but most people are not dropping down to Metal support unless they're doing custom effects or developing a game engine. Most apps could be developed outside of Xcode just fine.
    - fingerlocks 6mo ago
      Sometimes people add to the discussion by sharing esoteric knowledge because the uncommon aberrations are interesting. 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.
mohsen1 6mo ago
I'm building iOS apps without opening Xcode. All in VSCode and CLI build tools. This is excellent!

138 points by frizlab 6mo ago

jgbuddy 6mo ago

This is huge, long time coming. Interested to see if there is SwiftUI support.

nielsbot 6mo ago
What type of support do you mean? Language checking? Live previews?
rockbruno 6mo ago
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 https://github.com/spotify/sourcekit-bazel-bsp
- worldsavior 6mo ago
  You also can't do Android (app) development outside Android Studio.
  - tadfisher 6mo ago
    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?
    - manwe150 6mo ago
      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`).
      - tadfisher 6mo ago
        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. [0]: https://github.com/tadfisher/android-nixpkgs https://github.com/tadfisher/android-nixpkgs
      - daveoc64 6mo ago
        They've always offered a bundle of the command line tools separately to Android Studio: https://developer.android.com/studio#command-line-tools-only https://developer.android.com/studio#command-line-tools-only
  - cyberax 6mo ago
    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 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 https://developer.android.com/tools/sdkmanager
    - manwe150 6mo ago
      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
    - thejazzman 6mo ago
      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
    - Terretta 6mo ago
      On the contrary, commit your code to your GitHub repo, triggering Xcode cloud build to take it from there, build, test, deploy to TestFlight or store. 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.apple.com/xcode-cloud/
      - cyberax 6mo ago
  - Antonito 6mo ago
    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/ 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.
  - c0balt 6mo ago
    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.android-dev-ext https://marketplace.visualstudio.com/items?itemName=adelphes...
  - myko 6mo ago
    what? this is super easy with vim and gradle CLI
- QQ00 6mo ago
  What's the point then? Because nobody use Swift outside of iOS app development.
  - girvo 6mo ago
    > 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.
  - myko 6mo ago
    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
hyzyla 6mo ago
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 https://github.com/SolaWing/xcode-build-server Also I build extra tooling to facilitate iOS development in VSCode https://github.com/sweetpad-dev/sweetpad https://github.com/sweetpad-dev/sweetpad
- sunnybeetroot 6mo ago
  Thanks for your great work on sweetpad. I’ve always been a bit curious where the name came from though.
  - wiseowise 6mo ago
    Sweet=sweeft=swift+pad?
pezgrande 6mo ago
I hate that I need to create an Apple account (with email and phone verification) just to be able download the sdk to use MacOS APIs. To make things worse I tried for like one hour to create an account and couldn't because for some reason I was no receiving the verification email.

rockbruno 6mo 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!

MaysonL 6mo ago

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.

rafram 6mo ago
That is a very specific set of requirements. I doubt it.
mckn1ght 6mo ago
If you could reimplement Emacs in Swift that’d be great

castral 6mo ago

The loss of AppCode from Jetbrains was a huge blow to my motivation to continue working with Swift. Xcode just can't compare.

doctorpangloss 6mo ago
[flagged]
- Tostino 6mo ago
  What the heck type of software are you shipping that you can just avoid looking at the slop the LLM serves you?
  - georgemcbay 6mo ago
    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.
- Sardtok 6mo ago
  I don't even see the code. All I see is blonde, brunette, redhead.
bmc7505 6mo ago
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-ide https://plugins.jetbrains.com/plugin/22150-noctule-the-swift...
pjmlp 6mo ago
Apparently most folks were happy enough with XCode and didn't bother to buy AppCode licenses, hence why JetBrains gave up on it.

hbn 6mo ago

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.

randomNumber7 6mo ago

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.

tracymiranda 6mo ago
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-libraries-in-swift/ https://www.swift.org/blog/improving-usability-of-c-librarie...
- frizlab 6mo ago
  yup, it got much better recently
- randomNumber7 6mo ago
  These look mostly like toy examples where the type of the pointer can be inferred from the return values of the functions. 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);
  - jumploops 6mo ago
    It's ugly[0] and I haven't checked it deeply for correctness, but you should get the gist (: 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/b8e6cbbce7d24993cdd2fe24258aaf39 https://gist.github.com/jumploops/b8e6cbbce7d24993cdd2fe2425... [1]https://red.anthropic.com/2026/mythos-preview/ https://red.anthropic.com/2026/mythos-preview/

vyr 6mo ago

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

bartekpacia 6mo ago
The free Kotlin Multiplatorm plugin provides 1st class Swift support in IntelliJ IDEA. It’s heavily based on old AppCode codebase.
- pharaohgeek 6mo ago
  As I understand it, though, it's really not well suited to server-side Swift development. Doesn't leverage SPM, requires Xcode, etc. I'd LOVE a revival of AppCode (or Swift support in CLion) that would facilitate server-side Swift development.

jbverschoor 6mo ago

Use swift as a scripting language without the slow start time: Swift Caching Compiler - https://github.com/jrz/tools https://github.com/jrz/tools

frizlab 6mo ago
Is “$0” (`argv[0]`) correct when the pre-compiled binary is launched instead of the script?
- jbverschoor 6mo ago
  Ahh good question. I had to think a while before I understood what you meant. Let me check when I can. 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.
  - philkrylov 6mo ago
    bash, zsh, and ksh93 support `exec -a` especially for this case.

aabhay 6mo ago

We’ve used SweetPad and it worked fine for us, so this doesn’t change much.

inatreecrown2 6mo ago

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.

frizlab 6mo ago
Little by little, Xcode is making progress. Probably a lot of the improvements come from the open-source and actual work on its build system… It’s still far from perfect, but at least it’s getting better.

w10-1 6mo ago

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.

rescripting 6mo ago
In what way does it fail?
- w10-1 6mo ago
  Package introspection fails with an error that there are other swiftpm processes running when there aren't in a clean project with no .folders - probably a race with itself. That means no automatic configuration for tests or executables, debugging, etc. Just "build all"
  - rescripting 6mo ago
    Thats... not great. I wonder if its https://github.com/swiftlang/vscode-swift/pull/2174 https://github.com/swiftlang/vscode-swift/pull/2174, which I was running in to sporadically a few weeks ago and was fixed in the latest release.
inunuftbkj 6mo ago
> Couple this with Xcode 26.4 AI lacking agentic features A blessing, some might argue.

wiseowise 6mo ago

Everyone should post to open-vsx by default.

eptcyka 6mo ago

But can I develop iOS apps with vim? As in, easy to execute commands for debugging, running app and tests?

micampe 6mo ago
If you’re willing to try Neovim I’ve been using xcodebuild.nvim for a couple of years (for macOS not iOS, but they’re both supported). https://github.com/wojciech-kulik/xcodebuild.nvim https://github.com/wojciech-kulik/xcodebuild.nvim
pjmlp 6mo ago
Yes, provided you are running vim on macOS, and calling into the xcode command line tooling.
fingerlocks 6mo ago
Yes, But an iOS app requires a helluva lot more than just the Swift language. For example, Metal has zero support so you have to use ft=cpp and disable lsp diagnostics. And you can completely forget Xcode’s wonderful Metal debugger entirely. Otherwise swift works just like any other clang/llvm project and the tooling is basically the same.
- jadar 6mo ago
  Yes but most people are not dropping down to Metal support unless they're doing custom effects or developing a game engine. Most apps could be developed outside of Xcode just fine.
  - fingerlocks 6mo ago
    Sometimes people add to the discussion by sharing esoteric knowledge because the uncommon aberrations are interesting. 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.

mohsen1 6mo ago

I'm building iOS apps without opening Xcode. All in VSCode and CLI build tools. This is excellent!