3 ms·

Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise custome

Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. 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.

pjmlp 9y ago
And you haven't addressed the NDK, which is like life in the trenches of build systems.
izacus 9y ago
> Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. 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.
- vickychijwani 9y ago
  > Instant redeploy is very nice but hardly a huge deciding factor. 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.

pjmlp 9y ago

And you haven't addressed the NDK, which is like life in the trenches of build systems.

izacus 9y ago

> Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated. 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.

vickychijwani 9y ago
> Instant redeploy is very nice but hardly a huge deciding factor. 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.