Swift 5 is really astonishing. I think that the focus is on the right things. It would be amazing to be able to write cross platform at full speed. I would also really like Swift used for embedded development. Modelling concurrency at the language level would greatly improve the readability of code and reaffirm one of Swift's core tenets "clarity at the point of use". Protocol oriented programming restrictions could be relaxed with the emphasis on existentials and making a better use of the where keyword. Standard library use can be further simplified e.g. Decodable heterogeneous arrays. The Swift ecosystem would do well by adopting functional programming libraries under it's umbrella such as Prelude. Documentation should be improved with new language features, explaining their use. I'd like to see that for SE-0267. Obviously the autocomplete speed improvement would go a long way. All of this, and much much more is what I'm looking forward to in Swift 6!
Looks like there are updates for that in this section on contextual where clauses.
As more focus is going towards a decentralized web, it makes sense to have Swift and SwiftUI ported to Android and Linux. The idea is that sites will no longer require a browser, and should be self contained applications. This will enable apps to enter a new level of ubiquity, and eventually expand the ecosystem to single app devices, similar to Watch OS (multiple apps, but really just a single app with nested packages) or the iPod nano, where only a single app is launched for that device. The future will be these specific use devices, and it would be fantastic if these neutrino devices were powered by Apple. In addition, compiling swift natively on the client will enable a whole new installation experience for apps, signed by the Apple App Store.
Rather than visiting an app in the browser, URLS, such as classify.app, will automatically install the signed Mac app, in a sandboxed state. If hardware access is required, of course permissions will be requested as is the case today. This will create seamless experiences for users who will enjoy rich, stateful, and occasionally connected, transactional, and secure apps, which only require online capabilities to synchronize data or communicate with a blockchain type, decentralized infrastructure.
I agree. Being able to easily deploy a Swift app, or at least have a decently doable workflow to deploy an Android app, will really seek to establish Swift's as a important tool in a developer's toolbelt. With this, it would mitigate a lot of qualms with picking up Swift, namely that at the moment it can only be used for the apple ecosystem. There aren't many practical ways to use Swift outside of the ecosystem. While you can make executables for Windows or make a web server, there's really no reason to go do that. This is partly because of the high cost of entrance. It's not that great of an experience, there's no IDEs or tools to help development. It feels like a bit of the wild west compared to some of the more established languages. There's little support, and the documentation as it is could use work.
Something you talk about, Cyclic, is that you see Swift as being used as always tied to Apple, but I think that Swift needs to move away from being tied so closely to Apple. I'm sure everyone is happy to have the support of Apple, but having Apple more in the background and having Swift to stand for itself would be a tremendous improvement to the appearance of the language and frameworks. Swift, SwiftUI, and other frameworks and technologies should be able to stand alone, and not need any Apple servers to run. Android apps that are made using Swift should not be signed and checked on Apple servers. If an app isn't running on Apple hardware, not using the apple app store to distribute, there is no reason to be tied to any Apple App Store signing. When Mojang develops Minecraft using Java, they don't ask Oracle to code-sign Minecraft and then check Minecraft against Oracle servers. If I make an Android app using Swift, I want to be able to distribute my app without having Apple App Store touching it.
Swift should not be a tool to expand the Apple ecosystem. It is a programming language. And a programming language is a tool to build with, much like a woodworker uses a hammer.
For "open-sourcing" SwiftUI and Combine, Iâve changed my mind after the huge Concurrency roadmap. I believe it would be easier and most time-efficient to develop the open-source version of Combine and SwiftUI with a full set of concurrency features including async-await and Actors. SwiftUI on Apple platforms may also get new set of APIs using Swiftâs concurrency (possibly after WWDC21).
Taking these into consideration, I donât think itâs the proper time for the community to work on these two projects now. We need to get all the concurrency stuff done first, and wait for SwiftUI to get mature and fit into Swiftâs development roadmap.
P.S. Considering that Swift Concurrency is largely pushed by Apple, it may be the key of a huge update to SwiftUI 3. So letâs wait and see whatâs going on in WWDC.
Sorry for resurrecting, but thought one small thing here deserved a follow-up:
Was the idea to use the working group model shelved then along the way?
Nope, just delayed in blooming. It is worth keeping in perspective that the Diversity in Swift group â which was formed in the last year â is a working group within the Swift project.
Concurrency took a huge amount of focus from the Core team this year. With the initial rollout of concurrency now converging, I'm optimistic there will be more capacity from myself and the core team to push more on the working group idea. Thank you for bringing this up.
Thanks Ted, that's super - I've appreciated reading the SSWG meeting notes and the transparency they gave (and opportunity for feedback it gives), so was just curious if it was a bandwidth problem (it seems it was) or a change of mind (it seems it wasn't). (and major kudos for the concurrency work, it is shaping up very nice indeed I think - big step on the road...)
Now that we have direction and concurrency has shipped, it's probably a good time for Apple to start looking at using webasm to package SwiftUI/Combine/Concurrency/CoreData in a node style variant.
Having a single codebase in Swift for iOS, Android, and web/web3, would really make Apple's product roadmap a much bigger story for developers as a whole. This was the vision with XAML/WPF back in 2005, but having UI on the heap really hurt WPF performance, not to mention the verbosity of XML vs. SwiftUI.
Looking forward to shipping apps that run on linux and windows. Corporations embracing decentralization is going to be an important test of resilience in the future.
And spring is here now as can be witnessed in several places now, figuratively and actually. Awesome to see, thanks - I believe itâs a great direction!
Improve how software written in Swift is installed and deployed
I hope there is something similar to rustup in the works to install Swift - a one liner or gui managment tool that installs everything toolchains, dependencies, signing certificates with a single line. Installation on non-Apple systems is unsatisfactory currently.
I agree fully! It doesn't matter if it is Linux or Windows, Swift need something like rustup at least.
AFAIK the tool is currently referred to as swiftly and you can keep an eye on this name in SSWG workgroup updates to follow its development.
Yes we (the SSWG) announced we are working on the tool, there should be some more stuff to show in the not too distant future
Good to know! Thank you for the SSWG work! VSCode extension + Vapor... and this tool now.
I started exploring Rust as an alternative to C/C++ for my cross-platform projects last year and was surprised how much easier is to setup a project with rustup + Cargo.
With Swift the part that I really don't want to have to deal with would be: installing PGP keys and signing. I hope this part becomes truly transparent even on Windows:
Are there any news about the installer tool, papers or source code published yet?
@Patrick is the design or initial work public yet?
One thing I want to bring up here is to standardize or replace some (hopefully, most) of the underscored attributes. These attributes provide some quality-of-life features so now theyâve been (improperly, I would say) used in a number of production-ready libraries.
Itâs really worrying that the Underscored Attributes Reference grows by almost 40% since it was introduced merely a year ago. This will heavily harm Swiftâs goal of source compatibility and I donât think library authors are the ones to blame.