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.
https://developer.android.com/studio#command-line-tools-only
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
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/
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.
Also I build extra tooling to facilitate iOS development in VSCode https://github.com/sweetpad-dev/sweetpad
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.
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.
“You’re looking at a multi-week refactor” aaaaand it’s done
Otherwise swift works just like any other clang/llvm project and the tooling is basically the same.
Swift Caching Compiler - https://github.com/jrz/tools
Or am I going to have to vibe-code one.
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.
[1]: https://plugins.jetbrains.com/plugin/22150-noctule-the-swift...
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.