10 ms·

Swift was always going to be part of the OS (2022)

182 points by harporoeder 3y ago

oaiey 3y ago
I find this interesting, considering that .NET went the other direction. The .NET Framework was operating system bound, while the modern .NET (Core) is a separate installation or ships with the app or is even AOTed. Maybe Apple is more aggressive in adopting Swift as their operating system language, because Microsoft always has this split that the Windows division was C++/COM and .NET did not really fit into their world.
- nrr 3y ago
  The raisons d'être between the CLR (and C#) and Swift are entirely different. Apple has explicitly set out to adopt Swift as a successor language to C, Objective-C, C++, and Objective-C++[0][1]. This stands in stark contrast to Microsoft's vision for the CLR, which was… to be a better Java, more or less? (Does anyone actually know what the .NET initiative was all about? Microsoft went absolutely ham on it in their branding, but the momentum unceremoniously fizzled out before Server 2003 went RTM.) That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact. I'm told that there is in use a System C# dialect that generates native object code via a more production grade version of Bartok[3]. 0: https://youtu.be/lgivCGdmFrw https://youtu.be/lgivCGdmFrw 1: https://developer.apple.com/swift/#:~:text=Swift%20is%20a%20successor%20to,%2C%20flow%20control%2C%20and%20operators https://developer.apple.com/swift/#:~:text=Swift%20is%20a%20.... 2: https://www.microsoft.com/en-us/research/project/singularity/ https://www.microsoft.com/en-us/research/project/singularity... 3: https://en.wikipedia.org/wiki/Bartok_(compiler) https://en.wikipedia.org/wiki/Bartok_(compiler)
  - rezonant 3y ago
    Yeah, sigh Technically the ".NET initiative" was all about web services. But not the modern kind, it was about SOAP. And I guess also Code Access Security-- a way to run untrusted (and even remote) code securely. Ahem, "securely". The .NET Framework, CIL, and CLI/CLR and it's initial languages, C# and VB.NET, were in support of those technologies, but ended up being the only parts with real staying power. I am a big fan of the .NET Framework (and it's evolution in .NET Core / .NET 5)-- so many rough edges of the Java runtime concepts and Java language concepts were polished, and a lot of new innovations were introduced (proper annotations, a framework for handling code isolation, a better reflection API, real runtime generics in .NET 2.0 and more). There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. > That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact Firstly, of course C# is used quite a lot within Windows in the user space. I worked on some open source stuff around kernel level C# that was inspired by MSR's work here-- Singularity still used a very small core written in C++ iirc, we were interested in reducing the amount of unmanaged support code as much as possible as well as replacing the unmanaged c++ bits with unmanaged c#. That work grew into SharpOS. There was also a competing project called CosmOS. Lost to time now.
    - colejohnson66 3y ago
      One of the guys who worked on Singularity's successor, Midori, has a nice multipage post-mortem write up.[0] Many design concepts have found their way into C#/.NET in the years since. However, unlike Singularity, Midori's source code was (unfortunately) never released. [0]: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
    - Kwpolska 3y ago
      > There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752 https://github.com/dotnet/sdk/issues/24752 The assembly redirection hell has also been greatly reduced there.
      - rezonant 3y ago
        Yeah I didn't think it had, but I've not done too much with Core/5+ yet. I want to use it but I end up just using Typescript/Node by default. I do need to get into the habit of investigating using CLR when a bit more performance or lower latency is required, instead of jumping past it to systems level with C++/Rust/Go.
      - mycall 3y ago
        There is something similar to the Global Assembly Cache for .NET Core. This allows WSUS to automatically upgrade the .NET runtime installed on the system. https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
        metaltyphoon 3y ago
        Thats just framework dependent upgrades. .NET core and beyond allows for side by side installations of with different assembly versions where in .NET framework they shared a GAC.
  - pjmlp 3y ago
    The original plan of .NET was also to replace everything, .NET was going to be the next COM, hence why there were still plenty of configuration settings named COM_ when the open source efforts started. Also why since day one, it was polyglot, COM was part of the stack (as next step from VB 6 and MFC/ATL), and Managed Extensions for C++ were included (later replaced by C++/CLI in .NET 2.0). The problem is that Microsoft isn't Apple, and WinDev couldn't care less about this, and stayed true to their COM/C++ tooling, similiarly when the Longhorn effort failed (mostly due to sabotage from Office/WinDev teams), Vista redid most of the .NET based ideas into COM/C++, and since Vista COM has been the main delivery mechanism for new Windows APIs (WinRT is yet another take on COM). Bartok was used on the Windows Store compiler for Windows 8.x, via MDIL linker. .NET Native on Windows 10, grew out of Project N, which was influenced by System C# used in Midori, not Singularity.
  - cpeterso 3y ago
    I heard that parts of Microsoft Edge (the pre-Chromium version) were written in a GC-free subset of C#. I don’t know if it used System C#.
