News for hackers. Stuff that matters.
Re:The Next Chapter in Swift Build Technologies by JTyQZSnP3cQGa8B on Saturday February 01, 2025 @02:51PM (#42901558)
This has been my experience for a long time. Swift is nice but why would I waste my time working on a language that is too tied to the Apple platform even if it's open-source when we have more universal scripting languages like Python, or languages like Kotlin that are compiled but have more support (because I trust JetBrains way more than Apple at the moment), or languages that are most strict like Rust but have more momentum and safety?

They painted themselves in a corner. Apple being the best computing platform while trying to please everyone can never be a serious proposition. Either they are the best and everyone uses macOS, or we have to be so careful that any alternative is more interesting that what they propose.

Re:The Next Chapter in Swift Build Technologies by kelnos on Saturday February 01, 2025 @03:56PM (#42902203)
> Either they are the best and everyone uses macOS

"Best" obviously means different things to different people, but at least by market share, macOS has never been the best. Modern Apple doesn't seem to care about market share outside of the iPhone (and even then, they are still more interested in the iPhone being a premium product than winning on market share).

I used to like macOS, 15-20 years ago, but now it's just power-user-hostile and considerably more locked down and buggy. That's not the way to be "best", by any metric I can think of.

Re:The Next Chapter in Swift Build Technologies by philistine on Saturday February 01, 2025 @04:46PM (#42902698)
> but now it's just power-user-hostile and considerably more locked down and buggy.

Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.

Re:The Next Chapter in Swift Build Technologies by makeitdouble on Saturday February 01, 2025 @07:05PM (#42903957)
They're also hitting the classic "strategy tax"

When Apple secured the OS from third party, they also purposefully closed the door on deeper third party integration to privilege their ecosystem.

macOS only being half as useful for Android users makes it harder to be the "best" for that swath of users. iPadOS being the only tablet form in the ecosystem will also distance other users etc. They just can't please everyone while locking them in a limited ecosystem.

Re:The Next Chapter in Swift Build Technologies by YmiYugy on Saturday February 01, 2025 @05:13PM (#42902955)
Mac OS does some amazing things for security. An immutable root OS, sandboxing, very user friendly disk encryption. But there are certainly decisions that hold back the platform. Their business decisions have driven most developers away from the App Store. There is a notarization process, but it imposes a burden that many small open source projects can not bear. They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox). Installing things globally via homebrew or a random install script is still the way to go.
Re:The Next Chapter in Swift Build Technologies by philistine on Saturday February 01, 2025 @06:04PM (#42903428)
> Their business decisions have driven most developers away from the App Store.

> They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox).

The App Store is the way to run untrusted apps in a containerized way.

Re:The Next Chapter in Swift Build Technologies by fcantournet on Saturday February 01, 2025 @06:32PM (#42903699)
It's "the way" that apple wanted it to be, but it's not the way that humans have chosen.

Typically not a great idea to be against humans, especially the ones that give you money.

Re:The Next Chapter in Swift Build Technologies by ChrisMarshallNY on Saturday February 01, 2025 @09:48PM (#42905213)
> especially the ones that give you money

Last time I checked, their market cap was North of $3T, so someone is giving them money…

Re:The Next Chapter in Swift Build Technologies by chipotle_coyote on Saturday February 01, 2025 @11:05PM (#42905715)
I think if your app is on the App Store, it's kind of trusted by definition, isn't it?
Re:The Next Chapter in Swift Build Technologies by virgil_disgr4ce on Saturday February 01, 2025 @04:48PM (#42902717)
> now it's just power-user-hostile and considerably more locked down and buggy

Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?

Re:The Next Chapter in Swift Build Technologies by pmarreck on Saturday February 01, 2025 @11:10PM (#42905740)
Secure Enclave, having to use only signed apps and kernel extensions, stuff like that I imagine.
Re:The Next Chapter in Swift Build Technologies by thih9 on Saturday February 01, 2025 @03:11PM (#42901756)
> why would I waste my time working on a language that is too tied to the Apple platform

This might work the other way round: starting from people familiar with macos or ios development who want to write for other platforms.

Then the question becomes: why would a developer learn a different open source language when they can use what they already know. And sure, depending on the context they might still go with Python/Kotlin/Rust/etc.

Re:The Next Chapter in Swift Build Technologies by hu3 on Saturday February 01, 2025 @05:27PM (#42903096)
> people familiar with macos or ios development who want to write for other platforms.

This is a rather small userbase when it comes to enterprise.

Especially because Swift will never be as versatile as Python or as efficient as Rust.

And then there's also Go, C# and Kotlin with much better tooling.

Re:The Next Chapter in Swift Build Technologies by privacyis1mp on Saturday February 01, 2025 @06:13PM (#42903527)
Xcode gives me such a hard time that I started considering writing in Kotlin for macOS, just to have a normal IDE. We used to have AppCode (from JetBrains) and it was great. I wonder why Apple didn't support JetBrains, after all, it would have been to Apple's benefit.
Re:The Next Chapter in Swift Build Technologies by ChrisMarshallNY on Saturday February 01, 2025 @09:45PM (#42905182)
Personally, I never liked AppCode. It was too much like Eclipse (which I also never liked).

Me not liking something, does not make it bad. It’s just not my choice. I’m glad it existed, because it probably prompted Apple to do better with Xcode. Lots of people that I respect, used it.

These days, Xcode is Big Bug Ranch. When “Delete the DerivedData folder” is S. O. P. for developers, and Apple tweaked Xcode to reduce its impact on the project, you know that they have waved a white flag to bugs.

Re:The Next Chapter in Swift Build Technologies by joseda-hg on Saturday February 01, 2025 @10:08PM (#42905358)
There's even history of it working before, with Google / Kotlin
Re:The Next Chapter in Swift Build Technologies by pjmlp on Sunday February 02, 2025 @01:58AM (#42906666)
Since Apple has moved themselves out of the server market, folks need to at least be able to target BSD/Linux server workloads, and naturally using Swift as well instead of another language is a desired option.
Re:The Next Chapter in Swift Build Technologies by makeitdouble on Saturday February 01, 2025 @06:53PM (#42903873)
That crowd has the disadvantage of not being primarily interested in the other platforms, so they won't be much invested in optimizing or better matching the target capabilities.

That's the same dynamic as web devs writing React Native apps: you won't expect them to contribute extensions that manipulate local apfs metadata for instance.

So while it's nice to have them use the tools, you still need people who primarily care for non Apple platform and embrance swift for their purpose to have it expand.

Re:The Next Chapter in Swift Build Technologies by qaq on Saturday February 01, 2025 @07:50PM (#42904311)
Hmm Snowflake and Apple are rewriting FoundationDB in Swift. Swift has pretty good dev. ergonomics and good interop with C/C++ so it might find it's niche outside of Apple.
Re:The Next Chapter in Swift Build Technologies by pjmlp on Sunday February 02, 2025 @01:56AM (#42906657)
That crowd needs other platforms when using servers, as Apple has moved itself out of the server market, so at very least BSD/Linux workloads.
Re:The Next Chapter in Swift Build Technologies by cosmic_cheese on Saturday February 01, 2025 @03:13PM (#42901778)
Can only speak for myself, but I’d love to be able to use Swift elsewhere so I don’t need to drag around a JVM and all the things that come with it (Kotlin) or have to wrestle with Rust’s sematics and disinclination towards old style imperative desktop UI development. Swift isn't perfect of course, but it’s the closest I’ve come to a language feeling “comfy”.
Re:The Next Chapter in Swift Build Technologies by desiderantes on Saturday February 01, 2025 @05:30PM (#42903117)
So you haven't heard of Kotlin Multiplatform.
Re:The Next Chapter in Swift Build Technologies by cosmic_cheese on Saturday February 01, 2025 @06:28PM (#42903658)
Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.

Kotlin’s syntax is also weird/quirky in some ways.

Re:The Next Chapter in Swift Build Technologies by bartekpacia on Saturday February 01, 2025 @07:10PM (#42904004)
> Kotlin’s syntax is also weird/quirky in some ways.

I'm curious to learn what you mean by this! :)

Re:The Next Chapter in Swift Build Technologies by cosmic_cheese on Saturday February 01, 2025 @08:19PM (#42904570)
No terenary if and the elvis operator, for one. Stuff like that trips me up frequently when jumping between Kotlin and Swift/other C-likes.
Re:The Next Chapter in Swift Build Technologies by koakuma-chan on Saturday February 01, 2025 @08:35PM (#42904698)
Re:The Next Chapter in Swift Build Technologies by bartekpacia on Saturday February 01, 2025 @09:47PM (#42905204)
Ah, I see. Tbh, I actually like the lack of ternary and elvis, they are nicely handled by if expression (as the other comment notes)
Re:The Next Chapter in Swift Build Technologies by privacyis1mp on Saturday February 01, 2025 @06:15PM (#42903541)
What are your experiences of using Kotlin for modern macOS/iOS development? How's the support looking when Apple releases new XCode?
Re:The Next Chapter in Swift Build Technologies by aalimov_ on Sunday February 02, 2025 @03:35AM (#42907158)
Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).
Re:The Next Chapter in Swift Build Technologies by mdhb on Sunday February 02, 2025 @01:02PM (#42910372)
Or Dart
Re:The Next Chapter in Swift Build Technologies by pjmlp on Sunday February 02, 2025 @01:59AM (#42906669)
You mean like the huge ecosystem of libraries for almost anything one can thing of, and IDE tooling, with 30 years of experience in production?
Re:The Next Chapter in Swift Build Technologies by rnikander on Monday February 03, 2025 @09:55PM (#42927160)
I was using Swift before. Currently learning Rust. Want to use it for cross-platform UI, and I'm stuggling with exactly what you describe there.
Re:The Next Chapter in Swift Build Technologies by wahnfrieden on Saturday February 01, 2025 @03:55PM (#42902195)
See https://skip.tools for a new entrant
Re:The Next Chapter in Swift Build Technologies by GeekyBear on Saturday February 01, 2025 @05:04PM (#42902864)
> languages that are most strict like Rust but have more momentum and safety?

Like Rust, Swift is a compiled language that offers memory safety by default.

The creator of Clang and LLVM also created Swift, and interoperability with C was an explicit design goal.

So Swift offers the memory safety and data race safety of Rust, in a compiled language, without giving up tight integration with C.

(To be fair, better C integration is something the Rust community is looking to add.)

Re:The Next Chapter in Swift Build Technologies by myko on Saturday February 01, 2025 @06:20PM (#42903601)
fwiw Swift still doesn't support mixed-language targets so the interop is somewhat less useful to me than I'd like: https://forums.swift.org/t/se-0403-package-manager-mixed-lan...
Re:The Next Chapter in Swift Build Technologies by marxisttemp on Saturday February 01, 2025 @10:09PM (#42905359)
The creator of Rust also briefly worked on Swift
Re:The Next Chapter in Swift Build Technologies by pmarreck on Saturday February 01, 2025 @11:06PM (#42905718)
Python is not compiled, it is interpreted, and it has many warts.

Kotlin depends on the JVM and is also not compiled.

Rust? Now you're talking. Except that it has warts, too.

Re:The Next Chapter in Swift Build Technologies by zoot64 on Sunday February 02, 2025 @01:46AM (#42906587)
Kotlin is compiled in the sense that it compiles down to bytecode read by the JVM. It's not machine code level but it is still compiled to a certain degree. And Kotlin can compile natively for multiple targets including macOS and iOS without need for the JVM. There's also WASM support too.
Re:The Next Chapter in Swift Build Technologies by pmarreck on Sunday February 02, 2025 @07:47PM (#42913578)
Did not know about non-JVM compilation. Does it include the JVM as part of the binary then? Links?
Re:The Next Chapter in Swift Build Technologies by DidYaWipe on Sunday February 02, 2025 @03:10AM (#42907045)
The Python ecosystem is a sad mess.