A different vision for swift.org

Imagine you go to the homepage of your favorite source for Apple developer news, os26Insider, and above the fold here's all you see:

os26Insider is the up to date, best researched, authentic source of os26 news and information.

Below that is a subscribe button.

Across the top are categories: "New Technologies", "Liquid Glass", "iOS", "iPadOS", "macOS", "watchOS", and "tvOS" with links to pages with more information, stories, and further links.

You'd never click through.

When you visit actual sites such as Apple Insider or MacRumors you are able to scan the latest stories and decide whether to click to learn more. Each of these stories also includes links to other stories you might be interested in.

Each of the sites also contain links to various aggregate pages and specific themes - but the home page is vibrant and engaging and contains items that may or may not interest you. Without clicking or navigating, you generally get what you came for.

Contrast this with the swift.org homepage.

I am not criticizing the work and vision of the people who built the site - but I helped build and run a site for a programming language and it was very successful.

One of Apple's biggest challenges is that Swift is seen as an Apple language for Apple platforms.

Swift is more than that but Apple needs to make some changes if it wants to change this perception.

I would argue that Apple has been a great steward of Swift and is bringing the language to other platforms and doing great things with the language.

The swift.org web site must reflect this. Adding Linux and Windows references to the home page isn't enough. In addition, Apple marketing can't be any where near the website. There needs to be an independent editorial team that is responsible for the home page.

Here's what I'd like to see on a front page that is refreshed many times a week to highlight that Swift is part of a vibrant ecosystem.

At the top there would still be links to "Getting Started", "Install", and perhaps some or all of the existing links. The body of the site would include some subset of the following (different days might include different items).

(1) A curated list of excerpts from active Forum discussions. The forums are excellent but many people aren't following them, don't have the bandwidth to follow them, or are following just the threads that interest them. This would be a chance for people to glance over recent posts and decide that maybe a thread they didn't even know existed is something they are interested in.

(2) A featured Swift Package that updates once or twice a week. The Swift Package Index is amazing, but again many people don't know to visit it. There might be a Swift Package that they see on the homepage that gets them more interested in this resource.

(3) Future directions that highlights Swift Evolution proposals, pre-proposals, and vision documents. We're so busy that new proposals go by so fast and we don't notice weak let, inline arrays, or the updates to observation.

(4) News items from the world of Swift. An article on some aspect of the language, a new book, a relevant conference, a video, ... there are always things happening. This is another reason Apple can't own this page and apple marketing can't be anywhere near this page. The links are not sanctioning or approving the content - they're just pointing to it and making sure people understand Swift is a vibrant language with innovation happening in so many places.

