Comment by mrtksn | Hacker News Reader

Comment by mrtksn | Hacker News Reader

How does the Android Studio compares with Xcode?

On Xcode, it comes with SwiftUI and UIKit libraries for interface building. Does Android Studio comes with a standart UI library? Does it support design tools to help you with building the IU through these libraries or is it code-first?

How straightforward is the environment setup? On Xcode, building your first app is as complicated as creating your first CV on Microsoft Word. i.e, click new, choose a template and build from there or deep dive from scratch if you know what you are doing. Click run and in runs in the simulator, if you put your developer account you can run it on the real iDevice. Pretty hassle-free. Did Android Studio achieve similar level of hassle-free development?

Xcode comes with some asset management tools where you can build libraries of images, colours etc. that will automatically adapt to things like device color theme, language or size(In your code, you refer to a resource in the asset manager and the correct asset is used depending to the parameters you set there). What is the situation with Android Studio?

On Xcode, the default language is Swift and comes with all kind of other libraries that are targeting the latest iOS/MacOS releases. What is the state of art for Android development in therms of the language and OS support? Is everyone building on the native libraries that Google provides using Kotlin?

iDevice simulators run with acceptable performance even on 5 years old Macbook Air. Last time I tried a to run the "hello world" app through Android Studio many years ago on the simulator, the performance was miserable. Is the performance at acceptable levels now?

Thanks!

Android Studio deliver the full experience of android development!:

- Is slow

- It have a slower emulator

- But, not as slow as it UI builder! Being so useless you learn to do things with code instead!

- And also 2 different ways to do gradle builds, now with Kotlin!

- It have gradle, the #1 build manager! (when you do sorted().reversed())

- Is the same experience you have know for years! But with more and more features! That you hope will work for real this time!

It have a nice icon!

And the mysterious gradle/build errors that you keep looking at for hours trying to understand why in the name of mother nature the tool will not tell you what exactly went wrong in 2021 and then finally cluelessly trying different suggestions from clueless people on SO and you’re lucky if one of them works. Then you go home hoping everything works and swearing you’ll fix the gradle dependency nightmare your app has and then letting a helpless sigh that no it’s not your app’s fault.

Honestly, I think the biggest thing google(or who?) could for for android is put gradle in the rear mirror and do(or use? which?) a cargo-like build manager instead...

This is probably a startup idea, btw.

Android Studio is way nicer. It has all the same WYSIWYG features with the added support of a polished Java IDE at its core. There's much less signing, archiving, provisioning madness to deal with and there are no magic "fix this?" buttons that need to be found and pressed.

You can have your own opinions about Android vs iOS dev but IMO the Android Studio is less confusing and frustrating than xcode.

Very YMMV in my experience.

Coming from an iOS codebase that had eschewed XIBs and storyboards entirely in favor of pure code views, I was disappointed to find that it's very difficult to write pure code UIs with Android Framework. Everything is geared toward XML layouts with many things being impossible or impractical to access from Java/Kotlin, which is extremely frustrating.

And in place of code signing troubles, Android brings new challenges with things dependency management and ProGuard silently snipping out big pieces of required code if you don't tell it exactly what to do.

> Everything is geared toward XML layouts with many things being impossible or impractical to access from Java/Kotlin, which is extremely frustrating.

Compose has been available for awhile now and the views are done in code (and is much more functional than SwiftUI - it even gets bug fixes and works on older versions of Android)

> Android brings new challenges with things dependency management and ProGuard silently snipping out big pieces of required code if you don't tell it exactly what to do.

iOS has similar problems, eg mixing SPM with Carthage or Cocoapods, having to strip symbols from fat frameworks, libraries that don't ship xcframeworks or do but don't support the arch you need, bitcode, etc.

Compose is nice, but as noted elsewhere in the comments it's not of much help unless you're starting a new project. It won't be worth it to rewrite existing views for a few more years at minimum.

Re: dependencies, take-up of SwiftPM has been lightning fast and a lot of projects can move to it already. It still has a few rough edges but for my use case it's a massive improvement over Cocoapods/Carthage as is.

We've been integrating Compose into older projects without many issues at all. What have you run into?

Re: SPM - it is a huge improvement! But it has some issues (behaves differently on the CLI vs Xcode, Xcode support is basic and lacks control) and not every dependency has moved to it yet, especially proprietary SDKs. Combining it with Carthage/Cocoapods is a pain - worse than dealing with ProGuard imo.

Again, I think these fall under Android vs iOS and not Android Studio vs Xcode. Although it does get fuzzy when Xcode is the only way to do something in the iOS stack.

> How does the Android Studio compares with Xcode?