NwpierratorR 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. 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?
flohofwoe 3y ago
I really wish that Apple would provide an alternative C API to its system frameworks, even if it would be inconvenient to use (similar to Microsoft's COM APIs - terrible to use directly as C API, but at least it's possible, and most importantly, the COM APIs provide a stable ABI and allow proper interface versioning - so old and new interfaces can live side by side). Language bindings could then directly go through the C API instead of having to go through an ObjC- or Swift-shim, or calling directly into the brittle ObjC runtime functions (is there even something similar to the ObjC runtime for Swift?, e.g. a C API to create Swift objects and call methods on them?).
- neonsunset 3y ago
  They do! See https://github.com/apple/swift/blob/main/docs/LibraryEvolutionManifesto.md https://github.com/apple/swift/blob/main/docs/LibraryEvoluti... You can also see an example of what a .NET integration with Swift ABI looks like here: https://github.com/dotnet/designs/blob/main/proposed/swift-interop.md https://github.com/dotnet/designs/blob/main/proposed/swift-i...
newaccount74 3y ago
In the time since this article was published, a new feature was introduced in Swift 5.8 that addresses the issue: @backDeployed [1] allows Apple to include a default implementation for a new API method that will be used when running on an older version of macOS. It only works for functions/methods, but it will allow devs to use new APIs sooner! [1]: https://www.hackingwithswift.com/swift/5.8/function-back-deployment https://www.hackingwithswift.com/swift/5.8/function-back-dep...
- ec109685 3y ago
  Seems similar to polyfills in web developer. Game changer given vagaries of browsers still.
tambourine_man 3y ago
http://webcache.googleusercontent.com/search?q=cache:https://belkadan.com/blog/2022/10/Swift-in-the-OS/ http://webcache.googleusercontent.com/search?q=cache:https:/...
wheybags 3y ago
The more time passes, the more I feel like dynamic linking of anything but plain C interfaces is just a bad idea.
- criddell 3y ago
  Would you consider using runtime things like Microsoft’s Component Object Model (COM) to be a form of dynamic linking?
  - rezonant 3y ago
    The real question is probably "Is COM a bad idea?" And I don't think it is. But COM itself was such a pain to deal with. Notably all of my time with it was spent from within .NET so maybe it was less painful in C++-- but .NET was at least partially designed to work well with COM. Insert crying emoji. (Of course I think Microsoft intended us to stop using COM and instead use SOAP, but that didn't happen)
    - alternative_a 3y ago
      SOAP is an object access protocol. COM is an component object model. How is SOAP providing a component model?
      - flohofwoe 3y ago
        The only really important and surviving part of COM isn't the "component model idea", but that COM enables versioned interfaces and dynamic linking with a stable ABI for high level languages that usually don't have a stable ABI (like C++) by defining a standard of how high level language concepts can be tunneled through a regular C API.
        pjmlp 3y ago
        Which is even overlooked is how similar ideas have been adopted in Apple and Google platforms (XPC, IO/Driver Kit, AIDL/Binder, FIDL/zircon), less so in GNU/Linux as not all distributions rely on D-BUS for similar ideas.
0x0 3y ago
The comment about code signing perhaps being a blocked for third party sdk/library deduplication doesn't seem to also consider the fairplay DRM on iOS apps. As far as I know, the code (.text) segment of all iOS app store binaries are encrypted. I don't know the details about the encryption scheme (I would assume it is perhaps uniquely encrypted keyed on the user's appleid?) but it sounds like this would be a larger problem than just code signing signatures varying between publishers (and I would assume all appstore apps are re-signed by a single apple appstore authority, although enterprise/adhoc apps probably aren't).
deleted 3y ago
[deleted]
lysecret 3y ago
I recently built a Swift app for the first time, and I was so pleasantly surprised. It's really easy to pick up, I also did zero styling or performance optimizations and it's pretty and fast. My only regret was not using SwiftData (since it was only released with IOS 17), CoreData is not that nice.
- turquoisevar 3y ago
  CoreData is indeed not a Swifty experience, if only because of all of the boilerplate necessary. Luckily SwiftData is really easy to pick up and because it’s build on top of CoreData it’s pretty easy to convert it over to SwiftData.
  - jv95 3y ago
    You can use both at the same time as well. But not all the core Data features are supported yet. I use Core Data abstractions in my app and can’t port that part over to Swift Data yet.
