I work on full-stack product, with iOS/Android SDK element that other people integrate in their apps. Server-side with UNIX boxes: everything works always. Xco

I work on full-stack product, with iOS/Android SDK element that other people integrate in their apps. Server-side with UNIX boxes: everything works always. Xcode/iOS: we published CocoaPods. It was pain to get to work reliably on laptops/Jenkins b/c of upgrades to Ruby, but if you lock yourself to one Ruby version, and lock the Gemfile, it's mostly OK. At least it's pretty obvious when/why it doesn't work. Gradle: it's such a mess. I don't even know where to start. I don't know Maven, but Gradle error warnings are the worst. 4 lines, tells you nothing, with turned on debugging the output tells you nothing, while e.g.: in reality you don't have the child-repo checked out because you forgot to `git submodule update --init`. Getting Gradle to work on a laptops across the team of 4 was a pain. We had cases where two people with the same AS version and the same gradle version couldn't import the project into AS. Our instructions are - after 'git pull' make sure you do 'git clean -dfx' and re-import the project. Personally 50% of time when I start Android Studio I have some critical exception of some sort, each time from Gradle window. There's this, plus gradle wrapper. I pretty much never worked for me. This is meant to solve problems with always getting you the right Gradle version, but this is sci-fi. I believed it's just me who uses SDKMan to be able to fetch the right gradle which our project depends on, but others around do too. Otherwise it's a pain in the ass -- and `brew` doesn't have the gradle's we need, because they migrated to the very latest one, when in production you'd rather have older version for an extended period of support time. If you, just like us, have a project which has 3+ years of scar tissue and it has to integrate with javanet, picasso, okhttp, volley etc. and you have several people who fetch and integrate your code in their apps--I feel really, really sorry for you. DSL is all right, and maybe Groovy has some unique features, but I never discovered them. This is Java language that isn't Java, or some dialect of Java-like language aimed to make Java 3% better, but to be honest I don't hear people writing Groovy for fun and pleasure. So to me it was a cost of learning basic stuff just to be able to automate simple stuff in Android build system (when we run ./jenkins.sh --local, we want our Android functional tests to hit local dev environment). Of course in XCode it works 100% better and took 20% of time to do, since Apple owns XCode and made it look better: go to project settings, drop in the path to post/pre built scripts to customize your flow, and in a language you already know. Google, who subleases Android Studio from JetBrains, had no choice and made Android ecosystem look like a Frankenstein.