17 ms·

While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments. T

While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments. That's my main gripe with apple's approach to swift and swiftui. Yes, tech is getting better every day, but unless you target latest OS version, you can't use new fresh stuff until it's on enough devices around you. And that pretty much guarantees that no matter what apple adds, you still have to wait a year or two until you can safely start using it. In modern android, kotlin(and compose) also part of the system, yet all the apps do not rely on the system libs, but rather inject the latest available runtime with each of the apps. It takes more space, but instead allows developers to target latest available stack, no matter what core os this app is being run on.

mpixel 3y ago
The tradeoff is that the app runs faster, looks better, works better -- in quite the indirect way. Now that the developers on the core part don't need to spend time on compatibility -- or, just dont want have to make the base choice of being a runtime dependency -- they can spend time on other things instead. This seems like a net negative at a glance, on the surface it means the apps are less compatible, so the second level is forced onto the older iterations, in practice, since each iteration has to worry about a lot less, the older iterations are _also_ a lot better instead. It is of no surprise to me these Apple or Apple-like systems tend to be better overall, as opposed to the other philosophy of Android. It leaks into all the levels. In the Java app, it is usual to see a deprecated warning that keeps working and it is maintained, and someone pays for that. The negative side is that there's no reason to get rid of the said dependency, either. My point is that lowering the maintenance cost of _any_ app or systems in general, leaves room for improvement in all the other areas, as long as you don't fall behind -- if you are allowed to fall behind, you can afford to, if not, the end result is better given enough time.
- flohofwoe 3y ago
  > It is of no surprise to me these Apple or Apple-like systems tend to be better overall This might have been true in the past, but it's been getting worse over the last decade. For instance: The new parts in macOS that are written in Swift seem to be mostly inferior to the parts they replaced (see for instance the new settings window written in SwiftUI, which UX wise is a joke compared to the old one, even though the old settings windows wasn't all that great either - case in point: try adding two DNS servers, searching for 'DNS server' only allows adding one item, then the DNS server panel closes and cannot be opened again without repeating the entire search, no idea how this mess made it through QA). If Swift is so much better than ObjC, then we should start seeing improvements as users, but that doesn't seem to happen, instead things are getting worse in new OS versions. Why is that?
  - newaccount74 3y ago
    I really hope that the new version of the settings app causes enough backlash that Apple starts fixing SwiftUI on the Mac...
    - deergomoo 3y ago
      The weirdest thing about System Settings is that SwiftUI already supports much more Mac-like idioms. They deliberately chose to use the odd-looking iOS-style switches, bizarre label alignment, and weird unique controls. While also keeping the annoying limitations of the old System Preferences app, such as not being able to resize the window.
  - galad87 3y ago
    The issue has got nothing to do with programming languages or UI toolkits, it's just that before there were more people with more attention to details, or now the management is so broken that there is no QA and no time to fix things.
    - flohofwoe 3y ago
      A good operating system UI framework should enforce the operating system's UX standards though and make it hard to create an UI which doesn't conform to the rules. But yeah, in the end, software quality needs to be tackled on the organizational level.
    - mpweiher 3y ago
      Really? Just at the moment that Swift and, later, SwiftUI get introduced, and entirely coincidentally, management breaks?
      - galad87 3y ago
        It's been a gradual process, looks at the Music app, how it has continuously got worse and buggier over the year, even without Swift and SwiftUI. You can't blame SwiftUI for that.
bowsamic 3y ago
I think this is a great way to slow down unconditional hype based adoption of new technologies imo, it gives time to make training materials. It’s probably why apple don’t feel the need to make good tutorials, bc they make an artificial delay between new features and actual practical use of them
tinus_hn 3y ago
I think the Log4j debacle makes it painfully clear that we simple can’t afford to trust application developers to keep bundled libraries up-to-date. Good idea, doesn’t work.
gedy 3y ago
> it also makes it non-updateable separately from the OS itself, which slows the spread of developments. Hasn't it always been this way with native desktop applications using the OS vendor's UI toolkit? What I hear some folks describe as "the old days" of Windows, Mac, etc.
- Someone 3y ago
  On the Mac, it was non-updateable separately from the hardware for a while (large parts of the UI toolkit shipped in ROM) :-) I think there also always was a new OS version for the new hardware, though, with the new hardware not running at all on older versions. The high speed at which computer tech improved at the time made that a bit of a smaller issue.
  - duskwuff 3y ago
    > On the Mac, it was non-updateable separately from the hardware for a while (large parts of the UI toolkit shipped in ROM) :-) Apple had a mechanism (ROvr resources) to allow the system software on disk to override components from ROM.
