3 ms·

I am very unconvinced by cross platform UI solutions, as such I like the idea of Kotlin Multiplatform. Sharing non UI code has always been possible via C/C++, b

I am very unconvinced by cross platform UI solutions, as such I like the idea of Kotlin Multiplatform. Sharing non UI code has always been possible via C/C++, but it suffers from several issues not the least of which is having to write C/C++. The executions I've seen of this for example often bundle curl + boringSSL for an HTTP/HTTPS stack instead of linking against the system provided networking libraries. Aside from Kotlin I also think Rust with C FFI or WASM are good potential avenues to explore here. In the WASM case generic business logic can be written in Rust and compiled to WASM, platform capabilities such as networking/GPS etc can be exposed to the WASM VM via functions provided by the host. Further, with WASM it would also be possible to run the same code across web, native clients, and the server.

dep_b 6y ago
The main reason to use Kotlin is that it looks like Swift and most Android engineers already use it. As an Objective-C and Swift developer I can read C and C++ and dibble a bit in it but to write serious code from scratch: forget it. Kotlin itself feels quite natural, though the Java and Android libraries especially can be a bit weird at times.
- K0nserv 6y ago
  Yeah that’s definitely a strength of Kotlin multi platform. My general point is that doing cross platform UI specifically leads to poor experiences, whereas sharing non UI code doesn’t have that issue
  - The_rationalist 6y ago
    Why would ionic leads to poor experiences?
    - K0nserv 6y ago
      Cross platform solutions all share several issues that result in poor experiences: Reimplementing platform UI Poor reimplementaions of platform UI, such as navigation, that almost always looks subtley wrong or doesn't "feel" right in terms of interactivity. This also often lead to shipping a single platform's UI convention on every platform, for example Material on iOS or iOS patterns and conventions on Android. Poor UX An app's UI is more than just how it looks, just as important is how it feels, and if it fits in and feels at home as an app on the platform. Often cross platform solutions generate apps that have slightly "off" UX, such as sluggish interactivity(RN has this this issue), missing gestures(such as backswipe). In general many small cuts that deterioriate the user experience Focus only on the visual The visual representation of an app is only one part of the UI as mentioned above, an obvious other example is accessibility which is often lacking with cross platform tech, especially on iOS. I wrote a whole blog post about how Flutter Web fails[0] in this regard yesterday. Binary size By necessity cross platform solutions reinvent a lot of what the platform already provides which leads to larger binaries(performance is a feature). Performance Ionic for example, runs in a non-JIT(on iOS) enabled webview so can never match the performance of native. React Native runs a JS enging(again no JIT on iOS) which demands more from the device and uses more battery than native in my experience(performance is a feature). In general, cross platform UI works by targetting a lowest common denominator of the platforms which naturally results in a worse experience. 0: https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-bad-design.html https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-ba...
      - yesimahuman 6y ago
        A few things: Ionic is not Flutter. Flutter has to ship a ton of code to reimplement things Ionic can use right from the browser. Size increase is marginal with Ionic and Ionic can be used to build high lighthouse performance PWAs which Flutter Web cannot in its current state. Ionic does use a JIT-ed webview. WKWebView is JIT'ed, but JavaScriptCore (which React Native uses) is not. The rest of your points are subjective and we find Ionic apps, when designed well like any other app, have great performance and user ratings.
        The_rationalist 6y ago
        Hi Yesimahuman, I am really tired of seeing again and again the same myths being said about Ionic. Why not put an end to this by showing to the world scientific evidence? I just created this issue for tracking such an effort and flutter strive for the same goal: https://github.com/ionic-team/ionic-framework/issues/22417 https://github.com/ionic-team/ionic-framework/issues/22417 Plus it would allow tracking/catching performance regressions
      - novok 6y ago
        I think a better way to think of flutter web is flutter is using the web browser as a graphics layer to create a video game or desktop app, like SDL. It's not attempting to create an html web document. Also nowadays the dominant computation platform of the world is mobile phones, with most of the world being Android and many with money being iOS. Desktop UIs like the web with custom screen reader & extensions & custom css mod and such are not the P0 priority. I would also imagine it's not the majority of people with these accessibility needs using it either. Desktops are the world of the office worker, middle aged person who's calcified into desktops or other power user types. It would be hooking into iOS & Android standardized accessibility APIs. I'd imagine it executes far better there, because non-selectable text in UI elements are pretty much platform standard for mobile & desktop apps. Furthermore in that light I'm guessing that flutter web & desktop are also P2 projects to the P1 flutter mobile projects, and android / material design is P0.
    - yesimahuman 6y ago
      You can build great experiences with Ionic. Like anything, going the extra mile to build a great app still applies.
kitsunesoba 6y ago
> The executions I've seen of this for example often bundle curl + boringSSL for an HTTP/HTTPS stack instead of linking against the system provided networking libraries. For this reason, I’m hesitant to make use of a shared codebase for the networking parts of an app. By using your own stack, you’re throwing out a ton of device-specific optimizations and risk things like keeping the user’s cell antenna activated for longer than needed or not gracefully handling transitions between connection types. For most mobile apps, I think the only part that really makes sense to share between platforms are those to do with pure logic and data manipulation, since there’s not as much benefit from doing that full native, and any processing optimizations are typically surfaced in a way that’s accessible to lower level languages (and thus third party stuff like Kotlin Multiplatform).
- K0nserv 6y ago
  Yeah I agree with the points about using your own stack, it's building towards the lowest common denominator that is the sockets support in libc. I think it should be possible to link against the platform libraries, but it's more work than just shiping your own stack.

