> sbt-android doesn't allow you to use Android Studio, which is also a huge handicap. Some of our team uses Intellij, some use Android Studio to do Android dev

> sbt-android doesn't allow you to use Android Studio, which is also a huge handicap. Some of our team uses Intellij, some use Android Studio to do Android dev. Both work fine with sbt-android. > You can use the same libraries, the same build system, the same IDE. This is true of Scala as well. Granted the gradle scala plugin is not great (though it does seem much better than when I last looked at it). sbt-android-gradle lets you use gradle and sbt side by side for android apps. For a while my team used this. > The sbt-android plugin mentioned may work, but will never have the feature set of Gradle integration. I'm curious if you know of any of these features sbt-android is currently misisng. I believe some of the new Android O font stuff might not work yet. Instant Run might be the next thing to be mentioned but it's replaced really well by sbt-android-protify. > Scala 2.12 requires Java 8, and support for Java 8 bytecode has only been introduced in O This is (imo) the worst part about all of this. Even Android O isn't the full java 8 bytecode so scala 2.12 still doesn't work. > all of this is why Android developers love Kotlin Yeah, I think Kotlin is a godsend for Android. One thing I don't think I mentioned in my original post was that Scala benefits from Google's kotlin support as well. It means many tools google produces (new arch components come to mind) operate on bytecode instead of source. So they (more or less) automatically work for scala too. Certainly kotlin was thought of from the ground up as an Android language and it shows. You also mention method counts a few times. I admit this is somewhat of a problem but it's also worth pointing out that sbt-android runs proguard automatically for you during release builds. We haven't come close to 65k (with or without proguard) and 70% of our method count comes from android support libraries published by google not the standard library methods provided by scala. We also target api 21 so multi-dex is not really the headache for us that it used to be.