kstenerud 3y ago
I'm surprised that Apple didn't opt for a hybrid approach. They control the OS. They also control Swift. So why not embed the Swift version that the app was built against, and then download that swift version to the user's device when they download an app that uses it. Then: - The app runs against the exact Swift version it was built against - The app size is smaller because you're no longer shipping the Swift libraries with the app - The impact on the user's device space is minimized since it only downloads each version of Swift once (to be shared by all apps that use that version), and only on demand. - If a new version of Swift comes out before an OS upgrade, simply add it to the list. It gets downloaded the same as the rest. They could even add some predictive Swift downloading for the most popular versions of Swift to avoid unnecessary delays downloading it.
- deleted 3y ago
  [deleted]
- mort96 3y ago
  I guess the problem then is that you end up with one copy of Swift installed per Swift version that's ever released more or less, which doesn't seem ideal from a space perspective.
  - worewood 3y ago
    That's what MS does with .net and DirectX for example. Apple only needs to do this because they are charging a pornographic premium for storage.
    - dangus 3y ago
      MS does this because they aren’t in the same business as Apple. Apple is in the device business. They make most of their revenue by selling you a new device. A 10 year old Mac is basically a brick unless you want to mess with OpenCore Legacy. The solution to this problem is to target a newer OS like Apple wants you to. Their users are going to buy a new system anyway, they’re the most affluent segment of the PC market.
pseudocomposer 3y ago
As others have pointed out, there’s some tradeoffs here. One of them I’m not seeing mentioned is better forward compatibility. As a user, when Apple adds new features like built-in photo OCR, updated UI elements, better navigation patterns, etc., and I update iOS, every SwiftUI app I have gets those features without the developer doing anything.
- bsaul 3y ago
  I think i'd rather be sure my code behave like it did when i compiled it over having unexpected side effets at each os release. If all it takes to get the new features is recompile & deploy a new version of my code, i'm fine with it. The only exception is security.
  - bee_rider 3y ago
    From the user point of view, the new functionality is usually helpful.
    - bsaul 3y ago
      Sure, but the only case i see it really useful is for unmaintained apps. At which point you can be sure the app is going to break no matter what in a not distant future.
      - Linux-Fan 3y ago
        One of the major benefits of software is that you do _not_ need to re-create it if it already exists and solves your problem. An unmaintained app that solves a specific problem is never going to break by itself “in a not distant future”. Only if its environment changes so much that it cannot be run anymore (including security fixes missing in the app) does this happen. I recall a firm making good money while using their internally custom-built software for MS DOS with no way to change it whatsoever -- the software firm that wrote it was probably already long out of business, source code was not available -- and that was in 2019 which was already long past the days of MS DOS. I think it is worthwhile for OSes and other core software infrastructure to support running even unmaintained apps as much as possible because it reduces the need to rewrite (or overhaul) programs only due to a lack of maintainance for the existent one. Not caring about this is IMHO accepting to waste a huge portion of the advantages that software gives us compared to other technology (software by itself never breaks from physical defects or continuous use, does not stain, etc.).
