Why is Android Development so difficult/complex? (compared to Web and Desktop)

I don't know the why and I mostly code for it in C++ with a thin layer of Kotlin (used to be Java) around it because some things are easier to do there in the API. I guess if I started today I would have a hard time picking up but since it's been 8 years now the knowledge has compounded and I don't know exactly how to tell you. I think it's in the same sense that I have hard time to explain Magic The Gathering for someone when I have been playing it (with a few stops and comebacks) since 1995, it's so many cards, mechanics and history that I don't know exactly how to start someone and keep them interested.

I would suggest trying to do something small like a pomodoro app and then think on things you want for yourself - some people have fun with home automation, some people want the perfect note taking app, find something you want for yourself and try to go slow through the docs and tutorials to implement it. Android Studio is pretty great once you get the hang of it.

It's probably like that because there is so much internal Google churn and product development year after year, and a thousand cooks in the kitchen.

Old-school stuff like WinForms just seemed like a calmer scene with not so much going on.

Android seems about the same to me as desktop Windows/Mac development in all of those regards.

* Married to the vendor's IDE: You technically can build without Android Studio, Visual Studio, or Xcode, and it's educational to learn how to build apps without the IDE, so you can debug tricky compilation issues, but for day-to-day development, you've pretty much just got to use the vendor's IDE. `gcc hello.c` will not get you a running Windows Forms app, a running AppKit app, or a running Android APK. (`javac Hello.java` won't even get you an `.exe` file!)

* Complex proprietary tool chains: The vendors' build tool chains do a lot of tricky work, including link-time optimization, obfuscation/minification, and app signing/notarization. You technically can ship an app without LTO and without a signature/notarization, but good luck getting ordinary users to install it.

* Crufty legacy APIs: Windows and Android have a lot of those. Mac has marginally fewer of them, but that's because Apple is more willing to break backwards compatibility, which is its own kind of hassle. It requires a lot of domain expertise not to accidentally use a bad legacy API on desktop, and Android.

* Spotty documentation: All the vendors have spotty documentation. Some parts have excellent documentation, some parts are nearly undocumented, and some parts have outdated/misleading documentation. All of the platforms are popular enough that third parties have written a lot of great blog posts, videos, books, classes, etc. (As a professional software developer, your company should offer an education budget so you can pay for good educational materials.)

Because desktops, even modern commercial one, are still kind-of open platform, mobile are their OEM game, devs are uncomfortable guests there.

If you are a very large firm you have to accept the OEM bureaucratic terms, if you are a small one you are a bad guest because people must only consume and being fully dependent on the vendor, if programming is ease too many will try and sooner or later FLOSS start to spread and sooner or later people will decide it's time to ditch costly subscriptions to do things alone, knowing it's perfectly possible...

The entire modern IT development head in this direction, trying to subtract all power to all users, no matter if "end users" or "intermediate programmers".

Context: I developed Android professionally apps at Google & FB from 2010-2021/ and as a hobby dev during that time.

I personally blame gradle for the complexity. It's such a horrible system for builds, and when I was developing Android apps on my own, I would avoid it at all costs. Using buck/bazel/blaze resulted in a much cleaner build process. It's been a while since I've wrote Android apps, but I've included a minimalist BUCK build file with Java + C++ components below. Note how it just has two build rules for the Java and cpp code. And it only requires 5 for a minimal Java/cpp app. If it was a pure Java app, it would just require the one build rule alone with a .java file and an AndroidManifest.xml.

At the same time, I needed to maintain a public facing SDK so I needed to learn gradle which was an absolute nightmare. I spent way too much time reading docs on the build system compared to doing something useful with it.

I'm not sure what the current state of the ecosystem is with Kotlin and modern Android Studio, but if I had to develop Android apps on my own again, I would start with bazel or buck for anything that's more than a Hello World template. I would recommend the same for anyone just starting out with Android development who is familiar with CLI-based development. One useful learning experience was to unzip an APK and figure out the individual build steps that converted a set of source files into the final APK. With bazel/buck, you can give it an option that causes it to print every build step which involves the build system calling Android SDK build tools on source files. Then you can manually run this commands yourself to see what they do. Doing this will tremendously help you debug any build issues and teach you how to remove bloated items from your build process.

https://medium.com/androiddevnotes/the-internals-of-android-... is a good starting point. In particular, read the section about "Understanding each part of the process" until you understand exactly what each box in that diagram represents.

    android_binary(
        name = "one",
        srcs = ["TestOneActivity.java"],
        custom_package = "me.sxp.test.one",
        manifest = "AndroidManifest.xml",
        deps = [":libone"],
    )

    cc_library(
        name = "libone",
        srcs = [
            "jni.cpp",
            "testonelib.cpp",
            "testonelib.h",
        ],
    )