4 ms·

And you are now locked down to one environment.

by germandiago 3y ago

ryanwaggoner 3y ago
One man’s downside is another’s upside.
- jwells89 3y ago
  Indeed. Supporting a single platform means generally fewer bugs and headaches, as multi-platform is going to introduce new troubles regardless of how one goes about it. Approaches that try to be write-once-run-everywhere “silver bullets” will still see platform—specific bugs, as will per-platform codebases. It’s not a coincidence that macOS/iOS has long had a disproportionally large quantity of high quality indieware. Capable framework + minimal headaches = polished apps that an individual or small group can sustainably support, even within less profitable niches and without VC funding.
settsu 3y ago
And? There are plenty of companies which have fared just fine under such "limitations".
Analemma_ 3y ago
The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows. Cross-platform applications have their place, but sometimes I like having features that I can get in one place and nowhere else. Let them both exist and quit griping about it.
- jwells89 3y ago
  This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.
  - Analemma_ 3y ago
    It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead. There's no silver bullet here.
    - jwells89 3y ago
      Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code. For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set. Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing. In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX. [0]: https://mauikit.org https://mauikit.org
      - rubymamis 3y ago
        You can use Rust with QML[1]. QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you. I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer. [1] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [2] https://www.get-plume.com/ https://www.get-plume.com/ [3] https://www.appflowy.io/ https://www.appflowy.io/ [4] https://github.com/stdware/qwindowkit https://github.com/stdware/qwindowkit
- fauigerzigerk 3y ago
  What I find bizarre is that this is often discussed without considering the specifics of the app. I agree that not every app must be cross-platform. Text editors are a good example. The economics may or may not be more difficult. Yes the audience is smaller but the cost may be lower as well and you may have a competitive edge over cross-platform apps. The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features (unless the app is built on top of some cross-platform protocol or file format) and that you're not going to serve multi-platform users any time soon. This is a big decision with far reaching consequences. I think there's a risk for developers (and tech bloggers) to become so enamoured with the fine details of their platform of choice that they lose touch with the priorities of the user community.
  - internetter 3y ago
    > The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason
- germandiago 3y ago
  It is a matter of product: better to target more people better than fewer. Technology is usually secondary here.
allenu 3y ago
If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.
- satvikpendem 3y ago
  Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
  - allenu 3y ago
    As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on. Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
    - satvikpendem 3y ago
      Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
      - jwells89 3y ago
        “Easier” depends a lot on the project in my experience. For example if you need a tableview/datagrid as performant and feature rich as NSTableView on Swift/AppKit, you’re probably going to have to build it yourself with React (of any flavor) and especially Flutter (which has a heavy mobile bent to it) or at minimum settle for a community library that’s got big holes in its functionality. There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.
mattgreenrocks 3y ago
Often worth it for superior UX. The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
- FpUser 3y ago
  You can write app that will work on Windows, Mac, Linux, iOS, Android using Delphi.
  - skydhash 3y ago
    Working is easy, working well isn’t.
  - internetter 3y ago
    The Windows 7 example on their home page does not inspire confidence. I'd much rather be locked into macOS than be locked into this
    - FpUser 3y ago
      I brought it just as an example of what is possible. I do not give rat's ass whether it "inspires one's confidence" and who wants to be locked into what.
  - zoom6628 3y ago
    Freepascal is only tool I have found that creates same look and feel across platforms. After so many years of promise and intentions the cross platform issue only solved by Delphi/fpc to a professional level as far as I can tell. It's a metaphor for our industry chasing bling over productivity and generations seeking g rip and replace rather than understanding the constraints the prev gen worked with. Im only 60 but have worked with assembler, Algol, COBOL, Delphi, pascal, Awk, c#, various BASICs from apple II to VB.net. Python and JavaScript for 2 decades. Now most excited about Mojo.
detourdog 3y ago
I'm not sure one is locked down. One can write the model and the controller in the style one likes and then they just bind to appkit/uikit for the Apple versions. This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.
Vermyndax 3y ago
One environment with support on a vast plethora of devices and a long lifespan.
satvikpendem 3y ago
Indeed, Apple customers are quite a big market of course, but as an indie dev especially, there are more markets to bring your products and services to. That is why I use frameworks like Flutter which work everywhere, even if they are worse than Apple's developer platforms (and this is subjective even still). The upside is simply too great to lock myself to only one platform.