cornholio 3y ago
I think this tight coupling between the language and the platform compromised a very promising language. Swift is one of few if not the only modern language that, at the same time, has excellent performance (due to AOT compilation and optimization, deterministic garbage collection via ARC etc.), has modern security features (algebraic nil as opposed to NULL, bounds checking etc.), and is relatively easy to learn and become productive in, perhaps on par with Python/JavaScript for the core language. I don't think there's something else in the "general purpose languages with substantial real-world use" camp that touches on those 3 points quite like Swift does. On the other hand, non-Apple developers have good reason to avoid Apple, due to the extreme anti-competitive behavior. It's the C# story all over again.
- metaltyphoon 3y ago
  > It's the C# story all over again. At least C# has a real cross platform story for a while now.
  - pjmlp 3y ago
    Partially, you need to rely on the community for GUI stuff (Avalonia and Uno), and old Microsoft still pushes VS/Windows as the best experience, anyone else that wants a VS like experience has to buy Rider. Yes, there is VS Code, which besides being Electron based, Microsoft is quite open that will never achieve feature parity with VS.
    - wsc981 3y ago
      With regards to UI there is Microsoft’s MAUI, which I personally prefer over Avalonia. I love the single project approach of MAUI. I think Avalonia also relies on MAUI controls to some extent (I seem to recall a <UseMaui /> project setting in Avalonia projects.
      - pjmlp 3y ago
        MAUI doesn't count if "supports GNU/Linux" is part of being considered FOSS proper, and on macOS they took the shortcut of using Mac Catalyst instead of macOS UI APIs.
steve1977 3y ago
I don’t know about tech getting better every day. If I look at what Apple itself is able to do with SwiftUI, especially compared to Cocoa, for example with the Settings app or Journal (which I assume is SwiftUI, I don’t know though)… it’s kinda pathetic.
deleted 3y ago
[deleted]
callalex 3y ago
It’s also an insidious way to make perfectly good hardware obsolete. As Apple upgrades the OS, they slowly drop support for older hardware. This is usually justifiable, that’s just how OSs work for a variety of reasons. However it also means that if all apps have to target the latest OS just to get some UI features, they will quickly end up dropping support for older hardware as well. If you want a good example of this, check out the download page for Calibre, a simple app that helps to manage and convert eBooks.
- ghostpepper 3y ago
  Apple provides longer support windows than most android manufacturers. If you don’t need the latest features then there’s nothing forcing you to throw away a working device.
  - callalex 3y ago
    But there is pressure forcing you to abandon functioning hardware, that’s my whole point. Obviously nobody should expect OS updates forever, but third party software stops supporting old hardware that they would run fine on because of the way that the runtime tightly couples with the OS.
em-bee 3y ago
While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments. like javascript in the browser...

mpixel 3y ago

The tradeoff is that the app runs faster, looks better, works better -- in quite the indirect way. Now that the developers on the core part don't need to spend time on compatibility -- or, just dont want have to make the base choice of being a runtime dependency -- they can spend time on other things instead. This seems like a net negative at a glance, on the surface it means the apps are less compatible, so the second level is forced onto the older iterations, in practice, since each iteration has to worry about a lot less, the older iterations are _also_ a lot better instead. It is of no surprise to me these Apple or Apple-like systems tend to be better overall, as opposed to the other philosophy of Android. It leaks into all the levels. In the Java app, it is usual to see a deprecated warning that keeps working and it is maintained, and someone pays for that. The negative side is that there's no reason to get rid of the said dependency, either. My point is that lowering the maintenance cost of _any_ app or systems in general, leaves room for improvement in all the other areas, as long as you don't fall behind -- if you are allowed to fall behind, you can afford to, if not, the end result is better given enough time.

flohofwoe 3y ago
> It is of no surprise to me these Apple or Apple-like systems tend to be better overall This might have been true in the past, but it's been getting worse over the last decade. For instance: The new parts in macOS that are written in Swift seem to be mostly inferior to the parts they replaced (see for instance the new settings window written in SwiftUI, which UX wise is a joke compared to the old one, even though the old settings windows wasn't all that great either - case in point: try adding two DNS servers, searching for 'DNS server' only allows adding one item, then the DNS server panel closes and cannot be opened again without repeating the entire search, no idea how this mess made it through QA). If Swift is so much better than ObjC, then we should start seeing improvements as users, but that doesn't seem to happen, instead things are getting worse in new OS versions. Why is that?
- newaccount74 3y ago
  I really hope that the new version of the settings app causes enough backlash that Apple starts fixing SwiftUI on the Mac...
  - deergomoo 3y ago
    The weirdest thing about System Settings is that SwiftUI already supports much more Mac-like idioms. They deliberately chose to use the odd-looking iOS-style switches, bizarre label alignment, and weird unique controls. While also keeping the annoying limitations of the old System Preferences app, such as not being able to resize the window.
