Relaunching the Swiftinit documentation index

Community Showcase
1

hi all!

for those who aren’t aware, we were forced to take the Swiftinit documentation index offline around Fall 2025 for lack of funding. in the weeks since, i have been fielding many inquiries about the future of the site, and i was actually quite surprised by the number of people who reached out saying they had been relying on the site to navigate the Swift package ecosystem, and expressing dismay that the site was no longer available.

today i am thrilled to announce that several organizations have stepped up and agreed to contribute to the site’s hosting costs, which will allow us to bring the servers back online and re-enable the browsing of package documentation on swiftinit.org! these generous sponsors are:

and we are incredibly grateful for their support!

the world today is, for better or for worse, quite different than it was in 2022, when Swiftinit was first launched. hardware requirements for compiling the median Swift package have risen considerably as the Swift toolchain has matured, and the emergence of agentic AI and AI-powered scraping have fundamentally altered the security landscape of the public internet, which necessitates some changes to the operation of the Swiftinit website.

in particular, we will, moving forward, be restricting the documentation index to logged-in users only. this means that in order to browse API documentation on Swiftinit, it will become required to authenticate with GitHub SSO. we recognize that this presents an inconvenience, but we feel it is the only option available to us given the enormous crawl surface of the website and persistent problems we have had with scrapers disregarding robots.txt and pulling down millions of pages of API documentation, largely from obscure packages and the site’s historical documentation archive. restricting the site to logged-in users only allows us to keep the documentation available for human developers to browse, without worrying about gray-zone actors constantly crashing the site vacuuming data for SEO research or market sentiment analysis.

as a reminder, Swiftinit’s GitHub SSO requests only the minimum public profile information to verify you’re a human, and will not sign you up for any email lists.

we will also be sunsetting on-demand Swiftinit-hosted documentation builds. although we recognize that instant builds are a valuable feature for a subset of publishers, the memory requirements of modern Swift toolchains have risen over time, which means a great many Swift packages are no longer buildable on runners with 1–2 GB of RAM today. although we could attempt to raise additional funding to rent larger runners, it is the nature of on-demand CI that these runners would be idle for almost the entirety of their uptime, so AWS’s billing structure makes this an extraordinarily inefficient service for us to provide. thus, we will likely be transitioning to a “rolling updates” model where the index provides larger runners with more RAM that only come online periodically, and build Swift packages in batches, which is a far more economical architecture.

while we expect that this will increase the time between when a release is tagged to when documentation appears on the site, moving to a rolling build model will at the same time enable us to start building packages that we previously couldn’t build docs for at all due to memory constraints.

although these changes are not ideal, we feel it strikes the right balance between making the documentation available for developers to browse, and cutting down spending on wasted compute credits.

i would like to close out this announcement by again thanking our generous sponsors for making this possible at all! Swift’s ecosystem and extension-based API model presents unique challenges for developers searching and browsing API documentation, and i hope Swiftinit continues to provide you a valuable service in the years to come.

Diana :sparkling_heart:

23 Likes
2

Frabjous Day! I'm so happy to see this resource returning and getting real support from the community.

2 Likes
3

What’s the way to report bugs or give feedback? I have a bug in use of a 6.3 feature in hummingbird

4

i would file a GitHub issue on the Unidoc repo for that

5

What is “the Swiftinit documentation index”?

Currently, the homepage (index) of that your domain just redirects to the login screen. Perhaps adding some information on that screen would be useful?

2 Likes
6

unfortunately, querying the home page also runs a database query, which is why it was gated to logged-in users as well.

we could enable Cloudflare caching for the homepage, but that would make the build system very annoying to debug, as there is currently no way observe the build queue except by watching the home page. we could cache only the database query result, but that would not solve the problem of apex node saturation, which has historically been the most common mode of failure for Swiftinit. the way most large web services solve this issue is by load balancing across multiple apex nodes, but that’s a much more expensive setup.

7

You still haven’t answered the question. :joy:

I have no idea why I’d want to log in to your service, since I don’t know what it is or does.

3 Likes
8

you raise a good point, and these would be interesting technical problems to solve if i ever get an opportunity to start working on Swiftinit full time again.

for now, requiring login is a low-complexity, common sense stopgap that allows us to start serving documentation again to the small group of Swift developers who missed the previous iteration of the site and felt that it was worth resurrecting in a limited, gated form. if you’re not satisfied with the current tradeoff we’ve chosen, you free to simply not use the site and pretend it doesn’t exist, which was the status quo before we were able to secure the financial commitments needed to bring the site back online at all.

1 Like
9

I’ll answer: It’s a documentation index that compiles your libraries, and builds cross references between symbols used. So if you have a package, like “SomeSDK” that you depend upon - it can tell you what the type is and what variables and finctions there are. But it also knows what libraries provide extensions to the type, and can help you browse all the way through symbols in other libraries.

So the whole network of dependencies and symbol use is visible, tracable and queryable.

This also works when rendering docc tutorials. Not just for the module that the tutorial was written for - but also all dependencies available during docc build time.

3 Likes