(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

(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.