50 ms·

On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance

On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.

paperplatter 2y ago
Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.
- ameliaquining 2y ago
  I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.
  - paperplatter 2y ago
    Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.
  - evilfred 2y ago
    except for the thousand times you end up having to dip down into native components
    - nwienert 2y ago
      I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though. https://github.com/uniswap/interface https://github.com/uniswap/interface
      - fingerlocks 2y ago
        I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.
        nwienert 2y ago
        You can make a disaster in any framework. SwiftUI is a mess, for example, and slow. React Native took a while to mature, but with the right tooling you can ship amazing UX now. I don’t doubt there’s a ton of crap out there. But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot. And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.
        fingerlocks 2y ago
        I have made a countless PRs to many of the most popular react-native dependencies because they were a buggy mess. In fact at this very moment I’m helping a team fix a memory leak/crash in the “react-native-permissions” dependency. It’s obvious this package was not written by someone with experience. All it does is request permissions in a paragraph of code and it’s totally broken! Give me a break
        nwienert 2y ago
        I have plenty of nightmare stories to tell you about native deps.
        paperplatter 2y ago
        It can get tough with the native dependencies involved.
        cageface 2y ago
        When I was still doing contract work I rescued a bunch of native code iOS app disasters. For most apps cross platform solutions are fine.
    - nsonha 2y ago
      Like you dont have to know native components anyway? In one way you centralise as much logic as you can and are encouraged to write clean code that doen't depend on platfrom quirks. In the other way you... give up and just do whatever. I can see how some devs find it hard to not give up and just write the same logic in multiple languages, great job security!
- cageface 2y ago
  My main app is a cross platform Flutter app. I've considered rewriting it in Swift because most of my users are on macOS or iOS but all the prototypes I've written are actually slower even after extensive performance work and the development experience makes me want to tear my hair out.
  - felideon 2y ago
    Ironic, given Flutter's infamy regarding performance (jank).
    - paperplatter 2y ago
      I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.
      - cageface 2y ago
        UIKit is pretty fast although a major step down in dev velocity. AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.
        fingerlocks 2y ago
        Odd criticism. UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.
        vor_ 2y ago
        Not sure what you mean by "implemented as convenience wrappers around CALayers," especially when it comes to NSView where you have to opt-in to layer-backing.
- pjmlp 2y ago
  People go to React Native to stay on their cozy Web skills, it is exactly the same if we would be talking about Microsoft and Google platforms.
  - paperplatter 2y ago
    I started using RN when I had 0 web skills and didn't know JS. Everything from making a simple button to hooking up the model was easier to me in RN from day 1 than the native iOS way that I'd been using for years.
    - pjmlp 2y ago
      As someone that unfortunately has to deal with React ecosystem, and knows reasonably well native programming across Apple, Google and Microsoft ecosystems, I have some hard time believing that, but might be a knowledge issue.
      - riesinger 2y ago
        The Google ecosystem? Isn’t that also just Web-based?
        paperplatter 2y ago
        Not Android
seec 2y ago
To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple. But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.

paperplatter 2y ago

Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.

ameliaquining 2y ago
I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.
- paperplatter 2y ago
  Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.
- evilfred 2y ago
  except for the thousand times you end up having to dip down into native components
  - nwienert 2y ago
    I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though. https://github.com/uniswap/interface https://github.com/uniswap/interface
    - fingerlocks 2y ago
      I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.
      - nwienert 2y ago
        You can make a disaster in any framework. SwiftUI is a mess, for example, and slow. React Native took a while to mature, but with the right tooling you can ship amazing UX now. I don’t doubt there’s a ton of crap out there. But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot. And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.
        fingerlocks 2y ago
        I have made a countless PRs to many of the most popular react-native dependencies because they were a buggy mess. In fact at this very moment I’m helping a team fix a memory leak/crash in the “react-native-permissions” dependency. It’s obvious this package was not written by someone with experience. All it does is request permissions in a paragraph of code and it’s totally broken! Give me a break
        nwienert 2y ago
        I have plenty of nightmare stories to tell you about native deps.
        paperplatter 2y ago
        It can get tough with the native dependencies involved.
      - cageface 2y ago
        When I was still doing contract work I rescued a bunch of native code iOS app disasters. For most apps cross platform solutions are fine.
  - nsonha 2y ago
    Like you dont have to know native components anyway? In one way you centralise as much logic as you can and are encouraged to write clean code that doen't depend on platfrom quirks. In the other way you... give up and just do whatever. I can see how some devs find it hard to not give up and just write the same logic in multiple languages, great job security!
cageface 2y ago
My main app is a cross platform Flutter app. I've considered rewriting it in Swift because most of my users are on macOS or iOS but all the prototypes I've written are actually slower even after extensive performance work and the development experience makes me want to tear my hair out.
- felideon 2y ago
  Ironic, given Flutter's infamy regarding performance (jank).
  - paperplatter 2y ago
    I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.
    - cageface 2y ago
      UIKit is pretty fast although a major step down in dev velocity. AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.
      - fingerlocks 2y ago
        Odd criticism. UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.
        vor_ 2y ago
        Not sure what you mean by "implemented as convenience wrappers around CALayers," especially when it comes to NSView where you have to opt-in to layer-backing.
pjmlp 2y ago
People go to React Native to stay on their cozy Web skills, it is exactly the same if we would be talking about Microsoft and Google platforms.
- paperplatter 2y ago
  I started using RN when I had 0 web skills and didn't know JS. Everything from making a simple button to hooking up the model was easier to me in RN from day 1 than the native iOS way that I'd been using for years.
  - pjmlp 2y ago
    As someone that unfortunately has to deal with React ecosystem, and knows reasonably well native programming across Apple, Google and Microsoft ecosystems, I have some hard time believing that, but might be a knowledge issue.
    - riesinger 2y ago
      The Google ecosystem? Isn’t that also just Web-based?
      - paperplatter 2y ago
        Not Android

seec 2y ago

To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple. But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.