[HN Gopher] Expanding Swift's IDE Support
___________________________________________________________________
Expanding Swift's IDE Support
Author : frizlab
Score : 59 points
Date : 2026-04-08 19:21 UTC (3 hours ago)
(HTM) web link (swift.org)
(TXT) w3m dump (swift.org)
| jgbuddy wrote:
| This is huge, long time coming. Interested to see if there is
| SwiftUI support.
| nielsbot wrote:
| What type of support do you mean? Language checking? Live
| previews?
| rockbruno wrote:
| 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
| worldsavior wrote:
| You also can't do Android (app) development outside Android
| Studio.
| tadfisher wrote:
| 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 wrote:
| 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 wrote:
| 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
| daveoc64 wrote:
| They've always offered a bundle of the command line tools
| separately to Android Studio:
|
| https://developer.android.com/studio#command-line-tools-
| only
| cyberax wrote:
| 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
| manwe150 wrote:
| 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
| Antonito wrote:
| 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.
| QQ00 wrote:
| What's the point then? Because nobody use Swift outside of
| iOS app development.
| girvo wrote:
| > 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.
| hyzyla wrote:
| 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
| sunnybeetroot wrote:
| Thanks for your great work on sweetpad. I've always been a
| bit curious where the name came from though.
| rockbruno wrote:
| 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 wrote:
| Is there an open--source Swift IDE that can modify itself without
| restarting? (written in Swift) I loved Oberon uSystems Oberon/F
| aka Component Pascal for that capability.
|
| Or am I going to have to vibe-code one.
| rafram wrote:
| That is a _very_ specific set of requirements. I doubt it.
| mckn1ght wrote:
| If you could reimplement Emacs in Swift that'd be great
| castral wrote:
| The loss of AppCode from Jetbrains was a huge blow to my
| motivation to continue working with Swift. Xcode just can't
| compare.
| doctorpangloss wrote:
| on the other hand, when many of the best programmers haven't
| looked at a line of code in months, will it matter?
| Tostino wrote:
| What the heck type of software are you shipping that you can
| just avoid looking at the slop the LLM serves you?
| georgemcbay wrote:
| 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 wrote:
| I don't even see the code. All I see is blonde, brunette,
| redhead.
| hbn wrote:
| 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 wrote:
| 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 wrote:
| 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...
| frizlab wrote:
| yup, it got much better recently
| jumploops wrote:
| 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.
| MattDamonSpace wrote:
| 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
| vyr wrote:
| 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
| jbverschoor wrote:
| Use swift as a scripting language without the slow start time:
|
| Swift Caching Compiler - https://github.com/jrz/tools
___________________________________________________________________
(page generated 2026-04-08 23:00 UTC)