Over the last two weeks, I’ve had sporadic reports from users who suddenly have a corrupt image in the database for my app. It’s only affecting a few users and may possibly have been fixed with iOS 26.4.1 (I’m not sure). In any case, this started suddenly with the release of iOS 26.4 - our app has not been changed in several months. But I wanted to share what’s happening in case others are experiencing this.
My app lets users import photos from the camera roll, photo albums, etc. Once the user has selected an image, the app saves this to a SQLite3 database using “image.heicData()”.
For the four or five users who have been affected by this problem, the heicData call returns successfully, with a non-nil Data value. But the image itself is corrupt and unreadable. When the user tries to later open a screen containing the image, the app crashes. I’ve had to manually guide each user through tracking down and removing the affected item or items to resolve it, which is a bad experience for them and time-consuming for us. Our app crashes when it tries to read the image (using “UIImage(data: heicData)”).
All users who have this problem have had an ExcUserFault file in their crash reports with our app name in it. It's not possible to symbolicate this file but i've included an excerpt at the bottom of this post:
I was able to extract some raw data saved when this error occurs. When you run “file corrupt_image.heic”, you get:
AmigaOS bitmap font "rtypheic", fc_YSize 0, 35001 elements
which definitely doesn’t seem right. On a valid HEIC file, i get:
ISO Media, HEIF Image HEVC Main or Main Still Picture Profile
Is anyone else experience this? Or does anyone else have any suggestions about what could be happening?
I submitted feedback FB22667639 about this.
ExcUserFault example
Exception Type: EXC_GUARD
Exception Subtype: GUARD_TYPE_USER
Exception Message: namespc 7 reason_code 0x0000000000000009
Exception Codes: 0x6000000000000007, 0x0000000000000009
Termination Reason: Namespace LIBXPC, Code 9, XPC_EXIT_REASON_FAULT
Thread 0:
0 ??? 0x231fa997c 0x180000000 + 2985990524
1 ??? 0x197eb98b4 0x180000000 + 401316020
2 ??? 0x197ec4e04 0x180000000 + 401362436
3 ??? 0x197ec5ea0 0x180000000 + 401366688
4 ??? 0x19066bdb8 0x180000000 + 275168696
5 ??? 0x19066b968 0x180000000 + 275167592
6 ??? 0x19b5c19a4 0x180000000 + 459020708
7 ??? 0x19b5cfa2c 0x180000000 + 459078188
8 ??? 0x19b5cf838 0x180000000 + 459077688
9 ??? 0x197ec7c74 0x180000000 + 401374324
10 ??? 0x197ec991c 0x180000000 + 401381660
11 ??? 0x1bd74222c 0x180000000 + 1031021100
12 ??? 0x1bd744ba4 0x180000000 + 1031031716
13 ??? 0x1bd730e18 0x180000000 + 1030950424
14 ??? 0x1bd7458f8 0x180000000 + 1031035128
15 ??? 0x1bd730e18 0x180000000 + 1030950424
16 ??? 0x1bd731ae4 0x180000000 + 1030953700
17 ??? 0x1bd73bdac 0x180000000 + 1030995372
18 ??? 0x1bd73b6ac 0x180000000 + 1030993580
19 ??? 0x1e23283b0 0x180000000 + 1647477680
20 ??? 0x1e23278c0 0x180000000 + 1647474880
Having heicData() silently return corrupt data is a serious problem, especially since it doesn't surface until someone tries to display the image. I appreciate the thorough investigation — the corrupt file and the ExcUserFault reports you attached to FB22667639 are exactly what's needed to track this down.
The ExcUserFault report explains what went wrong. The termination reason — Namespace LIBXPC, Code 9, XPC_EXIT_REASON_FAULT — indicates that a system service crashed during the operation. The timing of that crash relative to your heicData() call, combined with the corrupt output, suggests that the encoding did not complete successfully but heicData() returned a non-nil Data value despite the failure.
The corrupt file header is consistent with an incomplete write. A valid HEIC file begins with an ISO Base Media File Format ftyp box followed by the heic brand. The file output showing "rtypheic" indicates the container header is malformed.
With that in mind, it's worth reviewing the full code path from image selection through to the heicData() call to see if you can identify where the corruption enters the pipeline. Threading issues or cases where the source image data could be released before encoding completes are good things to look for.
While you investigate, I recommend validating the data before storing it. I tested your corrupt HEIC file on an iPad running iOS 26.4.2 against several CGImageSource checks. CGImageSourceCreateWithData and CGImageSourceGetCount both pass on the corrupt data — they don't catch the problem. The check that detects the corruption is CGImageSourceCreateImageAtIndex, which fails because no decoder can parse the malformed container. So the validation needs to go all the way through to actual image decoding:
guard let heicData = image.heicData() else { return }
let source = CGImageSourceCreateWithData(heicData as CFData, nil)
guard let source,
CGImageSourceCreateImageAtIndex(source, 0, nil) != nil else {
// encoding produced unreadable data — fall back to PNG or re-request from Photos
return
}
// safe to store
This catches the corruption in the file you submitted and keeps data like it out of your database, giving you a chance to fall back — for example, to pngData() instead.
Additionally, I recommend continued testing of your software in system software updates as they become available, including beta software releases made available to you through your Apple Developer Programs account (see https://developer.apple.com/download/). If you find that the issue persists or is resolved, please update both this thread and FB22667639.
Thank you again for the thorough report and for filing Feedback.