I'm not fully aware of the state of discussion, so sorry if it is already
being addressed. I wanted to bring some feedback and awareness about the
need of a supported way to build app components as *static libraries* in
Swift.
We've moved most of our new developments to Swift 3. Our apps are complex,
making use of 10's of internal libraries and/or open source ones. We've
done that for years now, creating reusable components that are built in
Obj-C as static libraries. Static libraries are great for apps: no runtime
cost, stripped to what's really needed (smaller binary). Using tons of
dylibs/frameworks does not make much sense when it comes to building apps
(see below for when they actually make sense).
Swift in its current state (v3) does not support making static libs from
Xcode. This is a major problem for large apps that need to be built on
reusable components.
There are dirty tricks that we use right now (like creating static libs
from object files through specific Xcode phase, or directly importing
source in the app target). Dylibs don't scale. Even more so with Swift. We
see so many tiny bits of code implementing one collection type or specific
algorithms. This is fine, makes a lot of sense, but dylibs don't scale for
that (app launch time). We can't have one dylib per sorting algorithm for
instance.
The case where dylib / frameworks make sense still exist through: system
libraries, or internal app libraries that enables the same feature in both
the app itself and its extensions (in iOS sense). Even in that case, the
best way to handle this situation is that those "large, feature" framework
are themselve built on 10's of smaller static libraries.
Not using dylibs but instead directly importing source in the app target
has its own share of problems. Like the absence of namespace that creates
conflicts because so many developers want to use elegant small names that
Swift rightfully encourages.
Note that ABI stability is orthogonal to this discussion, as the libs
(static, dylibs) I'm mentioning above are built all together with the same
compiler as components of the final product. The way apps are typically
built. ABI stability still makes sense for system libraries / distributed
libraries, but this is another topic.
To summarise, I'd really like to see some official support for building
static libs directly in Xcode / Swift 4 toolchain, as it's really a
limitation currently to build complex apps even though Swift appears to be
a great language to tackle that.
Raphael