Before Swift/Kotlin our iOS team was way more productive than android. Everything was done in half the time.
They both switched to new languages.
Now it has flipped. Android does things in half the time the other team needs.
They both switched to new languages.
Now it has flipped. Android does things in half the time the other team needs.
Kotlin does a better job of getting out of the way when you need it to (compared to Swift), and Jetpack Compose is the real game-changer in terms of productivity.
That being said, there's a lot that you 'get for free' in iOS' frameworks, and APIs are generally more interoperable / batteries included. Both of these factors are what ultimately speed up iOS development.
To add to this: when looking for third party libraries (Swift/Objective-C or Kotlin/Android Java), aside from those from large organizations (Square, Airbnb, etc.), I've found the selection and quality of those available for iOS to be better, on average.
Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.
It's zero-boilerplate (IE, don't need to manually write bindings like most tools) bindings from C++ code for both Swift/ObjC and Java. The idea being you can write C++ code and then consume it on both mobile platforms, making your life easier.
https://github.com/scapix-com/scapix
https://github.com/scapix-com/scapix#java-link
I've had a scenario where another app handed me the pointer to a window to render to, and so the only way to use it from JVM was to write some bridge code. Where C++ started the JVM & invoked my Java app's entrypoint, sending over the window pointer, and then from there I could render/paint into the window.
I’ve always wondered why Google didn’t make something like this themselves. I assume the answer is that they just don’t care about native code, or at least native/Java interoperability.
But yes, not even caring about a better JNI tooling story is a big pain, specially given Android Java, they surely could have come up with a better FFI story.
But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it.
Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it.
I hope the swift team does some hard thinking and start slashing features and make it Simpler. What we got is something more complex than even Java. This is the same reason that Scala didn't take off (even though some people like it).
You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which is pretty easy. But in an imaginary world where we got ObjectiveSwift instead, SwiftUI could have existed there and given the same productivity benefits.
Binary sizes ballooned because of the language. Binaries were significantly smaller in equivalent Obj-C programs than the swift ones, even when the standard swift library was finally baked into the OS.
I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.
Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity.
Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases.
In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.
> Last time I checked the inflection point starts around 100k lines of code.
What! Of course it does. If it doesn’t impact coding at all, what is it for?
Unless we have well researched data, it is just a opinion.
My opinion and experience is definitely different than yours, and I have seen that objective c leads to more productive teams if they are mostly senior people. (With a couple of libraries (just some helper categories on strings and arrays) and some sparse macros objective c becomes a very productive language. But it takes a senior team to do that well).
Meanwhile with swift you feel you have to please the compiler at every! step? And it really doesn’t lead to much safer language anyway (swift bugs are different) and you feel you have to fight the compiler in every way.
Objective c is less fuzzy, and while it lets you do dumb/fast things (especially important during prototyping) it gives you a clear ‘you are doing x wrong’ warning which gives you the best of both worlds
Fast prototyping when you need it, and safety when you need to ship (you can have a production build fail on just warnings)
And if you're doing nullability, you might as well add ADT enums, since that is usually how it's implemented.
When you mention more sophisticated solutions using Swift, I am not sure what capabilities Obj-C lacks that would hamper it. Are you referring to the functional parts of the Swift language? Combine?
Just observe how much the iOS community talks about Swift patterns. Objective-C was more like Go, in that you accept your fate, keep things simple, and write some boilerplate code here and there. It seems to drive some people crazy, but it also avoids C++-style meta discussions about language features.
Whether this trade-off increases or decreases productivity depends on your team.
Both teams move faster in the new languages, but the Android team moves more faster.
String( Int("ff", radix: 16), radix: 10)I have also written commercial code that does this, and I'm just going to paste it here because it's actually not that much code. Sums two strings of arbitrary length, well outside of the overflow limit, for the given base. Returns the sum as string in the base given. No mapping or overflow checks needed. Invalid characters for the base are treated as 0, but you can easily modify it to throw an error or whatever.
func sumStrings(_ left: String, _ right: String, _ radix: Int) -> String {
var left = Array(left)
var right = Array(right)
var carry = 0
var result: String = ""
while left.isEmpty == false || right.isEmpty == false {
let charLeft = left.popLast() ?? "0"
let charRight = right.popLast() ?? "0"
let intLeft = Int("\(charLeft)", radix: radix) ?? 0
let intRight = Int("\(charRight)", radix: radix) ?? 0
carry += (intLeft + intRight)
result = String(carry % radix, radix: radix, uppercase: false) + result
carry /= radix
}
if carry % radix != 0 {
result = String(carry % radix, radix: radix, uppercase: false) + result
}
return result
}For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.
Swift compilation is an order of magnitude too slow, especially in incremental built, compared to objc.
* Android studio is reliable and just works.
* Kotlin is simple, easy to learn and productive.
* xcode is buggy and with their rapid pace of development it is just getting worse.
* Swift is complex. They had to rethink and redesign multiple times. Also the language was constantly changing under them.
How I wish this would be true.
There is a reason why so many rather use InteliJ with Android plugins, or even drop into VSCode with Gradle instead, only starting Studio for workflows that have to be done inside it.
There is hardly a "stable" release without regressions.