The solution that I will provide might not work, it depends on decoder at your iPhone part. It really rely on ECI(Extended channel interpretation) table.
QrCode and any barcode will follow ECI as for extended char table. Barcode will not take any byte input, but if you can translate byte to char then encode. That way will ensure you will get your info.
Tricky thing at moment is to find a char table under ECI list that from 00 to FF will not have any empty value. Let me give you some example.
Bad char table: iso-8859-1 http://en.wikipedia.org/wiki/ISO/IEC_8859-1 from 00~1F and some other area, they are empty. So when you translate 00 byte to 8859-1 table's char,
it will gives you same char as byte 1E. Both byte on that table are blank. Depends on char decoder written within your language, they will most likely give a common char to represent those blank char.
Good char table: IBM437 http://en.wikipedia.org/wiki/Code_page_437 As you can see, there is no blank byte. It's typical 00~FF one byte only char table. Problem is there is no such
table include inside ECI list. However, google's zxing decoder and encoder list that table at number 0 and number 2. thus zxing's decoder surely able to decode that char table, then I'm not sure about other decoder, as I don't have their source code.
For our encoder, we partly follow ECI list and adjust a bit according to ZXing. Our ECI list number 2 char table is IBM437. Encoder will detect it on it's own, so as long as your input string according to that will do.
More detail about implementation will be, well if I am you I will do following. As you have byte set, translate byte set use IBM437 char table to proper string set, and pass that to encoder. At client side, decode, then use IBM437 to translate to byte.
For C#, char table IBM437 is called as IBM437 while at Java, it's name is Cp437.
Now for a way to solve issue that if decoder not support char table IBM437. That will involve some modify library action. Go to class file for ECISet.cs under folder DataEncodation folder. Remove "AppendECI("IBM437", 2, option);" After remove
that line and compile, now encoder won't check IBM437 table, it will use utf-8 char table. From what I know most of decoder support that. Progress will be same, at your side, translate byte to char use IBM437 same as before, then encode QrCode. Encoder will
encode as utf8, at client side after decode, use IBM437 to translate that char string to byte. Now you have full byte array for you to use.
Disadvantage for that action will be utf8 char will use more byte than typical IBM437, thus QrCode sometime will be bigger than use first way to solve it.
For renderer, I believe you didn't use 0.3 beta, instead, you choose to use latest source code. Am I right? If so, I would like you to check out following link.
After 0.3 beta, I have totally rewrite renderer and control, thus new control and renderer's commander are totally different to old one. I have written wiki for newest change under document, but didn't delete old one as we haven't officially publish next
beta. Sorry about that.
I hope that can help you solve your issue, let me know if you have any other questions.
Also if your byte array is huge, and use utf8 to solve that issue, then you need to have some knowledge about how many byte could version 40 QrCode contain. Break byte array to several pieces, making multiple QrCode according to that and combine them
at client side. It will be a bit tricky. Check out ISO documentation we had at front page, scroll down to any table that could gives you that info will do.