Android Studio is a massively better IDE (being based on IntelliJ) with significantly better code inspection, refactoring and linting tooling.

Android itself has a better build system, being based on (kinda) industry standard Gradle which can be more easily automated and plugged into a CI. Doing automation based on Xcode is pure hell. It also has a better dependency management system with scriptable and pluggable components which you can use to improve you build.

Xcode is also seriously behind on testing with seriously buggy and problematic test runners which also love to fail with random code signing dialogs on CI nodes.

Where Android Studio lags behind is in performance (Gradle tends to be a dog) and the emulator (which is still slower than iOS Simulator, but more correct in its functionality). It can also be more buggy (especially when it comes to using tools like profilers) and can lag QoL features (like a good clickety click UI designer).

In general, for larger projects run by companies, Android Studio has been a better experience than Xcode. For pure beginners, Xcode is more friendly until you hit the wall of trying to automate things.

There are lots of different ways to compare these tools, but code navigation and refactoring support is way better in Android Studio than Xcode, IMHO.

(Information somewhat out-of-date, especially on the Android side)

Android's official libraries are often weirdly bad and seemingly incomplete. You'll do a lot of DIY and work-around and looking incredulously at 8-year-old bug reports to which someone submitted a damn patch to fix the bug two years ago, yet they're still sitting open with the last "me too" comment three weeks ago and a bunch of folks begging Google to apply the patch. True story, seen more than once, and you'd be surprised how non-obscure the developer facing functionality has to be when you start running into those.

Once I had to resort to meta programming to change (IIRC) a color of part of a stock Material Design input field, as the implementation had been half-assed by the Android team's interns, is all I can figure. Changing your typeface app-wide used to require (again, IIRC) modifying every single view-related class, or else importing a 3rd-party library (which library existed because obviously that's an insane design). There existed a 3rd party library to shim in the Javascript maps API, because the official Java Google Maps library on Google's own damn OS could only provide an address as one string, not broken up into house number and street and such, while the Javascript one could provide the address elements separately (you can tell where their real priorities are).

Lots of Google's advice about how to handle UI flows or data in one's app is just bad and will make your app brittle while wasting your time, compared to alternatives people who aren't developing the damn thing as their full-time job have come up with.

This was all like 3-4 years ago, not back in the stone ages of 2.x/3.x, or even 4 or 5. 2.x/3.x was a special hell that I wouldn't wish on anyone.

All of the above is relevant to stuff like UI building in Android studio, or your question about whether everyone uses native libs or what have you (you shouldn't, even for basic stuff like HTTP communication, at least as of 3-4 years ago, if you value your time and sanity). If you're not doing something very simple with stock styles, you'll hit some pain, and even then you might. Not insurmountable, obviously, but it's there.

As for AS itself, it's about as heavy as Xcode on system resources. Emulator used to be so slow it was useless, but it's somewhat better now. Still wouldn't develop for Android without an Android device with me 100% of the time, unlike iOS, but they have made big improvements. It probably doesn't crash as much as Xcode. Both are full of arcane bullshit in their interface to keep builds happy, and I actually think Xcode might be a little ahead of AS now that most provisioning difficulties can be auto-fixed. They do have a WYSIWG UI builder but I vaguely recall it being net-harmful last time I tried it, though not completely terrible. Probably useful for some apps. Otherwise it's an IDE and does normal IDE stuff. One "fun" part is that you manage a bunch of Android platform deps through the IDE, separately from AS itself—or you figure out how to do it from the command line while still making the IDE happy, for better repeatability, onboarding, and sanity.

>8-year-old bug reports to which someone submitted a damn patch to fix the bug two years ago, yet they're still sitting open with the last "me too" comment three weeks ago and a bunch of folks begging Google to apply the patch.

This isn't only something developers dealt with, there were user facing bugs like this.

I'm so glad we're finally getting real Linux phones because Android was awfull.

I liked the ones that had been auto-closed then manually re-opened like 5 times because it'd survived that many major versions. Entirely not kidding about more than once seeing that someone had pasted a patch file for like a 1-2 line fix in the bug thread and been begging Google to look at it for years.

[EDIT] To Google's credit, it was possible to write a patch for their OS, unlike iOS. Working against them is the fact that they don't seem to give a damn, so it hardly matters.

This maps pretty closely to my own experiences with android development. So many seemingly basic tasks that would've been a breeze in Cocoa Touch under iOS 6, probably even without third party libraries, are weirdly difficult with modern day Android Framework.

Developing for Android definitely made me a lot more understanding of quirks and brokenness in apps on my personal Android phones (developing for Android and iOS, and so being exposed to many examples of both kinds of devices, ended up converting me to being an iOS user anyway, though)

Reply on news.ycombinator.com