And you are now locked down to one environment.

ryanwaggoner 3y ago

One man’s downside is another’s upside.

jwells89 3y ago
Indeed. Supporting a single platform means generally fewer bugs and headaches, as multi-platform is going to introduce new troubles regardless of how one goes about it. Approaches that try to be write-once-run-everywhere “silver bullets” will still see platform—specific bugs, as will per-platform codebases. It’s not a coincidence that macOS/iOS has long had a disproportionally large quantity of high quality indieware. Capable framework + minimal headaches = polished apps that an individual or small group can sustainably support, even within less profitable niches and without VC funding.

settsu 3y ago

And? There are plenty of companies which have fared just fine under such "limitations".

Analemma_ 3y ago

The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows. Cross-platform applications have their place, but sometimes I like having features that I can get in one place and nowhere else. Let them both exist and quit griping about it.

jwells89 3y ago
This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.
- Analemma_ 3y ago
  It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead. There's no silver bullet here.
  - jwells89 3y ago
    Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code. For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set. Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing. In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX. [0]: https://mauikit.org https://mauikit.org
    - rubymamis 3y ago
      You can use Rust with QML[1]. QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you. I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer. [1] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [2] https://www.get-plume.com/ https://www.get-plume.com/ [3] https://www.appflowy.io/ https://www.appflowy.io/ [4] https://github.com/stdware/qwindowkit https://github.com/stdware/qwindowkit
fauigerzigerk 3y ago
What I find bizarre is that this is often discussed without considering the specifics of the app. I agree that not every app must be cross-platform. Text editors are a good example. The economics may or may not be more difficult. Yes the audience is smaller but the cost may be lower as well and you may have a competitive edge over cross-platform apps. The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features (unless the app is built on top of some cross-platform protocol or file format) and that you're not going to serve multi-platform users any time soon. This is a big decision with far reaching consequences. I think there's a risk for developers (and tech bloggers) to become so enamoured with the fine details of their platform of choice that they lose touch with the priorities of the user community.
- internetter 3y ago
  > The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason
germandiago 3y ago
It is a matter of product: better to target more people better than fewer. Technology is usually secondary here.

allenu 3y ago

If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.

satvikpendem 3y ago
Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
- allenu 3y ago
  As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on. Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
  - satvikpendem 3y ago
    Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
    - jwells89 3y ago
      “Easier” depends a lot on the project in my experience. For example if you need a tableview/datagrid as performant and feature rich as NSTableView on Swift/AppKit, you’re probably going to have to build it yourself with React (of any flavor) and especially Flutter (which has a heavy mobile bent to it) or at minimum settle for a community library that’s got big holes in its functionality. There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.

mattgreenrocks 3y ago

Often worth it for superior UX. The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.

FpUser 3y ago
You can write app that will work on Windows, Mac, Linux, iOS, Android using Delphi.
- skydhash 3y ago
  Working is easy, working well isn’t.
- internetter 3y ago
  The Windows 7 example on their home page does not inspire confidence. I'd much rather be locked into macOS than be locked into this
  - FpUser 3y ago
    I brought it just as an example of what is possible. I do not give rat's ass whether it "inspires one's confidence" and who wants to be locked into what.
- zoom6628 3y ago
  Freepascal is only tool I have found that creates same look and feel across platforms. After so many years of promise and intentions the cross platform issue only solved by Delphi/fpc to a professional level as far as I can tell. It's a metaphor for our industry chasing bling over productivity and generations seeking g rip and replace rather than understanding the constraints the prev gen worked with. Im only 60 but have worked with assembler, Algol, COBOL, Delphi, pascal, Awk, c#, various BASICs from apple II to VB.net. Python and JavaScript for 2 decades. Now most excited about Mojo.

detourdog 3y ago

I'm not sure one is locked down. One can write the model and the controller in the style one likes and then they just bind to appkit/uikit for the Apple versions. This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.

Vermyndax 3y ago

One environment with support on a vast plethora of devices and a long lifespan.

satvikpendem 3y ago

Indeed, Apple customers are quite a big market of course, but as an indie dev especially, there are more markets to bring your products and services to. That is why I use frameworks like Flutter which work everywhere, even if they are worse than Apple's developer platforms (and this is subjective even still). The upside is simply too great to lock myself to only one platform.