Your first impression is correct. There is a LOT to know and I am still learning new bits every day. And yes you do find most of it out by digging around in the docs or on StackOverflow.
That said, it's an amazing platform to explore because no door is fully closed. Android will let you do practically anything if the user wants you to. That leads to a really gratifying hacking experience where if you just keep digging you can achieve really fun and crazy things that you'd never be able to do on any other platform while working with mostly high-level APIs. It has its own strange logic that I have grown to love.
Apple may be closed down, but I've never had to target anything less than current_version-1.
Other things like the way events are handled and some of the native widgets are clunky. Some of us are fed up enough with all the incidental complexity Apple puts in your way every day as a developer (provisioning, in particular), that we prefer to put up with Android's warts.
That said the native app market is feeling pretty saturated these days and I'm not sure that boning up on building responsive/progressive web apps isn't a better long term bet.
As somebody currently learning the basics of iOS development, what do people use as an alternative?
Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html
That guide has such gems as:
"Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone."
"While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)"
"Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API."
etc.
And the audio subsystem is still really bad, lots of lag which prevents android having any serious sound / music app... if you dig the forums you will find lots of really upset people complaining and willing to help improve the sound subsystem and the Android team just keep ignoring... Just to give you an example, my raspberry pi gives me 3ms of sound latency while my current flagship Android phone with Android 6.0 gives me 100ms, totally unaceptable for music related apps :(
In terms of Android Studio I use it, but I find the interface really bloated which interferes with my desktop zen. I tweaked but still dont like it, somehow i miss my tuned Eclipse of some years ago. Biggest thing since the transition to Android Studio is Gradle which I find it really good.
I just wish Android was a truly open ecosystem where we developers have more voice than asking for help in stackoverflow and using a limited set of tools. Web development might be chaotic, sometimes feeling overcomplicated but Im truly amazed and thankful by the quality, quantity and variety of tools that the comunity produces. It just feel fresh and you can do it the way you want, from a simple html and css in a single file with a notepad to the most advanced framework with linters everywhere.
If you've never done native mobile app development (e.g. you only have background in web dev), then regardless which platform you start off with, the initial learning curve will be a bit steep. Most APIs are "lower level" than the web counterparts and there's more ceremony to piece things together since you're working in such a constrained environment (memory, CPU, battery, network speeds, inconsistent internet access, disk space).
All that said, I think Android is a _taaaad_ easier to start off with vs iOS if you're a web dev. There's the GC, the Activity model is similar to web pages and their View XML abstraction is not that far off from HTML/CSS.
-----
> .. View XML abstraction is not that far off from HTML/CSS.
Do you mean the underlying structure of xibs and storyboards? I don't think this is something anyone looks at willingly, much less actually work with.
The API is not really complex if you know a few basics (services/ activities/ broadcastasts/ lifecycle/ intents/ handlers/ ui/ ui thread/data storage) and then just know where to look for the answers(the android docs and tutorials are good and there's an answer to everything in SO).
Also you need to have a solid understanding of Java or you'll definitely have problems. So my proposal is to grok the (few) needed basics and the just go all-in and try to implement a full application so that you'll get the needed friction with the android environment.
Theres a reason android developer avg salary is higher then iOS ;)
The API is almost the same, sure. But things like class attributes, null-coalescing, lack of Gradle, automatically generated getters and setters which can be overloaded... I had more fun writing a personal app for fun in Xamarin than I ever did in Android Studio, which only ever frustrated me, even though I love the IDE it is based upon.
What's nice is that most of the regular Android tutorials/SO answers are easily translatable to Xamarin Android.
I have found myself just leaving the word Xamarin when I google something, as the ordinary Android resources are good enough.
It looked like it's just a middle ground that does neither as good as the native solutions. Was hoping MS will accelerate it to be more competitive.
> And does anyone know if it gets better with time or is it a constant struggle?
I'm not super experienced, but I did invest quite a bit of time a few years ago and never got to the point where it was getting any better.
I almost feel like I should just go completely Android given the numbers of devices out there is overwhelming compared with Windows/iOS/OS X combined. I will keep up with my other PLs and things simply through osmosis. It's time to join the Borg!
It does a really good job at fixing java's issues and since it outputs bytecode, you can write entire Android apps with it without writing a single line of java.
As I wrote downstream, I just need to commit to Java (or Kotlin!) I think!
Trying to write an app that isn't a game will make you enjoy the pleasures of JNI calls, given the APIs exposed to the NDK.
Syntax is a subjective thing; I just don't like Java. I was hoping Google was going to come up with something (other than Go), for Android.
I have tried a lot of the work arounds, and simply put, Java is the way to do Android right, so I guess I need to get over it!
The NDK is pervasively used by many many applications; that's why it's getting more support.
For some reason this seems unpopular with the android team, who seem to keep trying to avoid the issue when ever its raised at I/O...but hey, clearly at least someone is paying attention to what the statistics are showing.
Sure, it's some extra hoops to jump though; but shared business logic that you can use on any code base on any platform; that's a really really compelling reason to use the NDK, or one of the stacks based on it (eg. Xamarin, react native).
It's not just for some edge case. The biggest players in the field are doing this.
I think it's misrepresentative to try to characterize this as 'just for games'...
Edit: Looks like it's not longer free.
Haven't had to use Genymotion since 2.0. Instant run is getting better w every release, I surprised the iOS dev last time I showed it to him.
https://developer.android.com/studio/projects/add-native-cod...
Like cmake or not, this is a really really great change for the whole workflow of using native plugins.
Also be ware that at least during the beta period, the CMake build files had better support than Android.mk ones.
At work my desktop can handle it, but that thing has pretty unrealistic specs.
This can easily eat a bunch of ram, making the OS swap. Seems OS X has extra bad policy of swapping.
That's an extreme case though, most projects can be worked on with reasonable machines. An SSD really helps though