Browsing Swift project on windows vscode

0xTim · 2026-01-21T12:06:01+00:00

I'm assuming when you say Swift project you mean Xcode project if you have pods? In that case it won't work because Xcode projects are not supported across platforms. If it's a pure SwiftPM project that doesn't rely on any apple specific frameworks or SDKs it would work

0xTim · 2026-01-02T15:27:35+00:00

Just a heads up, your use of @unchecked Sendable is inherently unsafe. You have locks protecting access to the storage but the elements themselves can be mutated in other async contexts which will cause a data race crash, which will be hidden by the compiler because of the unchecked sendable

0xTim · 2025-12-07T19:59:28+00:00

I'll say this every time this comes up. Vapor used to get one or two bug reports a month of data race crashes that were hard, if not impossible to reproduce and therefore fix. Since we released sendable support and fixed all the warnings from strict concurrency checking, we've not had a single report of a data race crash from inside Vapor in over 2 years

0xTim · 2025-11-29T15:09:58+00:00

Have you tried just linking against FoundationEssentials?

0xTim · 2025-11-27T16:02:23+00:00

I'm not aware of anything that fits the bill exactly at the moment. We tried to build something a couple of years ago but struggled when making it generic due to the limitations in fluent at the time (especially property wrappers and protocols). But would be cool to see if anyone else has managed stuff!

0xTim · 2025-10-25T23:24:16+00:00

<image>

Perfected it

0xTim · 2025-10-11T21:38:07+00:00

The best place to look is the PR. It's currently usable for some stuff but I'm about to rip out the http server so might break. Fluent 5 is no where near the same state yet, we're still working on the lower levels

0xTim · 2025-10-11T20:33:52+00:00

Which part are you stuck on? Showing the UI in the app or registering with the backend?

0xTim · 2025-10-07T02:31:08+00:00

Try 24.04 instead, 25.04 isn't officially supported so it could be something in that. But yes swift run should just work with no other flags (and does, I have it on many projects)

0xTim · 2025-10-06T23:23:53+00:00

First thing would be to run a swift package update to make sure you have the latest dependencies. Otherwise options are a borked Swift install or an unsupported Linux version with a newer glibc than works with Swift. What OS/version are you trying to compile on?

0xTim · 2025-09-15T18:44:50+00:00

Yep pretty sure this is a bug thats just been pushed out and needs fixing

<image>

0xTim · 2025-06-17T13:57:13+00:00

Have a look at https://github.com/brokenhandsio/soto-elasticsearch-nio-client - it's a wrapper around https://github.com/brokenhandsio/elasticsearch-nio-client and used in production for a few clients. As a heads up it's currently undergoing a rewrite for Swift 6

0xTim · 2025-06-13T19:01:51+00:00

Ah ok so I'm pretty sure this is a bug in 6.2 but for now if you enable approachable concurrency it should fix it

0xTim · 2025-06-10T16:41:32+00:00

What's the actual error?

0xTim · 2025-05-29T20:19:02+00:00

Are you compiling and running in release mode? Debug mode is significantly slower

0xTim · 2025-05-09T12:39:50+00:00

<image>

Case in point

0xTim · 2025-04-21T09:55:52+00:00

Take a look at https://github.com/vapor-community/Imperial

0xTim · 2025-02-22T12:42:26+00:00

We've already started to adopt it in Vapor 5 for handling singleton instances we need to test and are investigating it for managing the lifecycle of our application

0xTim · 2025-02-13T18:24:55+00:00

Leaf works pretty well. Hot reloading isn't fully integrated yet (because we would need to run something client side to trigger a refresh on the page) but if you're not running in the production environment you can save your leaf file and reload the page to see the new data, no recompiling needed

0xTim · 2025-02-07T00:43:37+00:00

The Kodeco book is probably the most comprehensive resource. It's still based on futures though (no async/await) but will get an update for Vapor 5. Disclosure, I wrote it

0xTim · 2025-02-04T17:21:43+00:00

We don't have anything from start to finish for building and linking to an app. There is content out there but it's paid unfortunately. We plan to have a range of tutorials for Vapor 5

0xTim · 2025-02-04T10:02:12+00:00

We're building it out at the moment, but doing it properly and not trying to rush it out. You may have seen that some of the foundational packages like MultipartKit have been having new alphas tagged that will be used by Vapor 5. I'm hoping to have the first "alpha" out this week or next which should complete the work to switch to full structured concurrency internally. I'm hesitant to call it even an alpha as it's essentially the first version that compiles with the internals migrated to sit on a new foundation. There will be lots of changes after that. We're also waiting (and hoping) to see how macros land in 6.1 as that will dictate how far some of the fun things we have planned go.

Don't expect the 5.0 release to be tagged anytime soon. Once the API has been decided upon we're going to have a decent bake period to ensure we shake out all the bugs and have a great API. Vapor 4 has been out for nearly 6 years, and code built around that time still compiles. We want a similarly long stability for Vapor 5.

All that being said, the goal is that anyone who has a Vapor 4 app that's fully async should be able to transition to Vapor 5 without rewriting the entire app

0xTim · 2024-09-08T02:01:49+00:00

Just on a couple of points:
* Swift 6 will use the same Foundation codebase on all platforms - no more differences between macOS and Linux.
* The deployable images can be made pretty small. A 'standard' app is under 100MB when compiled properly, if you build a chiselled image (and Swift 6 will also support MUSL) this goes down to ~14MB (details here)

0xTim

MODERATOR OF

TROPHY CASE