<div dir="ltr">I&#39;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. <div><br></div><div>We&#39;ve moved most of our new developments to Swift 3. Our apps are complex, making use of 10&#39;s of internal libraries and/or open source ones. We&#39;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&#39;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).</div><div><br></div><div>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.</div><div><br></div><div>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&#39;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&#39;t scale for that (app launch time). We can&#39;t have one dylib per sorting algorithm for instance.</div><div><br></div><div>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 &quot;large, feature&quot; framework are themselve built on 10&#39;s of smaller static libraries.</div><div><br></div><div>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.<br></div><div><br></div><div>Note that ABI stability is orthogonal to this discussion, as the libs (static, dylibs) I&#39;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.</div><div><br></div><div>To summarise, I&#39;d really like to see some official support for building static libs directly in Xcode / Swift 4 toolchain, as it&#39;s really a limitation currently to build complex apps even though Swift appears to be a great language to tackle that.</div><div><br></div><div>Raphael</div></div>