3 ms·
If Google wants Android apps to have better quality, they need to take a step back and look at their mess of a platform. UI Support? Completely broken. Apple h
by zer0x4d 3y ago
If Google wants Android apps to have better quality, they need to take a step back and look at their mess of a platform.
UI Support? Completely broken. Apple has simple UI frameworks. You either use UIKit or SwiftUI. Very clear which one is being used in which file and the code won't compile if you mess up. No worry about color changes, design mismatch, etc. Everything looks the same and matches. They are compatible and interoperable. Begin with UIKit and you can slowly transition to SwiftUI if you want to. Android? Support library, material 2, material 3, androidx, jetpack compose, AppCompat, etc. I confused myself even trying to look this list up. wtf Google? Code compiles, you run. Either crashes right off the bat which is the lucky case (you are using component from material 3 but view theme is not a descendant of a material 3 theme), or if you're unlucky and it runs, half things are one design and color, the rest don't match? Why? Oh you forgot this one view uses a theme that is descendant of a different library. Off you go hunting down the style that component uses in 30 xml files (which btw, for some reason, are broken down based on dpi and api version too??) Good luck with that. 2 hours later you narrow it down, fix it, sigh of relief, then bam, it hits you back just like a window blind. The color matches but the button now looks different. Hmmm
Build system? Somehow this is even more broken than the ui support. Open project that used to build fine 1 month ago, hit build, it fails. Hmm what's wrong? Oh there is a gradle version mismatch between what the IDE has and what the project has downloaded in the main folder (wtf x2! Why is a binary for the build system living in the project source in the first place???) Shouldn't the android development tools included in the IDE already contain the last and best version of the build system that is backwards compatible? Imagine if Xcode asked you to download and store xcodebuild in the project source. It's ok. Update to new gradle version, hit build, it fails again. what now?? Oh the version for `com.android.tools.build:gradle` doesn't match! Weird, shouldn't android studio just be able to download and use the appropriate version of the android gradle plugin based on the gradle version you have specified (uhum I mean the one Android Studio itself should have included and you should never have to specify manually or download or store in your project source???) Oh and how could I forget our wonderful friend, the multidex! See, our build tools aren't even smart enough to be able to tell when your project needs to multi dex. It just errors out and you have to manually go ahead and enable it and include the library. To their credit, newer versions seem to have fixed this but this shouldn't have ever been even left to the developer.
Dependencies? This one isn't even debatable. It's yet another fragmented mess. Xcode dependency management is very simple. You either use their provided SwiftPM or you can use Cocoapods. Or both. They work well together. With android? Oh, Google does not want to commit a small storage/bandwidth from their massive capability to delivering good dependency hosting to developers. You pull the code from repo, dependencies can't be fetched! Wtf? Teammate swears it builds fine on their side (huh doesn't it always??). You check what's wrong! Oh Bintray/JCenter decided to shut down forever! Bye bye. They left and left you the generous parting gift of 10 unresolvable dependencies! You got hunting down the Github rabbit hole, issues galore. Everyone's freaking out. Project maintainer has left and hasn't pushed code to other dependency repos. You think: Good, the code is on Github, I should be able to just use the GitHub url directly in the dependencies instead, right? NO! Wrong!!! Things can't be that simple with android! You realize gradle dependency management doesn't allow you to just pull that code and use it unlike SwiftPM and Cocoapods. You are now at the mercy of yet another third party website (jitpack.io) to act as middle man between Github and gradle. This website shuts down any second and you are back to square one! Why god?? Why can't I just pull the god forsaken code and build it locally myself!? Did I mention that besides jitpack.io there's also maven central? What happens if that shuts down? No one knows!
I'm not even going to talk about the mess that is/was app signing and release, billing sdk updates, target sdk version deprecation, etc.
Fix your broken ecosystem first before blaming the developers! Why do the android apps for even bigger players like Tinder, Bumble, and Hinge have significantly lower rating than their iOS counterpart? They surely do test properly and can afford proper development. This just goes to show there is something really wrong with the android ecosystem and Google needs to look inwards to figure out how to get it out of the state its in right now.
- fidotron 3y agoThe funny thing is Android Studio itself is now much more usable than XCode but as you say it is everything you are doing in it that is maddening. What kills me about Android is the extent to which the official best practices have always been out of touch with reality and somehow get more so every time they add something new. The indoctrination in the Android dev community is so strong most people cannot separate the few core good bits of the platform from the layers of utter nonsense on top because they only know the nonsense.
- webworker 3y agoI have all of these problems, and more (since I inherited a react native app). I DREAD having up do framework updates. Maintaining this app for iOS is HALF the work that Android is, we have a lot less Android users, and in general it seems like iOS users are just a better audience. It really feels like there's no point to doing an Android app, just give those users a website, PWA if they're lucky. And with this change? Pfffff. And I agree - it does all descend from Google's horrible tooling and ecosystem.