af_setImage on ios13 causes app to crash

[tomeron11]

Hi also have the same problem. the af_setImage cause my app to crash. in xcode 10 it worked fine. version from the store works great on ios13. in xcode11 (official) it crashes. (phone and simulator). if i run earlier simulators (ios10,11) the code works. the debugger points on UIImage+AlamofireImage.swift extension UIImage

public static func af_threadSafeImage(with data: Data, scale: CGFloat) -> UIImage? {
   lock.lock()
   let image = UIImage(data: data, scale: scale) //the debugger stops here
   lock.unlock()
   return image
}

and in the console i see seek:285: IIOScanner::seek reached EOF getVal16:139: IIOScanner::getVal16 reached EOF

Alamofire Environment

Alamofire version: 4.9.0 AlamofireImage version: 3.5.2 Xcode version: 11 Swift version: 4.2 Platform(s) running AlamofireImage: iphone ios13 macOS version running Xcode: 10.14.6

[kaminwong]

Hi not sure if it helps but for my case the file format "application/octet-stream" was loaded successfully as image in ios12 but not ios13. Make sure the images you're fetching are saved as "image/*" (e.g. image/jpeg).

[jshier]

Odd. I wonder if the iOS 13 change that stops inspecting octet-stream responses:

To enhance security, URLSession no longer sniffs the MIME type when the server sends Content-Type: application/octet-stream. (7820658)

I'm not sure what we can do here. @tomeron11 Can you post a full crash stack trace?

[jhoanarango]

I am having the same issue, but the app is not "crashing". It's simply not setting the image being downloaded. Any hints ?

[jshier]

@jhoanarango It would be good to track down why it's not setting the image. Can you share an image URL that triggers this behavior, or perhaps debug the issue until you can isolate the cause? Perhaps the attempt to create an image from the downloaded data fails?

[jhoanarango]

@jshier I just ran 2 different simulators. iPhone X and iPhone 11 Pro, and on the iPhone X works fine, but on the Pro won't work. That's as far as debugging I can do right now lol I do not have any idea where to start to be honest.

[jshier]

What version of iOS was the iPhone X simulator running? It could at least confirm this is a version specific issue.

If you want to continue debugging, you can trace back from the code you used to set the image into AlamofireImage itself and see what data was downloaded and if that data was turned into a UIImage successfully.

If you aren't comfortable doing that, sharing the image URL would allow us to investigate.

[jhoanarango]

The version the X is running is on 12.1, and the other one in 13.0. The image URL is on a firebase data base. I will create a simple project that downloads an image and run it with both simulators and see what happens. I will get back to you in a few minutes with my findings.

[jhoanarango]

@jshier Created a very simple project with just one ImageView, installed AlamofireImage 3.5. Ran both simulators. Simulator X in iOS 12.1 and Simulator 11 Pro iOS 13.0.

The first simulator worked just fine, the other one did not. Perhaps you can try doing the same yourself and you may be able to debug further than I can.

[jhoanarango]

@jshier Any updates ?

[jshier]

No, as I have yet to find an image that replicates this issue. I encourage you to report the issue to Apple (as it's likely a change in behavior in iOS 13) and investigate it yourself. In the meantime, barring an image or image URL you can share, it's unlikely there will be much progress.

[jhoanarango]

@jshier here is the same link I am using for the test mentioned above..

https://firebasestorage.googleapis.com/v0/b/crewline-3e709.appspot.com/o/profileImages%2FDhjtY0HrXbbEZI7zdPMHQfBtc8k1%2FmyprofilePhoto.png?alt=media&token=77172515-41c1-4f7a-9804-c746f466bd12

[jshier]

Ah, as others have found, adding ImageResponseSerializer.addAcceptableImageContentTypes(["application/octet-stream"]) before loading images should accept these images that don't have a specific MIME type set. application/octet-stream sniffing was removed in iOS 13, so perhaps that's affect AFI's loading of images. Odd, if so. We may be able to add it as an acceptable content type.

[jhoanarango]

@jshier Excuse my ignorance, I can't find information on where should I put that..

ImageResponseSerializer.addAcceptableImageContentTypes(["application/octet-stream"])

[jshier]

You can add it anywhere, just as long as you add it before you start loading any images. I'm not sure where a good place would be, perhaps where you initialize your networking.

[jhoanarango]

Seems like on the version that I am is 3.5 and the code is:

"DataRequest.addAcceptableImageContentTypes(["application/octet-stream"])".

And now works as expected .. Thank you for your help !! Hope somehow is added in there for the next version.

Which is the latest version by the way ?

[tomeron11]

Hi took a while. holidays etc now with version 13.1 it doesn't crash anymore. the debugger stops at the same position, but when i press "play" the image is loaded. url that always reproduce the problem: https://storage.googleapis.com/easy/images/hpPhotos/food_1186125.jpg the "application/octet-stream" addition to the code didn't change a thing... other picture we use that didn't cause any trouble for example: https://storage.googleapis.com/easy/images/PICS/5390161.jpg

hope that's help a little thank u

[jshier]

Sounds like it was an issue with iOS 13 that was fixed in 13.1. I'll leave this issue open a while longer in case there are other reports, but it doesn't seem like there's anything for us to do here.

[tomeron11]

13.1 simulator still hangs the debugger in the same position. any clue how to overcome this?

[phatmann]

Still happens in iOS 13.2.2. The fix is simple: allow "application/octet-stream" for images.

[cnoon]

This has been resolved by adding "application/octet-stream" as an acceptable content type in f48f8cfe. This change will go out shortly in AFI 4.0.0.

Cheers. 🍻

[AbePlays]

Hey guys, I'm getting this error : Use of unresolved identifier 'ImageResponseSerializer'. Am I missing any import?