- galad87 3y ago
  The issue has got nothing to do with programming languages or UI toolkits, it's just that before there were more people with more attention to details, or now the management is so broken that there is no QA and no time to fix things.
  - flohofwoe 3y ago
    A good operating system UI framework should enforce the operating system's UX standards though and make it hard to create an UI which doesn't conform to the rules. But yeah, in the end, software quality needs to be tackled on the organizational level.
  - mpweiher 3y ago
    Really? Just at the moment that Swift and, later, SwiftUI get introduced, and entirely coincidentally, management breaks?
    - galad87 3y ago
      It's been a gradual process, looks at the Music app, how it has continuously got worse and buggier over the year, even without Swift and SwiftUI. You can't blame SwiftUI for that.

bowsamic 3y ago

I think this is a great way to slow down unconditional hype based adoption of new technologies imo, it gives time to make training materials. It’s probably why apple don’t feel the need to make good tutorials, bc they make an artificial delay between new features and actual practical use of them

tinus_hn 3y ago

I think the Log4j debacle makes it painfully clear that we simple can’t afford to trust application developers to keep bundled libraries up-to-date. Good idea, doesn’t work.

gedy 3y ago

> it also makes it non-updateable separately from the OS itself, which slows the spread of developments. Hasn't it always been this way with native desktop applications using the OS vendor's UI toolkit? What I hear some folks describe as "the old days" of Windows, Mac, etc.

Someone 3y ago
On the Mac, it was non-updateable separately from the hardware for a while (large parts of the UI toolkit shipped in ROM) :-) I think there also always was a new OS version for the new hardware, though, with the new hardware not running at all on older versions. The high speed at which computer tech improved at the time made that a bit of a smaller issue.
- duskwuff 3y ago
  > On the Mac, it was non-updateable separately from the hardware for a while (large parts of the UI toolkit shipped in ROM) :-) Apple had a mechanism (ROvr resources) to allow the system software on disk to override components from ROM.

kstenerud 3y ago

I'm surprised that Apple didn't opt for a hybrid approach. They control the OS. They also control Swift. So why not embed the Swift version that the app was built against, and then download that swift version to the user's device when they download an app that uses it. Then: - The app runs against the exact Swift version it was built against - The app size is smaller because you're no longer shipping the Swift libraries with the app - The impact on the user's device space is minimized since it only downloads each version of Swift once (to be shared by all apps that use that version), and only on demand. - If a new version of Swift comes out before an OS upgrade, simply add it to the list. It gets downloaded the same as the rest. They could even add some predictive Swift downloading for the most popular versions of Swift to avoid unnecessary delays downloading it.

deleted 3y ago
[deleted]
mort96 3y ago
I guess the problem then is that you end up with one copy of Swift installed per Swift version that's ever released more or less, which doesn't seem ideal from a space perspective.
- worewood 3y ago
  That's what MS does with .net and DirectX for example. Apple only needs to do this because they are charging a pornographic premium for storage.
  - dangus 3y ago
    MS does this because they aren’t in the same business as Apple. Apple is in the device business. They make most of their revenue by selling you a new device. A 10 year old Mac is basically a brick unless you want to mess with OpenCore Legacy. The solution to this problem is to target a newer OS like Apple wants you to. Their users are going to buy a new system anyway, they’re the most affluent segment of the PC market.

pseudocomposer 3y ago

As others have pointed out, there’s some tradeoffs here. One of them I’m not seeing mentioned is better forward compatibility. As a user, when Apple adds new features like built-in photo OCR, updated UI elements, better navigation patterns, etc., and I update iOS, every SwiftUI app I have gets those features without the developer doing anything.