KingLancelot 3y ago
[dead]
ec109685 3y ago
"Because this was the very premise of Apple’s OS-based library distribution model: apps compiled for Swift 5 would work with an OS built on Swift 6; apps compiled with Swift 6 would still be able to “backwards-deploy” to an OS built on Swift 5. Without this, Apple couldn’t use Swift in its own public APIs." How is an app built on Swift 6 runnable on an OS with just Swift 5 runtime? I would have thought developers have to target the minimal Swift (and iOS version) at build time and live with the features available then.
- mayoff 3y ago
  Yes, we pick a deployment target (a lowest supported version of iOS/macOS/etc.) at build time, and we're then allowed to use language, standard library, and SDK features that are supported by that deployment target. We can also conditionally use newer features when the app runs on a newer target, using @available and #available syntax. Swift 6 will not change the ABI in an incompatible way. If Swift 6 introduces features that require runtime support, then code that uses those features will not back-deploy, but other code will. We have seen this before. For example, Swift 5.7 implemented SE-0309 (“Unlock existentials for all protocols”). Some of the new features of SE-0309 required runtime support, and if you wrote code that used those features, the program would not back-deploy. But (I think) the compiler emits an error if your deployment target doesn't ship with the Swift runtime that supports those features. The big changes in Swift 6 will be new semantic restrictions related to concurrency, and possibly a small amount of breaking changes to syntax. These changes will prevent some existing Swift 5 code from compiling in Swift 6 mode. That is the reason the major version number will change.
nox100 3y ago
Go's creator still uses and promotes Go. Python's creator still uses Python. C++'s creator still uses and promotes C++. Java's creator still uses and promotes Java. But Swift's creator no longer uses Swift AFAICT. Why?
- onegived 3y ago
  He is developing Mojo now, so i guess he has no reason to use it now. Also perhaps developing a new language is an admission that the S4TF was a failed effort.
- pohl 3y ago
  Did he ever use it much? It’s not self-hosting yet, so he’d be more a user of C++ than he was of Swift.
nektro 3y ago
and this is one area where linux distros with its package managers really shines and totally beats all the competition

182 points by harporoeder 3y ago

I find this interesting, considering that .NET went the other direction. The .NET Framework was operating system bound, while the modern .NET (Core) is a separate installation or ships with the app or is even AOTed. Maybe Apple is more aggressive in adopting Swift as their operating system language, because Microsoft always has this split that the Windows division was C++/COM and .NET did not really fit into their world.

nrr 3y ago
The raisons d'être between the CLR (and C#) and Swift are entirely different. Apple has explicitly set out to adopt Swift as a successor language to C, Objective-C, C++, and Objective-C++[0][1]. This stands in stark contrast to Microsoft's vision for the CLR, which was… to be a better Java, more or less? (Does anyone actually know what the .NET initiative was all about? Microsoft went absolutely ham on it in their branding, but the momentum unceremoniously fizzled out before Server 2003 went RTM.) That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact. I'm told that there is in use a System C# dialect that generates native object code via a more production grade version of Bartok[3]. 0: https://youtu.be/lgivCGdmFrw https://youtu.be/lgivCGdmFrw 1: https://developer.apple.com/swift/#:~:text=Swift%20is%20a%20successor%20to,%2C%20flow%20control%2C%20and%20operators https://developer.apple.com/swift/#:~:text=Swift%20is%20a%20.... 2: https://www.microsoft.com/en-us/research/project/singularity/ https://www.microsoft.com/en-us/research/project/singularity... 3: https://en.wikipedia.org/wiki/Bartok_(compiler) https://en.wikipedia.org/wiki/Bartok_(compiler)
- rezonant 3y ago
  Yeah, sigh Technically the ".NET initiative" was all about web services. But not the modern kind, it was about SOAP. And I guess also Code Access Security-- a way to run untrusted (and even remote) code securely. Ahem, "securely". The .NET Framework, CIL, and CLI/CLR and it's initial languages, C# and VB.NET, were in support of those technologies, but ended up being the only parts with real staying power. I am a big fan of the .NET Framework (and it's evolution in .NET Core / .NET 5)-- so many rough edges of the Java runtime concepts and Java language concepts were polished, and a lot of new innovations were introduced (proper annotations, a framework for handling code isolation, a better reflection API, real runtime generics in .NET 2.0 and more). There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. > That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact Firstly, of course C# is used quite a lot within Windows in the user space. I worked on some open source stuff around kernel level C# that was inspired by MSR's work here-- Singularity still used a very small core written in C++ iirc, we were interested in reducing the amount of unmanaged support code as much as possible as well as replacing the unmanaged c++ bits with unmanaged c#. That work grew into SharpOS. There was also a competing project called CosmOS. Lost to time now.
  - colejohnson66 3y ago
    One of the guys who worked on Singularity's successor, Midori, has a nice multipage post-mortem write up.[0] Many design concepts have found their way into C#/.NET in the years since. However, unlike Singularity, Midori's source code was (unfortunately) never released. [0]: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
  - Kwpolska 3y ago
    > There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752 https://github.com/dotnet/sdk/issues/24752 The assembly redirection hell has also been greatly reduced there.
    - rezonant 3y ago
      Yeah I didn't think it had, but I've not done too much with Core/5+ yet. I want to use it but I end up just using Typescript/Node by default. I do need to get into the habit of investigating using CLR when a bit more performance or lower latency is required, instead of jumping past it to systems level with C++/Rust/Go.
    - mycall 3y ago
      There is something similar to the Global Assembly Cache for .NET Core. This allows WSUS to automatically upgrade the .NET runtime installed on the system. https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
      - metaltyphoon 3y ago
        Thats just framework dependent upgrades. .NET core and beyond allows for side by side installations of with different assembly versions where in .NET framework they shared a GAC.
