I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

thanks for reporting @harry-dickson . I'll take a look

@harry-dickson , can you please share the code snippet you're using to store and read back the null blob?

I expected a field value of null to fall under

    case TypeOrder::kNull:
      return [NSNull null];

I'll take a closer look tomorrow, but it's Flutter/Dart and I believe it's set though an update:

  DocumentRef<Stuff> ref;
  ref.update({"blob": null});

I think I can prevent this in the case of null as a workaround - and fix the handful of broken documents
(the field is an optional, encoded profile picture)

The read is coming through a subscription:

  DocumentRef<Stuff> ref;
  ref.snapshots().listen(...)

The initial load that's triggered by the listen causes the crash before it gets near the flutter code.

I'll take a closer look tomorrow, but it's Flutter/Dart and I believe it's set though an update:
...

The initial load that's triggered by the listen causes the crash before it gets near the flutter code.

That's not right. If it is null in the source object, it is simply omitted in the Map provided to the update.
It can be an empty byte array however. Is it possible the Blob handling would transmute that into a null?

It seems plausible from a simple text search in xcode:

nanopb_utils.cc:

pb_bytes_array_t* _Nullable MakeBytesArray(const void* _Nullable data,
                                           size_t size) {
  if (size == 0) return nullptr;

  // Handle non-empty data...
}

Called from MakeByteString() nanopb_util.h line 170
Called from parseScalarValue() FSTUserDataReader.mm line 519

  } else if ([input isKindOfClass:[NSData class]]) {
    NSData *inputData = input;
    return [self encodeBlob:(nanopb::MakeByteString(inputData))];
  }

I will try and stop writing empty arrays in my code as a workaround.

I get this crash for data that looks like this in the firebase console:

  foo: "value"         (string)
  bar: 99              (number)
  blob:                (blob)

That is, the field is present, but void/empty.
Any nulls in the database was probably just me frobbing around in the console investigating this issue.

In Flutter (package cloud_firestorm_platform_interface:blob.dart) it is not legal to store a null Blob.
The bytes member in the Blob constructor is not nullable. So I am definitely never sending null to be stored.

Looks like empty Blobs are coming from the database into the ios sdk typed as a Blob but with null as value.

Something did change back in May/June time: firebase/flutterfire#11096
I ended up staring at the same code then: FSTUserDataReader/Writer.

My workaround is to store an empty String in place of an empty Blob which works for my data assumptions; ymmv:

  static Map<String, dynamic> writeBytes(
    Map<String, dynamic> buf,
    String attr,
    Uint8List? bytes,
  ) {
    if (bytes != null) {
      if (bytes.isEmpty) {
        buf[attr] = "";
      } else {
        buf[attr] = Blob(bytes);
      }
    }
    return buf;
  }

Fix will be part of next release.