3 ms·

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next)

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so you can expect that they will keep on iterating on it for many years to come.

LudwigNagasena 4y ago
Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.
- lapcat 4y ago
  > It’s the same company, they should be able to leverage their past knowledge. It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc. https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
  - LudwigNagasena 4y ago
    I guess that means we should expect AppKit and SwiftUI to never improve.
    - lapcat 4y ago
      AppKit has been going downhill for years.
      - StewardMcOy 4y ago
        I don't know why this is being downvoted. The situation is more complex than this simple comment, but the sentiment is correct. The reality is that AppKit has had its ups and downs recently. There are obviously people in Apple trying to do their best to patch things up, and there have been some nice improvements because of their efforts, but some really bad bugs have been introduced, only to sit unfixed for years. It's gotten to the point where I dread the yearly OS updates, not because I dread having to update my code, but because I worry what has broken. In my experience, if you don't get your bugs filed within the first week after WWDC, they'll never get fixed, and even if you do, it's a toss-up. But testing your existing code isn't always enough. If you're writing new code to take advantage of some of the new OS features, you can be a month into the beta cycle before you find a bug, and by that point, its too late.
        plorkyeran 4y ago
        The worst part is that new things are often completely broken or outright missing in beta 1, and then by the time you can actually test them in beta 3 it's too late to report bugs and have any real hope of them getting fixed.
      - Klonoar 4y ago
        Uhhh, not sure I agree. You could argue it’s stagnant, maybe - but it’s just as good as it’s always been.
        lapcat 4y ago
        > You could argue it’s stagnant, maybe Quite the opposite. I would argue that macOS (the artist formerly known as Mac OS X) is quickly being transformed into iOS. Big Sur was a massive change in this respect, and the transformation continues in Ventura.
        solarkraft 4y ago
        iOS has a super solid UI, so that would be great. Instead Control Center takes 2 seconds to show up and without any animation. UI wise at best it's some paint. The port of Stage Manager is horrendous as well. Freedom wise I find it just about still tolerable. You can still run non-blessed binaries after some hoops and access a good amount of APIs.
- GeekyBear 4y ago
  So Microsoft's ARM based Windows RT should have been able to run any x86 software, because Microsoft had been coding Windows for a long time? Sorry, but it takes time for new things to gain functionality and polish. Windows RT was from 2012, and running x86 software on ARM only became possible recently.
  - LudwigNagasena 4y ago
    Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.
    - GeekyBear 4y ago
      Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?
      - LudwigNagasena 4y ago
        I don’t think that the situations are comparable. ARM/x86 and UI are quite different.
        GeekyBear 4y ago
        I don't think the time lag between the first release of Windows on ARM in 2012 and finally gaining the ability to (badly) run x86 programs a decade later is comparable. >I’d have only Slack open, and switching between channels would still take almost three seconds (yes, I timed it on my phone). Spotify, also with nothing in the background, would take 11 seconds to open, then be frozen for another four seconds before I could finally press play. When I typed in Chrome, I often saw significant lag, which led to all kinds of typos (because my words weren’t coming out until well after I’d written them). I’d try to watch YouTube videos, and the video would freeze while the audio continued. I’d use the Surface Pen to annotate a PDF, and my strokes would either be frustratingly late or not show up at all. I’d try to open Lightroom, and it would freeze multiple times and then crash. It quickly became clear that I should try to stick to apps that were running natively on Arm. https://www.theverge.com/23421326/microsoft-surface-pro-9-arm-qualcomm-sq3-review https://www.theverge.com/23421326/microsoft-surface-pro-9-ar...
ohgodplsno 4y ago
Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases. [1] https://compose-web.ui.pages.jetbrains.team/ https://compose-web.ui.pages.jetbrains.team/ [2] https://github.com/JakeWharton/mosaic https://github.com/JakeWharton/mosaic [3] https://github.com/fgiris/composePPT https://github.com/fgiris/composePPT [4] https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/ [5] https://github.com/googlemaps/android-maps-compose https://github.com/googlemaps/android-maps-compose
- kitsunesoba 4y ago
  IIRC the reason why SwiftUI isn’t a separate library is that it’s developed in lockstep with Swift, meaning that each release is dependent on new features in its contemporary release of Swift. That’s a problem because they stopped building Swift into third party app packages a few years ago in effort to bring down app download sizes, but that means that apps have to deal with whatever version of Swift comes with the user’s system. The best middle ground would probably be to ship Swift as a periodically updated package.
  - pohuing 4y ago
    Couldn't they just separate swift runtimes from the os updates? I'm always baffled by how often features are tied to seemingly random os versions. For example: You can't debug IOS 14.5 apps on Big Sur because Xcode for some reason needs Monterey. Though if you just spoof the required version in the xip's app manifest it'll work mostly fine.
alexashka 4y ago
> Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic Is it? Should I expect my M1 macbook to break in unexpected ways for a decade before it works too? M1 is new, like SwiftUI is new, how come it actually works? Apple devs have stockholm syndrome.
- GeekyBear 4y ago
  > M1 is new Leaks of Apple doing test ports of MacOS to it's ARM chips dated way back to 2011. So, not new at all.

