Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.

I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.

▲

hn-acct 3 hours ago | parent | next [-]

I'm also wondering how big their programs are that the compile times are an issue. I'm seeing fantastic build times with Xcode 16 and Xcode 26.2 with swift 6.2 it's even better. SPM is also better with the newer version. Most issues can be solved or exposed by closing the window and reopening or going to the package with issues and pressing cmd+s.

▲

ElFitz 7 hours ago | parent | prev | next [-]

Trying to make a .xcframework from SPM is "fun". And getting the Objective-C that are generated, but treated as intermediary artifacts discarded is a bit of a pain.

But I guess the issue here is that .xcframework is an Apple thing, not a Swift thing.

The whole "won’t build if the product / target has the same name as one of its classes" is absolutely ridiculous on the other hand.

	▲	wahnfrieden 2 hours ago \| parent [-]
		Try xccache

▲

cosmic_cheese 8 hours ago | parent | prev | next [-]

Experience with SPM might vary depending on how many dependencies you’ve got. A lot of Apple platform apps are quite thin on third party library use, in which case SPM is probably not a large source of trouble.

▲

ethin 8 hours ago | parent [-]

My problem with it is that I want to use C libraries. And I would (like) it to handle that as much as possible. But SPM can't use vcpkg packages or call CMake stuff (at least, not trivially), so it's extremely hard to use on non-Apple platforms. Which honestly is it's killer for me. It's still so, so Apple focused.

▲

willtemperley 7 hours ago | parent | next [-]

You can build Swift entirely with CMake;

https://github.com/swiftlang/swift-cmake-examples

▲

ethin 5 hours ago | parent [-]

Sure, but I've never found examples of (say) including other swift packages. Or using CMake-built swift packages in SPM.

▲

jabwd 4 hours ago | parent [-]

What is a CMake-built swift package to begin with? You're mixing build systems and expecting them to co-exist or what is the exact problem? I've done a lot of weird swift things so might be able to point you in the right direction.

	▲	ethin 3 hours ago \| parent [-]
		E.g.: referencing a vcpkg-built package (without pkgconfig because not all packages have those files). Or telling SPM "Hey, I have this package which uses the cmake build system, and I want you to link to it and auto-generate module maps for it, and get the include directories from cmake". Things like that. So for me anyway it makes using swift painful. The same thing goes in reverse: using SPM packages from cmake (although this is more a cmake issue).

▲

wahnfrieden 2 hours ago | parent | prev [-]

I think cmake very recently got added to spm

▲

h4x0rr 8 hours ago | parent | prev | next [-]

Using explicit types is less fun though

▲

ElFitz 7 hours ago | parent [-]

It even defeats the purpose of type inference.

	▲	mh2266 6 hours ago \| parent [-]
		It's been a while since I've Swifted but it was mostly with combinations of nested generics, lambdas, and literals. Annotating the type of the variable those were assigned to could improve performance a lot. You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.

▲

plagiarist 7 hours ago | parent | prev [-]

SPM is fine for most Swift and then fully enraging when you have a slightly divergent use case. IME of course.