Entitlements path was set on Project level thus both iOS app and PNSExt used the same file. I split this to be set per target and just removed DataProtection capability from the entitlements used by PNSE. Initial test on several devices seems to indicate that problem went away. We will deploy updated build to customers and monitor what's happening. Did someone forgot to use startAccessingSecurityScopedResource() for this? 🙃 (Thanks for timely answers!)

Here is debugger state, as detailed as I can get it, for the case when this error happens. URLResponse is HTTP 200 so the picture is downloaded OK. But tempURL (first param in downloadTask's closure) is nil so this is some error in local file handling in code that prepares downloaded file for handing over to my process.

Yes, it happens on many iPhones. This is issue in live app thus we see it on quite a variety of devices.

(I tried to attach the .swift file contents here using either Add text or Add file), but the form won't let me do that.)

What I meant: on the same iPhone, I receive say 10 push notifications sent from our backend (which goes to Firebase, which sends notification through APNs), all with same structure with only difference being imageUrl. It's entirely random how many will have download task succeed and attach downloaded image file to the UNMutableNotificationContent and how many downloads will fail with the said error. Sometimes most succeed. Sometimes none. Often 2-3 are OK, the rest fail. I checked SSL, TLS, whatever I could think for the web servers where the files are located, that was all fine. Today I fired up the debugger session for the PNSE process and re-run the notification that has just failed minutes ago only to see the download returns with URL and no error. When I do get the error in the debugger session, I don't see anything useful in the stack frame that could tell me where is the problem. I also tried using URLSesssion instance with custom configuration, seem to behave the same. extension URLSessionConfiguration { static var preferred: URLSessionConfiguration { let c = URLSessionConfiguration.default c.allowsCellularAccess = true c.httpCookieAcceptPolicy = .never c.httpShouldSetCookies = false c.httpAdditionalHeaders = [ "Accept-Charset": "utf-8", "Accept-Encoding": "gzip, deflate", ] c.requestCachePolicy = .returnCacheDataElseLoad return c } } No idea what else to try...

This is infuriatingly random. I have 3 super similar layout implementations in the same app. Two are working and 3rd is crashing when I pull down long enough down so that header is near the center. This causes layout loop in cells just outside the bottom edge. Those are cells where text in label is long enough taht it needs two lines. This crashes: func createSection(at index: Int) -> NSCollectionLayoutSection { let item = NSCollectionLayoutItem( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(60) ) ) let group = NSCollectionLayoutGroup.vertical( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(60) ), subitems: [item] ) let section = NSCollectionLayoutSection(group: group) let headerElement = NSCollectionLayoutBoundarySupplementaryItem( layoutSize: NSCollectionLayoutSize( widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(200) ), elementKind: ProfileHeaderCell.kind, alignment: .top ) section.boundarySupplementaryItems = [headerElement] return section } but if I change the item's height to heightDimension: .fractionalHeight(1.0) then it does not crash. With crashing code, I also noticed that lower cells are being continually extended in height as I pull the scroll view upwards. It's like I am extruding the cells. Super weird behavior.

To anyone having trouble with this, here's an additional test – do a GET for this https://app-site-association.cdn-apple.com/a/v1/YOURDOMAIN Replace YOURDOMAIN with whatever domain you put after applinks:. It should return the file version from AASA CDN. If it returns blank, then it means your AASA file or entire domain is not accessible to AASA-Bot and you should investigate that.

Thanks for the sysdiagnose pointer (this should be added to the documentation page). I found this: Service: applinks App ID: TeamId.bundle.id App Version: 510.0 App PI: <LSPersistentIdentifier 0x104622ac0> { v = 0, t = 0x8, u = 0x8a4, db = 284B9176-578F-42D3-A1D7-9F82DA98D040, {length = 8, bytes = 0xa408000000000000} } Domain: mydomain.com User Approval: unspecified Site/Fmwk Approval: unspecified Flags: Last Checked: 2022-01-27 20:20:37 +0000 Next Check: 2022-01-27 23:55:10 +0000 Error: Error Domain=SWCErrorDomain Code=7 "SWCERR00101 Bad HTTP Response: 503 Service Unavailable -- {"status":"503 Service Temporarily Unavailable"}" UserInfo={Line=274, Function=-[SWCDownloader URLSession:dataTask:didReceiveResponse:completionHandler:], NSDebugDescription=SWCERR00101 Bad HTTP Response: 503 Service Unavailable -- {"status":"503 Service Temporarily Unavailable"}, UnderlyingError=Error Domain=HTTP Code=404 "(null)" UserInfo={Line=274, Function=-[SWCDownloader URLSession:dataTask:didReceiveResponse:completionHandler:]}} Retries: 1 This 503 error could be because of geo-restrictions on the site itself, I'll try to fix/check this with sysadmins.

I am trying with developer alternate mode. Adjusted to this: applinks:mydomain.com?mode=developer and verified in .entitlements file that it's changed. Deleted the app from device and build&run from Xcode, directly to my device. I had Proxyman running on iPhone to see will it actually fetch the AASA file from our server and it did not. The universal links thus still did not work. What am I missing here..? Also, not sure this means: As an additional precaution, only apps that you sign with a development profile can use developer mode, and users must opt-in on any device they use. Where are users supposed to opt-in on the device..?