bsaul 3y ago
I think i'd rather be sure my code behave like it did when i compiled it over having unexpected side effets at each os release. If all it takes to get the new features is recompile & deploy a new version of my code, i'm fine with it. The only exception is security.
- bee_rider 3y ago
  From the user point of view, the new functionality is usually helpful.
  - bsaul 3y ago
    Sure, but the only case i see it really useful is for unmaintained apps. At which point you can be sure the app is going to break no matter what in a not distant future.
    - Linux-Fan 3y ago
      One of the major benefits of software is that you do _not_ need to re-create it if it already exists and solves your problem. An unmaintained app that solves a specific problem is never going to break by itself “in a not distant future”. Only if its environment changes so much that it cannot be run anymore (including security fixes missing in the app) does this happen. I recall a firm making good money while using their internally custom-built software for MS DOS with no way to change it whatsoever -- the software firm that wrote it was probably already long out of business, source code was not available -- and that was in 2019 which was already long past the days of MS DOS. I think it is worthwhile for OSes and other core software infrastructure to support running even unmaintained apps as much as possible because it reduces the need to rewrite (or overhaul) programs only due to a lack of maintainance for the existent one. Not caring about this is IMHO accepting to waste a huge portion of the advantages that software gives us compared to other technology (software by itself never breaks from physical defects or continuous use, does not stain, etc.).

cornholio 3y ago

I think this tight coupling between the language and the platform compromised a very promising language. Swift is one of few if not the only modern language that, at the same time, has excellent performance (due to AOT compilation and optimization, deterministic garbage collection via ARC etc.), has modern security features (algebraic nil as opposed to NULL, bounds checking etc.), and is relatively easy to learn and become productive in, perhaps on par with Python/JavaScript for the core language. I don't think there's something else in the "general purpose languages with substantial real-world use" camp that touches on those 3 points quite like Swift does. On the other hand, non-Apple developers have good reason to avoid Apple, due to the extreme anti-competitive behavior. It's the C# story all over again.

metaltyphoon 3y ago
> It's the C# story all over again. At least C# has a real cross platform story for a while now.
- pjmlp 3y ago
  Partially, you need to rely on the community for GUI stuff (Avalonia and Uno), and old Microsoft still pushes VS/Windows as the best experience, anyone else that wants a VS like experience has to buy Rider. Yes, there is VS Code, which besides being Electron based, Microsoft is quite open that will never achieve feature parity with VS.
  - wsc981 3y ago
    With regards to UI there is Microsoft’s MAUI, which I personally prefer over Avalonia. I love the single project approach of MAUI. I think Avalonia also relies on MAUI controls to some extent (I seem to recall a <UseMaui /> project setting in Avalonia projects.
    - pjmlp 3y ago
      MAUI doesn't count if "supports GNU/Linux" is part of being considered FOSS proper, and on macOS they took the shortcut of using Mac Catalyst instead of macOS UI APIs.

steve1977 3y ago

I don’t know about tech getting better every day. If I look at what Apple itself is able to do with SwiftUI, especially compared to Cocoa, for example with the Settings app or Journal (which I assume is SwiftUI, I don’t know though)… it’s kinda pathetic.

deleted 3y ago

[deleted]

callalex 3y ago

It’s also an insidious way to make perfectly good hardware obsolete. As Apple upgrades the OS, they slowly drop support for older hardware. This is usually justifiable, that’s just how OSs work for a variety of reasons. However it also means that if all apps have to target the latest OS just to get some UI features, they will quickly end up dropping support for older hardware as well. If you want a good example of this, check out the download page for Calibre, a simple app that helps to manage and convert eBooks.

ghostpepper 3y ago
Apple provides longer support windows than most android manufacturers. If you don’t need the latest features then there’s nothing forcing you to throw away a working device.
- callalex 3y ago
  But there is pressure forcing you to abandon functioning hardware, that’s my whole point. Obviously nobody should expect OS updates forever, but third party software stops supporting old hardware that they would run fine on because of the way that the runtime tightly couples with the OS.

em-bee 3y ago

While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments. like javascript in the browser...