(5) Recent Swift.org blog posts (we'd also build a calendar so there are more of them).

(6) A daily quick note from the editor highlighting something new on the site each day.

(7) Commissioned articles on topics

(8) Searchable archives of previous homepages.

(9) A swift.org podcast which includes quick interviews with core team members and community members about recent and upcoming changes in Swift and how it might impact them. For instance a quick conversation with Holly Borla on her vision for Swift Concurrency and/or a conversation with Matt Massicote on top questions he fields from the community on concurrency adoption.

(10) Notes for Newbies and for those on the cutting edge who want to install toolchains or peak behind feature flags.

(11) Swift snippets could be quick 1-2 minute video showing code before and after we make a small change to incorporate a Swift feature many might not yet be using.

(12) Perhaps some coding challenge with a link to a page with a live playground environment like our own programming equivalent of a wordle or mini crossword.

So many of us are in our own little corner of Swift and may not know about embedded Swift or Swift on the Server. This page is a daily launch page for Swift. It is mainly links to existing content but it can be a great service to the community.

I'm not sure if it's at all possible as the site would be expensive to run and would require a financial commitment from Apple without allowing them editorial oversight or control.

In any case, I wanted to share a vision for a different sort of swift.org. The full post is [here](https://dimsumthinking.com/Blog/2025/06/20-SwiftDotOrg.html).

28 Likes

I'm very much in agreement with this! I also want to emphasize the Swift Evolution portion, that's been extremely hard to digest for many folks. We could provide a TL;DR of these proposals on swift.org as a highlight of what's to come. All of this is extremely good input.

8 Likes

Yeah, I love those ideas!

@Daniel_Steinberg, thank you for this post, your suggestions, feedback, and insights.

In addition to the website redesign project, there is also an ongoing Swift information architecture project running in parallel. (Project Announcement)

Since, the information space of the Swift project is so large, including everything from getting started, documentation, packages, governance, to nitty gritty details of contributing to each of dozens of projects, a follow-on document describing a High-Level Information Architecture divides the information space into more manageable focus areas.

One of the focus areas called out in the high-level architecture is Blog / News:

This focus areas seems very much in line with many of your suggestions.

The Community Participation section of the original project announcement describes different ways members of the community can participate in the information architecture project, including joining the project team.

Joining the project team gives community members a chance to shape proposals before they are presented to the entire community for review and feedback.

Anyone from the community is welcome to join (details here: Community Participation).

Another way for the community to participate is to review and provide feedback in the forums, as you have done here.

As I think we have seen through the Swift Evolution process, having the community review and provide feedback improves the end result by hearing different perspectives and thoughts.

I do encourage you and anyone else in the community with an interest to join us in the information architecture project.

Your feedback in this post is very valuable (as is everyone's). Even if you choose not to work on the project directly, I hope you are able to review and provide feedback on information architecture proposals as they are released in coming months.

13 Likes

Thanks for your vision. I have to say I don’t like this kind of exposition you propose that try to offer something to every one in a one page but which is rarely user friendly for newbies arriving in.

I really appreciated the new home page. Clear. Proposing the essence. Minimal.
I discovered 2 importants info I ignored in 2 minutes.

1 Like

Perhaps it would help to compare the official websites for Rust, Go, and Kotlin:

They have some elements in common (and elements in common with swift.org) but are also wildly different from each other.

1 Like

Wildly different how exactly? All three make a brief case for why you should use the language, just as the new Swift front page does.

Thanks for linking the three front pages, looked at all three, as I had not done so in ages.

One striking difference is that two of the three prominently call out their main corporate sponsor, with the first bullet point about Go saying "supported by Google" and Kotlin saying "Developed by JETBRAINS" just below the big install button. Only Rust doesn't do this, instead providing a big link to their corporate sponsors and foundation members near the bottom.

Also, both Go and Kotlin plaster the page with a bunch of corporate logos linking to examples of companies using their language.

I didn't think much of the Swift front page not having any prominent corporate names like this when the new page was unveiled- the only exception is a small "Copyright © 2025 Apple Inc..." at the very bottom- but I suspect it was a mistake not to do so.

I think the reason they all do this is to reassure prospective users that the language isn't going away and that there is plenty of corporate demand for those adept with that language. We all know this to be true for Swift too, but many newbies arriving to the front page will not: I think we should add a similar note about Apple's backing.

Also, rather than plastering the front page with corporate logos, I'd add three logo tiles with prominent companies and usecases, that we could perhaps rotate in time.

My suggestions would be:

  1. One tile with The Browser Company logo, who have heavily contributed to the Windows and Android ports, mentioning that and linking to one of their Windows substack posts.
  2. One tile with a Swift on Server company, maybe @sebsto can get AWS to sign off on using their logo?
  3. One tile with the Apple logo, talking about their shipping embedded Swift on millions of trusted enclave processors and linking to more info.

Personally, I like a front page as it is now, more focused on functionality than showcasing corporate involvement, but I suspect I'm in a very small minority in that regard, and I have to admit knowing that some large entity like Apple was heavily backing Swift was perhaps the key factor in my deciding to use it.

2 Likes

They all deliver the same message, but the design language each site uses is distinct and the content on each language's landing page differs (and is arranged differently.)

Anyway—my point is just to introduce these websites so folks can compare and contrast. I take no moral position.

1 Like

I’ve also recently looked into two other languages: Gleam and OCaml.

What I like is how both display code examples and guide you to try the code directly in a web playground.

Also these two languages take slightly different approaches when it comes to sponsorship.

OCaml uses the classic “Trusted by Industry Leaders” model—which I think is good reassuring phrase.
Gleam, on the other hand, being a smaller project, leans toward a friendlier approach by highlighting its community.

2 Likes