iOS - Unable to scan high-density QR codes (1200+ bytes) / MiDNI format

[neofar]

Hi everyone,

I'm having trouble scanning high-density QR codes on iOS. The use case involves scanning a QR code generated from an official ID document (MiDNI). You can find the technical documentation and examples (from page 22 onwards) here: https://www.midni.gob.es/assets/pdf/MiDNI-FormatoQR_v107_sc_PN.pdf

The QR code contains a byte buffer that can exceed 1200 bytes.

The issue:

• Android: Works perfectly; the QR is read instantly.
• iOS: The scanner fails to capture/recognize the code.

What I've tried: I have already experimented with parameters such as RequestZoomFactor, CaptureQuality, and AimMode, but none have yielded positive results.

I’ve tested other third-party scanning apps on the same iOS device, and they can read the code without issues. This leads me to believe it's not a limitation of the native iOS hardware/framework itself, but rather a configuration issue in my implementation.

Does anyone know which specific parameters or configurations are required on iOS to successfully capture these large, high-density QR codes?

Thanks in advance!

[afriscic]

Commercial scanning frameworks usually come with their own recognition engines that have some advantages to built-in ones (that is what you pay for).

AFAIK there isn't anything to tweak to improve built-in detection capabilities.

[afriscic]

The only thing that crosses my mind is to use Google Mlkit on iOS platform, as it detects the code on Android. This could be done but it would increase the complexity to maintain this project so for now there aren't any plans to support it...

[neofar]

First of all, thank you for your response. I understand your point, and I agree that switching the image analysis implementation to Google MLKit would be a fairly large change.

That said, I have made some progress while investigating the issue.

While reviewing the iOS implementation source code, I noticed there is a filter that validates whether the detected code contains text data. Because of this validation, QR codes that only contain RawBytes are ignored, which is exactly the problem I am currently facing. I tried temporarily disabling that validation, and interestingly, I was then able to receive the QR payload in binary format. However, the data is not directly usable and requires some additional processing. It appears that the framework is returning the raw encoded payload instead of a fully decoded byte stream.

The byte buffer I receive has the following structure:

[4 bits ] Mode indicator flag (yes, only 4 bits)
[2 bytes] Data length
[x bytes] Data         <-- This contains the QR Raw Bytes
[x bytes] Padding

The first 4 bits represent the data mode indicator. The encoding specification can be found here:
https://www.thonky.com/qr-code-tutorial/data-encoding

In my case, the mode is always 0100, which indicates that the payload contains byte data.

The main difficulty is that those initial 4 bits cause the remaining data to be bit-shifted, meaning the buffer cannot be processed directly as a standard byte array. To solve this, I implemented a small realignment step. The idea is to remove the first 4 bits and rebuild the buffer by combining the upper 4 bits of each byte with the lower 4 bits of the next byte. Once the buffer is realigned, the next two bytes represent the payload length. This is important because the buffer also contains trailing padding that must be removed.

One limitation I have observed is that the extracted length bytes are not always fully reliable, although in practice this workaround is producing correct results for my use case.