LudwigNagasena 4y ago

Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.

lapcat 4y ago
> It’s the same company, they should be able to leverage their past knowledge. It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc. https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
- LudwigNagasena 4y ago
  I guess that means we should expect AppKit and SwiftUI to never improve.
  - lapcat 4y ago
    AppKit has been going downhill for years.
    - StewardMcOy 4y ago
      I don't know why this is being downvoted. The situation is more complex than this simple comment, but the sentiment is correct. The reality is that AppKit has had its ups and downs recently. There are obviously people in Apple trying to do their best to patch things up, and there have been some nice improvements because of their efforts, but some really bad bugs have been introduced, only to sit unfixed for years. It's gotten to the point where I dread the yearly OS updates, not because I dread having to update my code, but because I worry what has broken. In my experience, if you don't get your bugs filed within the first week after WWDC, they'll never get fixed, and even if you do, it's a toss-up. But testing your existing code isn't always enough. If you're writing new code to take advantage of some of the new OS features, you can be a month into the beta cycle before you find a bug, and by that point, its too late.
      - plorkyeran 4y ago
        The worst part is that new things are often completely broken or outright missing in beta 1, and then by the time you can actually test them in beta 3 it's too late to report bugs and have any real hope of them getting fixed.
    - Klonoar 4y ago
      Uhhh, not sure I agree. You could argue it’s stagnant, maybe - but it’s just as good as it’s always been.
      - lapcat 4y ago
        > You could argue it’s stagnant, maybe Quite the opposite. I would argue that macOS (the artist formerly known as Mac OS X) is quickly being transformed into iOS. Big Sur was a massive change in this respect, and the transformation continues in Ventura.
        solarkraft 4y ago
        iOS has a super solid UI, so that would be great. Instead Control Center takes 2 seconds to show up and without any animation. UI wise at best it's some paint. The port of Stage Manager is horrendous as well. Freedom wise I find it just about still tolerable. You can still run non-blessed binaries after some hoops and access a good amount of APIs.
GeekyBear 4y ago
So Microsoft's ARM based Windows RT should have been able to run any x86 software, because Microsoft had been coding Windows for a long time? Sorry, but it takes time for new things to gain functionality and polish. Windows RT was from 2012, and running x86 software on ARM only became possible recently.
- LudwigNagasena 4y ago
  Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.
  - GeekyBear 4y ago
    Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?
    - LudwigNagasena 4y ago
      I don’t think that the situations are comparable. ARM/x86 and UI are quite different.
      - GeekyBear 4y ago
        I don't think the time lag between the first release of Windows on ARM in 2012 and finally gaining the ability to (badly) run x86 programs a decade later is comparable. >I’d have only Slack open, and switching between channels would still take almost three seconds (yes, I timed it on my phone). Spotify, also with nothing in the background, would take 11 seconds to open, then be frozen for another four seconds before I could finally press play. When I typed in Chrome, I often saw significant lag, which led to all kinds of typos (because my words weren’t coming out until well after I’d written them). I’d try to watch YouTube videos, and the video would freeze while the audio continued. I’d use the Surface Pen to annotate a PDF, and my strokes would either be frustratingly late or not show up at all. I’d try to open Lightroom, and it would freeze multiple times and then crash. It quickly became clear that I should try to stick to apps that were running natively on Arm. https://www.theverge.com/23421326/microsoft-surface-pro-9-arm-qualcomm-sq3-review https://www.theverge.com/23421326/microsoft-surface-pro-9-ar...

ohgodplsno 4y ago

Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases. [1] https://compose-web.ui.pages.jetbrains.team/ https://compose-web.ui.pages.jetbrains.team/ [2] https://github.com/JakeWharton/mosaic https://github.com/JakeWharton/mosaic [3] https://github.com/fgiris/composePPT https://github.com/fgiris/composePPT [4] https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/ [5] https://github.com/googlemaps/android-maps-compose https://github.com/googlemaps/android-maps-compose

kitsunesoba 4y ago
IIRC the reason why SwiftUI isn’t a separate library is that it’s developed in lockstep with Swift, meaning that each release is dependent on new features in its contemporary release of Swift. That’s a problem because they stopped building Swift into third party app packages a few years ago in effort to bring down app download sizes, but that means that apps have to deal with whatever version of Swift comes with the user’s system. The best middle ground would probably be to ship Swift as a periodically updated package.
- pohuing 4y ago
  Couldn't they just separate swift runtimes from the os updates? I'm always baffled by how often features are tied to seemingly random os versions. For example: You can't debug IOS 14.5 apps on Big Sur because Xcode for some reason needs Monterey. Though if you just spoof the required version in the xip's app manifest it'll work mostly fine.

alexashka 4y ago

> Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic Is it? Should I expect my M1 macbook to break in unexpected ways for a decade before it works too? M1 is new, like SwiftUI is new, how come it actually works? Apple devs have stockholm syndrome.

GeekyBear 4y ago
> M1 is new Leaks of Apple doing test ports of MacOS to it's ARM chips dated way back to 2011. So, not new at all.