So many ways to define a byte

It's totally indifferent. Whichever you use, it will most probably end up being an unsigned char. If you want it to look nice, though, I suggest you use uint8_t from <stdint.h>.

Neither will change with the architecture. char is always 1 byte as per the C standard, and it would be insupportable from a user's point of view if in an implementation, UInt8 suddenly became 16 bits long.

(It is not the case, however, that char is required to be 8 bits wide, it's only that if the name of a type suggest that it's 8 bits long, then any sensible implementation does indeed typedefs it as such. Incidentally, a byte (which char is) is often an 8-bit unit, i. e. an octet.)

As in every programming language derived from C-language type model, Objective C has a handful of equivalent options to declare a 8-bit integer.

Why did I say equivalent? Because as OP correctly stated, it's obvious that all of those options eventually typedef-ed to unsigned char built-in compiler type. This is correct for now and, let's speak practically, nobody sane will change them to be a non-8-bit integers in the future.

So, the actual question here is what is the better order to prioritize considerations when choosing the type name for 8-bit integer?

Code readability

Since basically in every code having C language roots, primitive type names are a mess. Therefore, probably the most important factor is readability. And by that I mean clear and uniquely identifiable intent of choosing this specific type for this specific integer for the majority of people who would read your code.

So let's take look at those types from an average Objective C programmer point of view who knows little about C language.

• unsigned char - what's this??? why char is ever meant to be signed???
• uint8_t - ok, unsigned 8 bit integer
• UInt8 - hmm, the same as above
• Byte - signed or unsigned 8 bit integer
• Bytef - what's this? byte-float? what does that 'f' mean?

It's obvious here that unsigned char and Bytef aren't a good choices.

Going further, you can notice another nuisance with Byte type name: you can't say for sure if it represents signed or unsigned integer which could be extremely important when you're trying to understand what is the range of values this integer could hold (-128 .. 127 or 0 .. 256). This is not adding points to code readability, too.

Uniform code style

We're now left with the 2 type names: uint8_t and UInt8. How to choose between them?

Again, looking at them through the eyes of an Objective C programmer, who is using type names like NSInteger, NSUInteger a lot, it looks like much natural when he sees UInt8. uint8_t just looks like a very low-level daunting stuff.

Conclusion

Thus, we eventually are left with the single option - UInt8. Which is clearly identifiable in terms of number of bits, range and looks accustomed. So it's probably the best choice here.