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

I wrote apps for Android when I first got a smartphone, circa 2011, and it was so easy. There was a bit of doc to read to understand activities and intents but that was basically it. At that point you could write an app without running into new surprises.

I tried again to write a tiny Android app last year and couldn't figure it out. There's so many moving parts with SDKs, API levels, support libraries, contexts, fragments, Gradle, ... And the documentation is built similarly, bolting on new chapters when new concepts are introduced, making a whole that is useless and inscrutable.

It's really a shame. Is there a better starting point that could get someone ready to write a simple app in 2024? Some document that would introduce some reasonable workflow from A to Z (whether SDK, React Native, Kotlin, or whatever is simple)?

I'm sure some web-to-native workflows are documented just by popular demand. Like this React Native + Expo review posted recently: https://expo.dev/blog/from-web-to-native-with-react-native-a...

But for an absolutely minimal native example, I followed this guide: https://czak.pl/2016/01/13/minimal-android-project.html with a few adjustments and got an app to compile.

Qt makes Android development really simple.

if you don't mind iOS swift(ui) is the most beautiful software framework I've ever used

I really doubt that, but I'll bite. Why?

Not the OP but at least for me, freedom (open source) comes before elegance and android scores there as do linux distros. Hence, I've never bothered to look at the i-ecosystem at all.

I don't disagree, plus people in this thread have bashed iOS just as much. Still I'm giving GP the benefit of the doubt, might not be purely irrelevant fanboying...?

I can't theorize on the 'Why' part of your question, but there are ways around using Android Studio IDE to make Android builds without gradle build system.

If you want to learn exactly how the APK/AAB is built and compiled, here are some resources I used to learn:

- https://stackoverflow.com/questions/59504840/create-jni-ndk-...

- https://stackoverflow.com/questions/69566622/android-build-w...

- https://github.com/HemanthJabalpuri/AndroidExplorer/blob/mas...

- https://developer.android.com/tools

Some of the links haven't aged too well, but it's a starting point for learning how things work under the "Android Studio" / "gradle" hood.

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",
        ],
    )

Couldn’t agree less. I’ve been a developer for nearly 20 years, working with Python, PHP, JavaScript, ObjC, Swift, Java, bash scripting, SQL, Terraform, and a bunch of others. Written code for data transformations, web servers, client side JS apps, native mobile apps, and games.

Android has been my favourite platform to work with and has offered the best developer experience I’ve found. It’s not particularly close. The SDK has improved significantly over the years, the IDE is wonderful, the feedback loops are short, Kotlin hits the sweet spot between functional and OO code, and Compose is a joy. Although yes, Gradle is a sore spot.

IMO the reason why Google have gone all-in on Android Studio is because it’s really, really good. Compare it to Xcode. If you’ve never used a JetBrains IDE, it can feel a little unfamiliar, but I’ve never felt as productive in any other programming environment.

can it do vim shortcuts? its soo hard without vim

Intellij, which Android IDE is base on, as well as other Jetbrains' editors I'm assuming, all support a Vim plugin. https://www.jetbrains.com/help/idea/using-product-as-the-vim...

It was decent enough when I used an Jetbrains editors a few years back, at least for 80-90% of normal/insert mode vanilla vim editing behavior.

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

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.

Instead of using the barebones Android SDK you might want to experiment around a bit with Kotlin.

https://kotlinlang.org/

Note that Google is using Kotlin internally themselves for writing Android apps because reasons.

If you want to have a great multiplatform development experience based on Kotlin, add Kotlin Multiplatform (https://www.jetbrains.com/kotlin-multiplatform/) and you are all set.

I think its a combination of:

* Android having made lots of compromises to get Java running on resource constrained devices, leading to things like manually saving state in Bundles, Parcelables, SavedStataHandle, etc in combination with Component Lifecycles. These deep seated things remain.

* Lots and lots of undocumented behavior, poor documentation, etc. The Javadoc is in disrepair for many APIs, being just skeleton but not mentioning semantics, arguments, return values in all scenarios etc.

* Lots of API churn, stuff being deprecated constantly. You may need lots of compatibility paths.

* Just straight out bad ideas like Content Providers, which are still used in various APIs like DownloadManager (getting status, etc).

* Still have plenty of fragmentation and behavior differences (Samsung devices, etc)

* Google Policies continue to become more onerous. Seems like more of my effort goes towards administration than actually building. I suspect this is intentional, so only larger teams can get their stuff in Play Store.

* Mobile development in general is still kinda like shipping software on CDs, there is some delay for approvals, and some people won't get your update for a bug fix etc

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.

Only 2 equally contributing reasons:

1. UI is inherently a very complex problem, because of the state. Most of the so called web apps are thin clients with most of the state machine delegated and spread over backend services.

2. Android platform was shitty designed to begin with. Terrible architecture, ugly UX, frustrating docs etc.

Strongly disagree. As a dev who’s been in the business since the days of the first gui apps and OSes, UI can be very straightforward, but we have designed modern systems such that they are immensely complex.

Styles and inheritance and asynchronicity have turned what could be a simple approach into an inscrutable problem.

Aren’t you one of developers of android?

That would explain a lot :)

Very dangerous wishful thinking.

Ui can only be as straightforward as a user wants it to be - if all user wants is pressing couple buttons to open couple windows - then yes, it is straightforward.

Asynchronicity is not a problem it is one of the many solutions to help alleviate the problem.

Gradle is a very strange build system.. it actively downloads things if you are missing things, but then still will only work if you have the right combination of things on your system (on linux at least), and fails in cryptic ways. Not sure I know anybody actively likes Gradle and that entire build system -- there was something previously like ant something, etc.. if you have an older project good luck having it actually build even when trying to use Android Studio.. it seems to only work if you actively use Android Studio quite often and slowly adapt to each random change to keep your project working properly.

Take a look at https://dotnet.microsoft.com/en-us/apps/mobile. It will allow you to write Android apps in C# in Visual Studio.

Not going to lie their example apps look terrible. I would have been significantly more impressed if they released a functional first party Microsoft app with their own tools.

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

I wonder if this is also one of the reasons why Android apps are usually worse than their ios counterparts.

iOS development is honestly the worse.

It got a bit better with Swift instead of ObjectiveC but you still have to deal with XCode and a stupid process to sign and publish your apps.

The signing process might be whacky but the actual swift and swift ui is quite pleasant to use.