12 digit UPC-A barcodes are detected as EAN-13 with an extra '0' in front on iOS

[tochichiang]

12 digit UPC-A barcodes are always detected as 13 digit EAN barcodes with extra '0' in front. This only happens on a tested iPhone SE 2nd gen, both front and rear cameras. It works fine on tested Android phones.

.Net 8.0 MAUI project
BarcodeScanning.Native.Maui NuGet package 1.5.7
iPhone SE 2nd gen on iOS 17.5.1. (Updated to 17.6.1 and the issue remains)

[afriscic]

Hello. Sorry for slow response.
iOS doesn't have support for for UPC-A directly, rather it interprets it as EAN-13 with a leading 0. As per ChatGPT:

UPC-A can be represented as EAN-13: When international products are scanned, UPC-A codes can be converted to EAN-13 by simply adding a leading zero. This ensures compatibility with systems that expect the 13-digit format.

[tochichiang]

Hello. Sorry for slow response. iOS doesn't have support for for UPC-A directly, rather it interprets it as EAN-13 with a leading 0. As per ChatGPT:

UPC-A can be represented as EAN-13: When international products are scanned, UPC-A codes can be converted to EAN-13 by simply adding a leading zero. This ensures compatibility with systems that expect the 13-digit format.

My app needs exact match instead of EAN-13 equivalent. I found that some apps in Apple's app store have the same behavior but some don't. Hope this library can return exactly what it is instead of EAN-13 equivalent.

[thomasgalliker]

The thing is, there is no fool-prove way to distinguish between UPC-A and EAN-13. Native iOS symbologies do not even offer to scan for UPC-A that's why this library maps UPC-A to EAN-13.

How would you distinguish if "0012345678901" is UPC-A or EAN-13? The leading "0" can also be used for EAN-13 barcodes as far as I know.

[afriscic]

Depending on your use case. If it is retail than you are always working with EAN-13 encoded GTINs and than the first 3 digits are always encoding the country code or UPC-A compatibility:
https://en.wikipedia.org/wiki/List_of_GS1_country_codes

Otherwise, you could technically encode any random 13 digit combination into an "EAN-13 like" barcode outside of the GS1 standard. But AFAIK this is highly discouraged to prevent confusion.

[tochichiang]

Depending on your use case. If it is retail than you are always working with EAN-13 encoded GTINs and than the first 3 digits are always encoding the country code or UPC-A compatibility: https://en.wikipedia.org/wiki/List_of_GS1_country_codes

Otherwise, you could technically encode any random 13 digit combination into an "EAN-13 like" barcode outside of the GS1 standard. But AFAIK this is highly discouraged to prevent confusion.

My app searches certain websites by the scanned barcode. Some websites do exact match only. If EAN13 doesn't match anything, it returns nothing instead of trying to remove leading 0 and search again. Sure my app can do UPC-A search again but the response time becomes slower because of the first try. In my opinion the implementation of iOS symbology is bad.

[mferrari-magaya]

We have the same issue in our app, We need to match exact barcodes instead of encoding everything into EAN-13.

[thomasgalliker]

So, since we all know that the limitation is the Vision Framework provided by iOS, what do you suppose would @afriscic do to solve this issue? I think we cannot just interpret barcodes with leading '0' as UPC-A because it could technically also be an EAN13. The only situation where we could do this is, if your scanner has only activated barcodeformat=upc-a (and not ean13). Any other way to distinctly differ between EAN13 and UPC-A is highly welcome.

[ukehartmann]

We're expecting this behaviour. So if this is changed, it should also mark the code type to UPC. I agree with @thomasgalliker that this is not an issue for this library but Apple.