The fact that iOS is successful without a comparable build system (everything is bound to Xcode projects and tooling based on that undocumented changing format), makes me think he's overestimating importance of the build system.
True. Gradle (and its Apache Groovy build DSL) conquered a market by first creating that market. There's really no need for a build system with a procedural build language -- a declarative language to describe a build like with Make and Ant/Maven is good enough.
I don't know, Gradle allowing easy extensions allowed us to do continious delivery significantly easier than with Maven (not to mention iOS build system). It's not a must, but it's a really nice thing to have when you need to build several versions of a build, tag versions dynamically, build docs, etc.
so, they addressed that pain point by using Gradle, which also did dependency management really well (compared to say Ant and, many would argue, Maven) and by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.
Instead someone at Googleplex managed to steer a team to rebuild the world to their favourite IDE and in the process reboot the whole Android development stack, which by the way is still not done.
Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion not been released and to this day there wouldn't be a solution how to use the NDK inside Studio.
I bet Google IO 2018 will again have a talk about how to improve Android build speeds.
Indexing that one cannot turn off unless laptop mode is enabled, spinning the HDD all the time, really?
Also none of our customers IT teams allows InteliJ on their leased hardware/VMs to external partners.
The exception being Android Studio.
Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.
The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.
Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.
Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale.
> Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.
Tools team is certanly aware of it.
> The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.
Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor.
> Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.
Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer.
> Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.
I think you're wrong on this one. A large number of devs care about dev experience at the expense of other important things like platform maturity, reliability, and security.
I don't agree with many of Steve's points in his post, but I do agree on this point. Both factors - x-platform development and instant redeploy - have contributed significantly to React Native's success so far. Indeed, if it weren't so important, I wouldn't expect Google to invest as much time and money as it did in getting Instant Run to work correctly (like others said, it was buggy as all hell when it first landed in Studio's stable channel and only became usable after many months). The fact that Flutter advertises "stateful hot reloading" prominently is just more evidence that it's important for attracting devs.