3 ms·

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,

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

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]