Packaging Swift Apps for Alpine Linux

https://mko.re/blog/swift-alpine-packaging/

by todsacerdoti • 2 years ago

126 38 2 years ago

Similar to chroot, I wonder if flatpak is a good option? Obviously native is better but I know that that works because that's how I've run Steam on Alpine

xena• 2 years ago

Flatpak isn't really intended for command-line apps. Maybe this is where something like dockerc (https://github.com/NilsIrl/dockerc) can shine?

tadfisher• 2 years ago

Nix is another option for static builds. There is a `pkgsStatic` tree for building static musl-linked binaries, which would be a perfect integration point for Swift's static Linux target.

silisili• 2 years ago

I was curious how large these static binaries would be since the last announcement. Being honest, 100MB is quite a bit larger than I was expecting. Probably fine for CI business apps and such, but kinda rules out a lot of linux util type things.

repelsteeltje• 2 years ago

I seem to have missed the part where he explains why he's targeting Alpine Linux for his Swift app. Alpine isn't mainstream (the way Ubuntu or rhel are) and stands out mostly for being compact and clutter free.

So... indeed... If you somehow end up with 100MB package for what is essentially just 250kB, I'd say something did not go right. Feels very square peg in round hole.

yjftsjthsd-h2• 2 years ago

Some of us are just using Alpine as our primary OS, and would need a compelling reason to do anything else.

Tildey• 2 years ago

If I had to guess, Alpine is a very popular choice for building container images in Docker/Kubernetes/whatever the new hotness is since I last worked with containers. Mostly because the aforementioned small size and low overhead add up if you’re at any sort of scale (even one instance on top of your desktop OS).

If you’re wanting to containerise the program, maybe it’s less resource intensive to add those things to Alpine than to run another distro with more support? Obviously only speculation

lolinder• 2 years ago

The Alpine Linux docker image is 7.8 MiB to Ubuntu's 76 MiB, so they get a savings of about 68 MiB in image size by using Alpine Linux over Ubuntu.

From the stats in TFA it looks like about 43 MiB of the file size is the Swift runtime itself, which would need to be installed in any OS. This leaves ~57 MiB extra in their static binary approach vs what they'd get out of dynamic linking.

68 MiB (saved by using alpine) - 57 MiB (lost to static linking) = 11 MiB (net gains from Alpine), so their Alpine Linux solution is actually about 10% smaller than the equivalent that uses an Ubuntu image.

Is that worth the extra work they put into it? It probably depends on the application.

dagmx6• 2 years ago

A big chunk (roughly a quarter) of it is the Unicode handling library.

I think eventually the stdlib will be split up more so that it’s not one giant blob, but there’s a lot of areas that will be reducing in the future.

arp2422• 2 years ago

75M is still huge for this type of thing.

My smallest Go CLI is 1.6M. This is probably about as small as you can get in Go and still do something useful. Some of my other (larger) Go CLIs range from ~2.5M to ~6.5M. Go is not known for producing small binaries.

neonsunset• 2 years ago

Hmm, so it includes the entirety of Swift's standard library? Isn't there an option to tree shake/trim it? That's what .NET AOT compilation does (standard library is always included, sans the dependency on glibc or musl, which you can statically link into the binary as well should you need that)

JCWasmx86• 2 years ago

The biggest symbol of a statically linked swift binary that I have, is icudt_swift65_dat with 27.98MB, so I think that's not so easy to remove (nm v3.1.2 --size-sort --radix=d|swift demangle) And I think if you strip debuginfo it will be smaller (For a statically linked program of mine: 98MB -> 56MB)

But I think for a distribution it makes more sense to link swift programs dynamically against the runtime libraries, like it's the case for e.g. the C standard library, OpenSSL etc., as you can assume they all work with the same version and are ABI-compatible.

I tested it with a nearly static build (Still links against glibc and friends): 55MB get stripped to 44MB, so not that much. 27MB of that is icudt_swift65_dat, so I guess you would have to optimise that first

georgelyon• 2 years ago

If I’m not mistaken, the embedded swift mode aims to make ICU (the 27mb file for Unicode support) optional (and thus easily removed where it isn’t needed)

0xTim• 2 years ago

With the new Foundation work going on, when you migrate to that, if you don't import `FoundationInternationalization` then you won't pull in all of ICU and it won't be bundled in

xvilka2• 2 years ago

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

isodev• 2 years ago

Also self-inflicting Apple’s “what happens not a Mac” developer experience may not be what one wants to go through during the lifetime of an app.

mannuch• 2 years ago

Well I for one appreciate Swift’s focus on ergonomics and progressive disclosure. I think Rust is great, but I don’t see it as a great application-level programming language.

I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.

dagmx6• 2 years ago

This is like a C++ dev saying there’s no reason to use rust.

Swift offers a lot of ergonomic values over rust in ways that have made me switch over as my default choice.

Things like default argument values, lazy static initializers, computed properties, optional chaining. I’ve personally also come around to ref counting by default being a sensible choice for most programs.

Though the thing that won me over was the recent C++ interoperability. Rust doesn’t have a good story there yet that’s as comparable. Hours/days/months writing Rust bindings for a C++ library are often minutes in Swift.

Each language has its own place and own benefits, but to say there’s “no reason to use a language” feels short sighted and defensively dismissive

xvilka2• 2 years ago

I would agree with you but in the case of Swift is largely confined to the Apple ecosystem with other platforms as an afterthought, while both C++ and Rust try to cover as many targets as possible.

lenkite• 2 years ago

Wish Swift provided a way to use custom allocators. Then it would be really terrific. A fair number of middle-ware projects work well with strategies like arena allocation which significantly improve performance and also structural ergonomics. ARC adds a fair bit of performance burden - you can see dozens of examples of people refactoring continuously to reduce ARC time in the swift forums.

opless• 2 years ago

Indeed there's no compelling reason to use C++ or Rust. It comes down to user preferences.

Quite frankly if you can't track the lifetime of your own allocated memory, are you even a competent software developer?

wredue• 2 years ago

Is Linux still a fifth class citizen for swift?

The last time I used it (and I admit this was a couple years ago), silly expectations like “my program will behave the same on Linux as it does on Mac” were not being met.

bsaul• 2 years ago

Side question: what’s the status of android compilation target with swift 6 ?

Packaging Swift Apps for Alpine Linux

Related Stories