I saw some SWIFT code that generates IV for AES 256 from selecting 16
characters from a-zA-Z0-9 space.
Is this secure? Sufficiently secure?
Almost always, when you see that modern ciphers are initialized by strings then the developer doesn't really understand that ciphers operate on binary data. This is a development practice that has got a special name: stringified code, where each parameter is a string, no matter what.
The characters that are used are almost the base 64 alphabet, which uses 6 bits for each byte. That means that you have (128 / 8) * 6 = 96 bits of security. We'll excuse the 64Ki options left out. That's still plenty of IV space for most usages, fortunately.
It does limit the amount of messages to encrypt with this kind of random IV though; keep to around 4 billion messages ($2^{32}$) or less for high security, and possibly a thousand times ($2^{42}$) more if you want to live dangerously.
The bigger problem is that I would not trust any developer that would use a string as key or IV. That's a $\color{red}{\text{red flag}}$: I'd start looking for other issues, because those are almost certain going to exist.
What is the best practice to generate IV for AES 256?
Will picking random 16 bytes from 0x0-0xff be good?
Yes, that is probably the best way of generating an IV for CBC mode. There are other ways of doing the same though. For many modern modes (that are based on CTR mode) you are however only required to use a nonce. In that case, a random IV may still be the best way forward, but a counter has advantages as well. For instance, a counter is less likely to repeat (the chances of an IV colliding are relatively high due to the birthday problem).
Do make sure that you are using a well seeded cryptographically secure random number generator.
We want to store key and IV in Database and retrieve it for encryption/decryption. We want to store it as a string of values (i.e "1, 255, 126, 124 ..." - 16 values like this). Than decrypt using this as bytes.
That's a bad idea because for any mode the IV should not repeat for the same key. Generally, this is achieved by keeping / prefixing it to the ciphertext. Keeping a key in the database makes little sense as well. The key should be harder to access than the fields that it is trying to protect after all.
Finally, the problem with strings is that they are commonly hard to delete from memory. Generally, you want to remove keys once they are not used anymore. For IV's that's less of an issue, as they can be made public without compromising security.