- pjmlp 3y ago
  The original plan of .NET was also to replace everything, .NET was going to be the next COM, hence why there were still plenty of configuration settings named COM_ when the open source efforts started. Also why since day one, it was polyglot, COM was part of the stack (as next step from VB 6 and MFC/ATL), and Managed Extensions for C++ were included (later replaced by C++/CLI in .NET 2.0). The problem is that Microsoft isn't Apple, and WinDev couldn't care less about this, and stayed true to their COM/C++ tooling, similiarly when the Longhorn effort failed (mostly due to sabotage from Office/WinDev teams), Vista redid most of the .NET based ideas into COM/C++, and since Vista COM has been the main delivery mechanism for new Windows APIs (WinRT is yet another take on COM). Bartok was used on the Windows Store compiler for Windows 8.x, via MDIL linker. .NET Native on Windows 10, grew out of Project N, which was influenced by System C# used in Midori, not Singularity.
- cpeterso 3y ago
  I heard that parts of Microsoft Edge (the pre-Chromium version) were written in a GC-free subset of C#. I don’t know if it used System C#.

NwpierratorR 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. 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?

flohofwoe 3y ago

I really wish that Apple would provide an alternative C API to its system frameworks, even if it would be inconvenient to use (similar to Microsoft's COM APIs - terrible to use directly as C API, but at least it's possible, and most importantly, the COM APIs provide a stable ABI and allow proper interface versioning - so old and new interfaces can live side by side). Language bindings could then directly go through the C API instead of having to go through an ObjC- or Swift-shim, or calling directly into the brittle ObjC runtime functions (is there even something similar to the ObjC runtime for Swift?, e.g. a C API to create Swift objects and call methods on them?).

neonsunset 3y ago
They do! See https://github.com/apple/swift/blob/main/docs/LibraryEvolutionManifesto.md https://github.com/apple/swift/blob/main/docs/LibraryEvoluti... You can also see an example of what a .NET integration with Swift ABI looks like here: https://github.com/dotnet/designs/blob/main/proposed/swift-interop.md https://github.com/dotnet/designs/blob/main/proposed/swift-i...

newaccount74 3y ago

In the time since this article was published, a new feature was introduced in Swift 5.8 that addresses the issue: @backDeployed [1] allows Apple to include a default implementation for a new API method that will be used when running on an older version of macOS. It only works for functions/methods, but it will allow devs to use new APIs sooner! [1]: https://www.hackingwithswift.com/swift/5.8/function-back-deployment https://www.hackingwithswift.com/swift/5.8/function-back-dep...

ec109685 3y ago
Seems similar to polyfills in web developer. Game changer given vagaries of browsers still.

tambourine_man 3y ago

http://webcache.googleusercontent.com/search?q=cache:https://belkadan.com/blog/2022/10/Swift-in-the-OS/ http://webcache.googleusercontent.com/search?q=cache:https:/...

wheybags 3y ago

The more time passes, the more I feel like dynamic linking of anything but plain C interfaces is just a bad idea.

