4 ms·

I've found similar results, although at the end of the day, iOS development is still faster overall. Kotlin does a better job of getting out of the way when yo

I've found similar results, although at the end of the day, iOS development is still faster overall. 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.

kitsunesoba 5y ago
I haven't had a chance to use Jetpack Compose yet but this roughly tracks with my experience. Needing to hunt down third-party libs for everything slows development down considerably and makes for complications down the road when those libraries inevitably stop being supported.
- dhritzkiv 5y ago
  Totally. 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.
  - kitsunesoba 5y ago
    Strong agree here. This is also tied into the "batteries included" approach of Apple platforms, because many if not the majority of Swift/Obj-C libraries are mainly wrappers around system frameworks that either bring them to a higher level (in the case of C or C++ APIs) or add a sprinkle of syntactic sugar and light-to-moderate gap filling functionality. So naturally, these libraries are easier to maintain in the long term simply because they're doing so much less.
  - iainmerrick 5y ago
    I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. 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.
    - gavinray 5y ago
      There's a tool called "scapix" that's popped up recently that fixes this and is really impressive. 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 It also is really useful if you want to use Java from C++. Manual JNI invocation and type translation is awful, this just smoothes over all of it. https://github.com/scapix-com/scapix#java-link Good usecase being when you want to extend a Java app with some native capabilities. 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.
      - iainmerrick 5y ago
        Sounds great, I’ll check it out! 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.
        pjmlp 5y ago
        Because as per Android team, you should only be writing C or C++ code for implementing Java native methods, Vulkan, real time audio, integrating native libraries from other platforms, or anything else game development related. 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.
    - deleted 5y ago
      [deleted]

kitsunesoba 5y ago

I haven't had a chance to use Jetpack Compose yet but this roughly tracks with my experience. Needing to hunt down third-party libs for everything slows development down considerably and makes for complications down the road when those libraries inevitably stop being supported.

dhritzkiv 5y ago
Totally. 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.
- kitsunesoba 5y ago
  Strong agree here. This is also tied into the "batteries included" approach of Apple platforms, because many if not the majority of Swift/Obj-C libraries are mainly wrappers around system frameworks that either bring them to a higher level (in the case of C or C++ APIs) or add a sprinkle of syntactic sugar and light-to-moderate gap filling functionality. So naturally, these libraries are easier to maintain in the long term simply because they're doing so much less.
- iainmerrick 5y ago
  I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. 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.
  - gavinray 5y ago
    There's a tool called "scapix" that's popped up recently that fixes this and is really impressive. 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 It also is really useful if you want to use Java from C++. Manual JNI invocation and type translation is awful, this just smoothes over all of it. https://github.com/scapix-com/scapix#java-link Good usecase being when you want to extend a Java app with some native capabilities. 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.
    - iainmerrick 5y ago
      Sounds great, I’ll check it out! 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.
      - pjmlp 5y ago
        Because as per Android team, you should only be writing C or C++ code for implementing Java native methods, Vulkan, real time audio, integrating native libraries from other platforms, or anything else game development related. 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.
  - deleted 5y ago
    [deleted]