Well..did didn't think this myself, so very clever.
Though this isn't really that generizable method.

But it works, and answers the question asked.

I believe this to be the "correct" way of doing it.
It's expandable into a more generalized version easily and can handle alphabets beyond just standard english alphabet.
And can easily be modified to different encryption shifts.

Also very readable, which is always a good thing.

Very cool and clever. Good job!

Clever, wouldn't probably call it best practise as this is specific to an english alphabet (which was ok for this kata)

This is a good and simple solution, thought specific for an english standard alphabet (which I suppose was enough for this specific kata).
I wonder if it's just a coincidence that english alphabet divides nicely into 2 equal sets of chars?

This solution works...as in it answers the question asked.
Now on the other hand... I wouldn't say this is a usable solution in general.

Checking out the other solutions you can find more generalized ways of thinking about this problem.
Which in my opinion is the right way to go about this.
Though I have to say..the oneliner solutions aren't good necesserily either. They are clever but not necesserily the Best Practise.

The generalized solution would take for example into account the fact, that you could want to change the shifting value from 13 to let's say 20.

Wanted to do a solution without using BigIntegers, which I did for a similar kata earlier.
Wanted to incorporate the basic arithmetics we were taught in primary school on how to calculate with big numbers.

I suppouse we should always remember to do null checks, even if the assigment specifically said the input will letters and spaces.

Always remember nullChecks!

The resources need to only be accessable during the runtime, so no need to use external database/files.