criddell 3y ago
Would you consider using runtime things like Microsoft’s Component Object Model (COM) to be a form of dynamic linking?
- rezonant 3y ago
  The real question is probably "Is COM a bad idea?" And I don't think it is. But COM itself was such a pain to deal with. Notably all of my time with it was spent from within .NET so maybe it was less painful in C++-- but .NET was at least partially designed to work well with COM. Insert crying emoji. (Of course I think Microsoft intended us to stop using COM and instead use SOAP, but that didn't happen)
  - alternative_a 3y ago
    SOAP is an object access protocol. COM is an component object model. How is SOAP providing a component model?
    - flohofwoe 3y ago
      The only really important and surviving part of COM isn't the "component model idea", but that COM enables versioned interfaces and dynamic linking with a stable ABI for high level languages that usually don't have a stable ABI (like C++) by defining a standard of how high level language concepts can be tunneled through a regular C API.
      - pjmlp 3y ago
        Which is even overlooked is how similar ideas have been adopted in Apple and Google platforms (XPC, IO/Driver Kit, AIDL/Binder, FIDL/zircon), less so in GNU/Linux as not all distributions rely on D-BUS for similar ideas.

0x0 3y ago

The comment about code signing perhaps being a blocked for third party sdk/library deduplication doesn't seem to also consider the fairplay DRM on iOS apps. As far as I know, the code (.text) segment of all iOS app store binaries are encrypted. I don't know the details about the encryption scheme (I would assume it is perhaps uniquely encrypted keyed on the user's appleid?) but it sounds like this would be a larger problem than just code signing signatures varying between publishers (and I would assume all appstore apps are re-signed by a single apple appstore authority, although enterprise/adhoc apps probably aren't).

deleted 3y ago

[deleted]

lysecret 3y ago

I recently built a Swift app for the first time, and I was so pleasantly surprised. It's really easy to pick up, I also did zero styling or performance optimizations and it's pretty and fast. My only regret was not using SwiftData (since it was only released with IOS 17), CoreData is not that nice.

turquoisevar 3y ago
CoreData is indeed not a Swifty experience, if only because of all of the boilerplate necessary. Luckily SwiftData is really easy to pick up and because it’s build on top of CoreData it’s pretty easy to convert it over to SwiftData.
- jv95 3y ago
  You can use both at the same time as well. But not all the core Data features are supported yet. I use Core Data abstractions in my app and can’t port that part over to Swift Data yet.

KingLancelot 3y ago

[dead]

ec109685 3y ago

"Because this was the very premise of Apple’s OS-based library distribution model: apps compiled for Swift 5 would work with an OS built on Swift 6; apps compiled with Swift 6 would still be able to “backwards-deploy” to an OS built on Swift 5. Without this, Apple couldn’t use Swift in its own public APIs." How is an app built on Swift 6 runnable on an OS with just Swift 5 runtime? I would have thought developers have to target the minimal Swift (and iOS version) at build time and live with the features available then.

mayoff 3y ago
Yes, we pick a deployment target (a lowest supported version of iOS/macOS/etc.) at build time, and we're then allowed to use language, standard library, and SDK features that are supported by that deployment target. We can also conditionally use newer features when the app runs on a newer target, using @available and #available syntax. Swift 6 will not change the ABI in an incompatible way. If Swift 6 introduces features that require runtime support, then code that uses those features will not back-deploy, but other code will. We have seen this before. For example, Swift 5.7 implemented SE-0309 (“Unlock existentials for all protocols”). Some of the new features of SE-0309 required runtime support, and if you wrote code that used those features, the program would not back-deploy. But (I think) the compiler emits an error if your deployment target doesn't ship with the Swift runtime that supports those features. The big changes in Swift 6 will be new semantic restrictions related to concurrency, and possibly a small amount of breaking changes to syntax. These changes will prevent some existing Swift 5 code from compiling in Swift 6 mode. That is the reason the major version number will change.

nox100 3y ago

Go's creator still uses and promotes Go. Python's creator still uses Python. C++'s creator still uses and promotes C++. Java's creator still uses and promotes Java. But Swift's creator no longer uses Swift AFAICT. Why?

onegived 3y ago
He is developing Mojo now, so i guess he has no reason to use it now. Also perhaps developing a new language is an admission that the S4TF was a failed effort.
pohl 3y ago
Did he ever use it much? It’s not self-hosting yet, so he’d be more a user of C++ than he was of Swift.

nektro 3y ago

and this is one area where linux distros with its package managers really shines and totally beats all the competition