dep_b 6y ago

The main reason to use Kotlin is that it looks like Swift and most Android engineers already use it. As an Objective-C and Swift developer I can read C and C++ and dibble a bit in it but to write serious code from scratch: forget it. Kotlin itself feels quite natural, though the Java and Android libraries especially can be a bit weird at times.

K0nserv 6y ago
Yeah that’s definitely a strength of Kotlin multi platform. My general point is that doing cross platform UI specifically leads to poor experiences, whereas sharing non UI code doesn’t have that issue
- The_rationalist 6y ago
  Why would ionic leads to poor experiences?
  - K0nserv 6y ago
    Cross platform solutions all share several issues that result in poor experiences: Reimplementing platform UI Poor reimplementaions of platform UI, such as navigation, that almost always looks subtley wrong or doesn't "feel" right in terms of interactivity. This also often lead to shipping a single platform's UI convention on every platform, for example Material on iOS or iOS patterns and conventions on Android. Poor UX An app's UI is more than just how it looks, just as important is how it feels, and if it fits in and feels at home as an app on the platform. Often cross platform solutions generate apps that have slightly "off" UX, such as sluggish interactivity(RN has this this issue), missing gestures(such as backswipe). In general many small cuts that deterioriate the user experience Focus only on the visual The visual representation of an app is only one part of the UI as mentioned above, an obvious other example is accessibility which is often lacking with cross platform tech, especially on iOS. I wrote a whole blog post about how Flutter Web fails[0] in this regard yesterday. Binary size By necessity cross platform solutions reinvent a lot of what the platform already provides which leads to larger binaries(performance is a feature). Performance Ionic for example, runs in a non-JIT(on iOS) enabled webview so can never match the performance of native. React Native runs a JS enging(again no JIT on iOS) which demands more from the device and uses more battery than native in my experience(performance is a feature). In general, cross platform UI works by targetting a lowest common denominator of the platforms which naturally results in a worse experience. 0: https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-bad-design.html https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-ba...
    - yesimahuman 6y ago
      A few things: Ionic is not Flutter. Flutter has to ship a ton of code to reimplement things Ionic can use right from the browser. Size increase is marginal with Ionic and Ionic can be used to build high lighthouse performance PWAs which Flutter Web cannot in its current state. Ionic does use a JIT-ed webview. WKWebView is JIT'ed, but JavaScriptCore (which React Native uses) is not. The rest of your points are subjective and we find Ionic apps, when designed well like any other app, have great performance and user ratings.
      - The_rationalist 6y ago
        Hi Yesimahuman, I am really tired of seeing again and again the same myths being said about Ionic. Why not put an end to this by showing to the world scientific evidence? I just created this issue for tracking such an effort and flutter strive for the same goal: https://github.com/ionic-team/ionic-framework/issues/22417 https://github.com/ionic-team/ionic-framework/issues/22417 Plus it would allow tracking/catching performance regressions
    - novok 6y ago
      I think a better way to think of flutter web is flutter is using the web browser as a graphics layer to create a video game or desktop app, like SDL. It's not attempting to create an html web document. Also nowadays the dominant computation platform of the world is mobile phones, with most of the world being Android and many with money being iOS. Desktop UIs like the web with custom screen reader & extensions & custom css mod and such are not the P0 priority. I would also imagine it's not the majority of people with these accessibility needs using it either. Desktops are the world of the office worker, middle aged person who's calcified into desktops or other power user types. It would be hooking into iOS & Android standardized accessibility APIs. I'd imagine it executes far better there, because non-selectable text in UI elements are pretty much platform standard for mobile & desktop apps. Furthermore in that light I'm guessing that flutter web & desktop are also P2 projects to the P1 flutter mobile projects, and android / material design is P0.
  - yesimahuman 6y ago
    You can build great experiences with Ionic. Like anything, going the extra mile to build a great app still applies.

kitsunesoba 6y ago

> The executions I've seen of this for example often bundle curl + boringSSL for an HTTP/HTTPS stack instead of linking against the system provided networking libraries. For this reason, I’m hesitant to make use of a shared codebase for the networking parts of an app. By using your own stack, you’re throwing out a ton of device-specific optimizations and risk things like keeping the user’s cell antenna activated for longer than needed or not gracefully handling transitions between connection types. For most mobile apps, I think the only part that really makes sense to share between platforms are those to do with pure logic and data manipulation, since there’s not as much benefit from doing that full native, and any processing optimizations are typically surfaced in a way that’s accessible to lower level languages (and thus third party stuff like Kotlin Multiplatform).

K0nserv 6y ago
Yeah I agree with the points about using your own stack, it's building towards the lowest common denominator that is the sockets support in libc. I think it should be possible to link against the platform libraries, but it's more work than just shiping your own stack.