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 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.
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.
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.
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.
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
No, you can't. You'll need to hit "xcodebuild" somewhere in the chain. It's just that you can offload it to someone else (e.g. EAS Build) or use pre-built apps that only need JS/LUA/Python code package swapped.
> 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.
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!
Problems that require deep knowledge of multiple repositories, e.g. when trying to debug issues involving dependencies. The models get confused very fast even with all code available locally, due to the size of the problem. But in my experience any kind of deep integration already messes up the models, even within a single repo.
Oh yeah I forgot to mention that, it was the first option I considered but getting it shipped to Sweden was super expensive. So it didn't make sense considering I just wanted the camera dump feature. Buying the pcb and port on the other hand only costed me about 10 bucks since I already had an Arduino laying around, and also served as some necessary soldering practice :)
When the AI companies run out of money, I predict tokens will stop being dirt cheap and such setups will become extremely expensive (even for regular software engineering to some extent). Then it's become clear how over-engineered most things we do with AI are
In parallel, local models are getting better and better, so eventually they’ll get “good enough” to run fairly cheaply at a level close to the current Sonnet/Opus models (what I run Claudeclaw with), on Groq, Openrouter or whatever commodity provider. Perhaps even mid to high end consumer PCs when the current RAM madness subsides.
There’s loads of good discussions about local LLMs in this thread:
That can't be allowed, and also won't happen. If token costs do start going up at a serious rate in the US, you can be sure that they'll stay down in China, and the political situation won't allow for the inevitable exodus to Chinese providers.
While true, my personal fear is that the higher-ups will overlook this fact and just assume that AI can do everything because of some cherry-pick simple examples, leading to one of those situations where a bunch of people get fired for no reason and then re-hired again after some time.
Exactly, now which one do you wanna be? The burned out ones but still working in SWE or the fired ones which in the long run converge to manual labor which AI can't do.
Not to mention in SWE case the salaries would be pushed down to match cost of AI doing it.
If you fail as a "higher up" you're no longer higher up. Then someone else can take your place. To the extent this does not naturally happen is evidence of petty or major corruptions within the system.
In competitive industries, bad firms will fail. Some industries are not competitive though. I have a friend that went a little crazy working as a PM at a large health insurance firm.
I think the "well defined prompt" is precisely what the person you responded to is alluring to. They are saying they don't get worried because AI doesn't get the job done without someone behind it that knows exactly what to prompt.
reply