Regardless of how fast it is, it seems wasteful to do all this byte-swapping when the vast majority of systems today, outside of more specialised applications, are little-endian.
Well considering the vast majority of swift code runs on Apple's ARM chips (iDevices) rather than x86 processors (Mac), I think that's kind of a moot point
It seems I should have just left out the fact that byte-swap is a single instruction on x86, I was trying to make the point that it is fast but I suppose the point missed its mark and the fact that it's a single instruction really doesn't matter. You can do the swap with a few shifts and it still takes no time at all. If speed really becomes such a factor that this is too slow doing the encoding and decoding, you'll likely be looking at replacing this framework with a more hardcoded solution, not removing byte-swaps.
With a choice, when reading every platform has a conditional swap rather than some platforms having an unconditional swap (and the others having no swap at all).
A choice will only be beneficial if writes happen more often than reads (as providing a choice means that platforms can do no swapping on write). This can only be the case if some written data is never read.
Also, conditionals in general are not good from a performance perspective, so even more writes than reads doesn't make it clearly better to have a choice.
Performance is not really a concern for this implementation. I would guess that the indirection from calling through all the Swift protocol methods will completely swap any cost of having extra branches (which will be predicted correctly about 99.99% of the time if there's a lot of them).
Most application protocols I've worked with are LE; serialisations like Avro, BSON, capnproto, protobufs, etc. come to mind, as well as numerous other proprietary ones. ASN.1 is a notable exception, but it's also much older.
As an aside, the book, Advanced Swift, by the objc folks is fantastic but assumes you already know Swift. It's not what you're looking for, but something to move onto after you grasp the basics.
2.x was stable all through, but a lot of work to migrate from 1.x
3.x minor changes but a big renaming effort leading to a lot of work in accepting proposed changes in Xcode. Laborious more than difficult
4.x most projects I've tested just compile. On the road to a stable ABI