I could see issue if using it for splitting strings, but I guess it also depends what Swift assumes to be what normal people think a character is.
Most normal people assume Unicode grapheme to be characters. That would be the set of symbols you'd consider a single letter if you were to visually count the number of symbols in the string.
In Unicode though, some code points are non visible, yet are part of the string. So for example, the character at i+1 for some match against a letter might not be the next visible letter. I can see this causing issue either way.
Honestly, I'd say it's best to just learn this, it you'll have some weird bugs one way or another.
Basically, you have code units, those are the smallest chunk of bit that has meaning in Unicode and thus can be sent over a wire, streamed or decoded. In UTF-16 encoding, which is what JVM uses, code units are 16 bit.
The history helps. In the beginning, each character in Unicode was 16bit. So you could represent all Unicode characters with 16bit only. Later, there were even more characters added, and it couldn't fit into 16bit. So UTF-16 where the 16 tells you the code units is 16 bit no longer could represent all characters in one 16 bit unit. Thus code points were invented, those are characters that span two code units 16bit + 16bit. Together they represent the new characters that didn't fit in the single 16bit range.
So nowadays, it actually takes 21 bits to represent all Unicode characters. There's three encodings: UTF-8, UTF-16 and UTF-32. Their number correspond to the bit size of their code units. In UTF-8 we break each character into 8 bit units. In UTF-16 we do so in 16 bit units, and in UTF-32 into 32 bit units.
Ok, now back to measuring length. We can say tell me the number of code units used to represent the string. That's what Java's string.length() does. Or we can say telle the number of bytes needed to represent the string (a byte is 8bit). That's what converting to byteArray and getting the length of the array does. Or you can say tell me the number of code points (Unicode characters) the string contains. In UTF-16 a code point can be 16bit (composed of one unit only), or it can be 32 bit (composed of two units). But not all Unicode characters are visible, so the user might be surprised to get a length that is greater than what it counts visually. So you can also get the number of grapheme in the string, which are "visual characters". In Java you can use BreakIterator to count those. That said, Unicode grapheme don't always make sense to what each speaker of each language would consider a character. That's for example some languages might consider a combo of two letters one character with one pronunciation, etc.
Finally, I'll say there's another interesting length. It's the font width in terms of physical measures like pixel count.
So basically, each measure might be most appropriate depending what your measuring for.
I think the real issue is that we didn't adopt new terminology of Unicode yet. You should try to start referring to things as code units, code points, grapheme and font width/height. And stop using the word character or letter.
And then just make yourself a little library that has string.codeUnitCount(), string.codePointCount(), string.graphemeCount() and string.pixelWidth().
And when you don't care about the difference between these, I'd argue that code unit count is the best default for length, which is why I don't actually disagree with string.length counting code units. Cause I think of string.length from the perspective of looping over the smallest units of the string.