I have this issue as well.

Thanks for the lead. Actually, I was very happy to use RecognizeTextRequest.perform(on: URL) because I was supposing that the underlying code was optimizing everything in terms of CPU/GPU. Of course it wouldn't make any sense that the code would resize the image there, not knowing what the image contains. Therefore, If I'm to resize the images before OCR by defining a maximum resolution, do you have a recommandation (ballpark) on good pixel values to use knowing that the images are documents? Also, can you confirm that RecognizeTextRequest.perform(on: CIImage) would be the optimized choice to use in the case of a resized image? In other words, flow would be: URL > CIImage > resized CIImage > OCR Thank you very much in advance :-)

Hello, thank you for your answers! I already tried to profile various iOS devices, without success: from iPhone 12 to 16 Pro: all are only capable of 2 requests in parallel. Requests must definitely be .accurate, and resizing the image would be too resource demanding. I'm flying blind here unfortunately, and currently, I have to serialize and avoid having more than 2 in parallel, otherwise the app completely hangs. I wish I could at least have some error thrown.

So far, no. But I don't think my iOS 26 user base is large enough to conclude anything. I'll report here if I see any crash from iOS 26. It happens quite often in production though, is there anything I can do to at least mitigate the issue?

I'm sorry, I thought I was saving a draft. Here is the bug report number: FB18227187 Thank you!

Same here. It might have started with iOS 18.3 though.

Yes, I perform OCR on multiple images in parallel. This is a use case of the app. Typically: a background process might OCR images that haven't been OCR'd yet the user can add new images where OCR has to be performed etc... Moreover, as suggested in the WWDC video, I wanted to use the new Swift Concurrency API to perform multiple requests in parallel. But as mentioned in the topic, their provided code won't work with RecognizeTextRequest. My current workaround is unfortunately to serialize every OCR request, to avoid the issue. But this doesn't fit the spirit of the app and the architecture.

Not fixed under iOS 18.4, unfortunately :(

@DTS Engineer : I filed the bug report:** FB16995719** I tested the old way for indexing: indexSearchableItems(_:completionHandler:) The issue remains the same. The textContent is NOT found when using Spotlight. However, querying Spotlight on textContent within the app, returns the right result. This is so strange. Best regards

So I ran further tests: Setting contentType: no success -> title is indexed, but not textContent attributeSet.contentType = UTType.plainText.identifier attributeSet.textContent = ocrText I tried printing the entity textContent just before indexing: NSLog("Indexing entity with OCR = \(entity.attributeSet.textContent ?? "")") try await CSSearchableIndex.default().indexAppEntities([entity]) It correctly prints out the textContent of the entity. --> Core Spotlight indexes the entity, but seems to ignore the textContent field Modified the AppIntentsJournal project from Apple, to fill in the textContent field in the indexed attribute set. --> textContent is correctly indexed in that project The entity are almost identically the same in both projects. What could cause a difference in behavior from CoreSpotlight?

Did you find a solution to this?

Same question here

Changing let thumbMaxSize = min(2400, maxImageSize) with let thumbMaxSize = min(1200, maxImageSize) thus, simply reducing the image size, fixed the issue. I don't know what changed in 18.2 in that regards, but I must say that I'm happy that my use case allows for reducing the image size. Any detail would be appreciated, in order to ensure that everything is working as it should. Thanks!

So I confirm that this became a mess. A device can become uncalibrated, probably when he stays inside for a significant amount of time. The issue is that going outside with clear GPS signal is not a good solution. It might take A LOT of time for the device to recover (my watch, for example, never re-calibrated). If it does, the app using CMAltimeter might enter a weird behavior, due to the delivery of inaccurate events. I don't know what happened with the latest updates, but I have 2 production apps facing major issues.

Did you find a solution to this?