Have you considered adding retroactive conformance yourself?

import Siesta

extension RequestError: LocalizedError {
    public var errorDescription: String? {
        return userMessage
    }
}

You can do that within your project, without any changes to Siesta.

If that doesn’t suit your needs, would you elaborate a bit on your use case? What is the situation in which you have a RequestError but are not working with any other Siesta API?

I’ve been reluctant to make RequestError a Swift Error because it doesn’t exactly have the shape of one. (It isn’t ever thrown, for starters.) It’s perhaps better to think of it as an event payload that wraps a Swift error.

That may be a distinction without a difference, and I’m open to adding LocalizedError conformance. However, I suspect that may cause more confusion than not: Siesta.RequestError has one guaranteed message; LocalizedError has four optional ones.

Yes, that's what I'm doing atm, just thinking it might be more global usage for others, I'm actually doing verification inside the function that have Siesta call, that have completion closure with single error param that can return either Siesta error or verification error, then read the localized description to display it, don't need to cares if its from verification or networking.

Usually in iOS I only need to use error.localizedDescription to display for any kind of error, I think it will be more common use of Error inside the app. It's still kind of depends for others.