6 ms·

Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful

Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful, or the user experience is awful. Actually, it's usually both. The thing is that its easy to get 90% there with these things. But getting that last 10% is often a huge hurdle, erasing most of the efficiency gains you just made. Then, when a new hot framework comes along, the old hottness you bet your project on quickly becomes deprecated, and you have to rewrite your whole project under duress. I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian... How long before people give up on that and move on to the next thing? Hiring is really tough as well. With cross platform, at the end of the day, when you get that crazy memory issue or app crash, you need native expertise. So to be an effective cross platform engineer, you have to be an expert in iOS, Android, and whatever hot framework you bet on. If you need to get to market very quickly and are OK with throwing it all away in a few years, cross platform is a great choice. But if you want your app to stand the test of time, the best thing you can do is to write it in the only framework which is officially supported by the platform - all native.

api 4y ago
... which means you have to write the application at least twice for mobile and at least three times for desktop. On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. On mobile I guess only two platforms is not quite as bad so more people cope with it?
- trog 4y ago
  > It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications. I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out). I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.
  - brundolf 4y ago
    Slack used to feel better than it does now, and from my outside perspective it feels like most of the slowness that's started to happen comes down to lazier caching and slower back-end requests (loading conversations, etc)
  - api 4y ago
    They do it because coding a large UI project is brutally hard and money doesn't help that much. Building a new UI team is hard, hiring is hard, managing is hard, designing is hard, it's all brutal. Now do that 2-3X in parallel and manage that efficiently and ship new features on time. Couple that with the fact that web devs are much easier to recruit than devs for any native platform and it's easy to see why they don't bother with native. The real choice is (1) be single-platform (Mac only, Windows only, etc) or (2) use a cross-platform UI with Electron being the easiest to adopt.
    - phist_mcgee 4y ago
      Bang on the money.
  - dceddia 4y ago
    I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written. Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code. It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too) https://inessential.com/2020/05/18/why_netnewswire_is_fast https://inessential.com/2020/05/18/why_netnewswire_is_fast
    - claytongulick 4y ago
- saratogacx 4y ago
  From my experience the reason why these kinds of platforms get used as much as they do is that it follows the concept of the fungible developer. It is painful and expensive to find an iOS/Android/Win32 developer because the pool of skilled developers limited. The promise around much of these frameworks is that any dev with web experience can handle these and become a cross-platform generalist. Faster and less expensive to find more/backfill developers and, most of the time, it won't cost anything in lost sales. // tangential rant follows The experience suffers but when you look at the tech landscape as a whole, there is little to no native application niche that is presenting an opportunity. Quite the other way, the prevailing trend is that everything is bring brought down to the limits of the OS's webview components. You even see this in, what used to be, pure native applications like office. One of the latest changes they're doing is replacing the room finder with one backed by a webview2 control. It sucks and is a lot less capable from the native version, but it is following the same path being charted by our industry.
whycombagator 4y ago
Ionic has been a round for a while, good development experience, from what I can tell there are some good Ionic apps out there Xamarin (MAUI now) is pretty decent and there are good apps out there (Bitwarden for example).
suzzer99 4y ago
> I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian... I honestly can't count the number of times I've been down this road - Alfresco, Hazelcast, Sencha Touch, a bunch of others I can't remember right now. People skills become very important.

api 4y ago

... which means you have to write the application at least twice for mobile and at least three times for desktop. On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. On mobile I guess only two platforms is not quite as bad so more people cope with it?

trog 4y ago
> It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications. I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out). I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.
- brundolf 4y ago
  Slack used to feel better than it does now, and from my outside perspective it feels like most of the slowness that's started to happen comes down to lazier caching and slower back-end requests (loading conversations, etc)
- api 4y ago
  They do it because coding a large UI project is brutally hard and money doesn't help that much. Building a new UI team is hard, hiring is hard, managing is hard, designing is hard, it's all brutal. Now do that 2-3X in parallel and manage that efficiently and ship new features on time. Couple that with the fact that web devs are much easier to recruit than devs for any native platform and it's easy to see why they don't bother with native. The real choice is (1) be single-platform (Mac only, Windows only, etc) or (2) use a cross-platform UI with Electron being the easiest to adopt.
  - phist_mcgee 4y ago
    Bang on the money.
- dceddia 4y ago
  I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written. Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code. It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too) https://inessential.com/2020/05/18/why_netnewswire_is_fast https://inessential.com/2020/05/18/why_netnewswire_is_fast
  - claytongulick 4y ago
saratogacx 4y ago
From my experience the reason why these kinds of platforms get used as much as they do is that it follows the concept of the fungible developer. It is painful and expensive to find an iOS/Android/Win32 developer because the pool of skilled developers limited. The promise around much of these frameworks is that any dev with web experience can handle these and become a cross-platform generalist. Faster and less expensive to find more/backfill developers and, most of the time, it won't cost anything in lost sales. // tangential rant follows The experience suffers but when you look at the tech landscape as a whole, there is little to no native application niche that is presenting an opportunity. Quite the other way, the prevailing trend is that everything is bring brought down to the limits of the OS's webview components. You even see this in, what used to be, pure native applications like office. One of the latest changes they're doing is replacing the room finder with one backed by a webview2 control. It sucks and is a lot less capable from the native version, but it is following the same path being charted by our industry.

whycombagator 4y ago

Ionic has been a round for a while, good development experience, from what I can tell there are some good Ionic apps out there Xamarin (MAUI now) is pretty decent and there are good apps out there (Bitwarden for example).

suzzer99 4y ago

> I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian... I honestly can't count the number of times I've been down this road - Alfresco, Hazelcast, Sencha Touch, a bunch of others I can't remember right now. People skills become very important.