Post

Replies

Boosts

Views

Activity

Reply to URLSession is broken in iOS 18.4 RC Simulator
This is sorta ridiculous where it developed. I've seen reports over Twitter, bunch of GitHub issues for Meta, Google SDKs, Flutter, RevenueCat… I wonder how this made it to a full release being known since almost the beginning. I don't even think there's a usable method to escalate serious issues or blockers in the release train, unfortunately, nor an efficient way how Apple could communicate this. To this day, from the Dev portal it seems like if there are no issues at all, despite being the contrary. Could we have some 1st-party communication from Apple regarding this, ideally on the Dev portal & Developer app (News section) or somewhere? This & other issues (StoreKit, UI crashes etc.) has a solid potential to ruin someone's day, now imagine somebody not noticing updating all self-managed CIs to latest releases and only after that finding out about it – whole pipeline red as a commies march & machine- + man-hours wasted. 🙃 @eskimo pls bump it up! 🙏
Apr ’25
Reply to URLSession is broken in iOS 18.4 RC Simulator
Not really, my issue also appears only in the Simulator – when I tested the app bundle on the real 18.4 Beta/RC device, it worked just fine. Now, the more I'm testing it, the “trick“ with Info.plist exceptions seems not to work anymore, only setting the .websiteDataStore = .nonPersistent() allows me at least render the desired website right now. Got a bunch of logged issues on the way, as follows. 1️⃣ Error caught in webView(_:didFailProvisionalNavigation:withError:): // 18.4 Simulator exclusive 0x1040bbc18 - [pageProxyID=12, webPageID=13, PID=8501] WebPageProxy::didFailProvisionalLoadForFrame: frameID=16, isMainFrame=1, domain=NSURLErrorDomain, code=-1001, isMainFrame=1, willInternallyHandleFailure=0 Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSErrorFailingURLStringKey=https://www.kiwi.com/, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <EE8D03C0-F32B-4DC7-9D77-4E3F5A5694C2>.<2>, NSErrorFailingURLKey=https://www.kiwi.com/, networkTaskMetricsPrivacyStance=NotEligible, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <EE8D03C0-F32B-4DC7-9D77-4E3F5A5694C2>.<2>" ), NSLocalizedDescription=The request timed out., _WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x6000002557c0>, networkTaskDescription=LocalDataTask <EE8D03C0-F32B-4DC7-9D77-4E3F5A5694C2>.<2>, _kCFStreamErrorDomainKey=4, NSUnderlyingError=0x600000c11d70 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _kCFStreamErrorCodeKey=-2102} 0x103a4a818 - [pageProxyID=12, webPageID=13, PID=9737] WebPageProxy::didFailProvisionalLoadForFrame: frameID=16, isMainFrame=1, domain=NSURLErrorDomain, code=-1005, isMainFrame=1, willInternallyHandleFailure=0 Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={NSErrorFailingURLStringKey=https://www.kiwi.com/, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <764262C2-9135-4B73-B98C-A0404487BC91>.<2>, NSErrorFailingURLKey=https://www.kiwi.com/, networkTaskMetricsPrivacyStance=NotEligible, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <764262C2-9135-4B73-B98C-A0404487BC91>.<2>" ), NSLocalizedDescription=The network connection was lost., _WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x6000002ddd40>, networkTaskDescription=LocalDataTask <764262C2-9135-4B73-B98C-A0404487BC91>.<2>, _kCFStreamErrorDomainKey=4, NSUnderlyingError=0x600000c96760 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={_kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _kCFStreamErrorCodeKey=-4} 2️⃣ Random log mentioning browser engine entitlements: // Also shown with 18.3 Simulator Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))" UserInfo={NSLocalizedFailureReason=((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))}> 0x12700e0b0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=8136, error: (null) 3️⃣ Random log containing QUIC & network issues: // 18.4 Simulator exclusive quic_conn_change_current_path [C4.1.1.1:2] [-fc2c137b006e9a75] tried to change paths, but no alternatives were found ...repetitively... Task <854C1530-6678-4EBA-8279-353D981F20E0>.<3> finished with error [-1017] Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response" UserInfo={_kCFStreamErrorCodeKey=-1, NSUnderlyingError=0x600000c81d10 {Error Domain=kCFErrorDomainCFNetwork Code=-1017 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x6000021454f0 [0x1e6ebb4f0]>{length = 16, capacity = 16, bytes = 0x100201bb8efb256a0000000000000000}, _kCFStreamErrorCodeKey=-1, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <854C1530-6678-4EBA-8279-353D981F20E0>.<3>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <854C1530-6678-4EBA-8279-353D981F20E0>.<3>" ), NSLocalizedDescription=cannot parse response, NSErrorFailingURLStringKey=https://firebaseremoteconfig.googleapis.com/v1/projects/kiwi-debug/namespaces/firebase:fetch?key=XXXXXXXXXX, NSErrorFailingURLKey=https://firebaseremoteconfig.googleapis.com/v1/projects/kiwi-debug/namespaces/firebase:fetch?key=XXXXXXXXX, _kCFStreamErrorDomainKey=4} // (Similar issue for plain URL https://duckworth.finance-prod.skypicker.com/currencies-config) 4️⃣ Some Simulator stuff from Console app: nw_endpoint_flow_failed_with_error [C16.1.1.4 18.245.62.104:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], expensive, uses wifi)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection quic_conn_change_current_path [C12.1.1.1:2] [-e80eabd0b655b188] tried to change paths, but no alternatives were found [app<com.skypicker.Skypicker((null))>:9733] client not entitled to get limitationsForInstance: <Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.process-state, NSLocalizedFailureReason=Client not entitled, RBSPermanent=false}> 0x1048f0818 12 Server protocol violation 0x02 0x1048f0818 12 Control stream closed but connection is alive nw_flow_service_writes Failing write request <nw_write_request> [57: Socket is not connected] Task <3643AD6D-70F8-4862-B533-79F663D61C69>.<2> HTTP load failed, 555/0 bytes (error code: -1017 [4:-1]) nehelper sent invalid response: <dictionary: 0x1e6e8d320> { count = 1, transaction: 0, voucher = 0x0, contents = "XPCErrorDescription" => <string: 0x1e6e8d4b8> { length = 18, contents = "Connection invalid" } } nw_connection_add_timestamp_locked_on_nw_queue [C7] Hit maximum timestamp count, will start dropping events I've just updated to Xcode 16.3 RC 2 & tested (no change), RC Simulator runtime seems like hasn't changed from RC1. iOS 18.3 Simulator still works fine, even if launched from latest Xcode RC. Feel free to reach me if needed, I can test whatever I'd be able to, will continue investigating as well. 👍
Mar ’25
Reply to URLSession is broken in iOS 18.4 RC Simulator
I'm dealing with a similar issue now 🤔 also appearing on the 2nd and later app launches – only to discover that there's probably something about the SSL/TLS configuration conflicting with the web I'm attempting to display in WKWebView. Adding an Info.plist exception: NSExceptionRequiresForwardSecrecy = false; for the domain patched it for me for now, another option is setting configuration.websiteDataStore = .nonPersistent() on your WKWebView where applicable (which is probably similar to using ephemeral configuration on URLSession). Yet I guess none of these shouldn't really differ from the device behaviour & it's not an actual fix, could be just a hot patch for a wider variety of inconsistencies. Curiously it really only started failing with 18.4 Beta/RC Simulator, 18.3 is just fine, no matter the backing macOS (15.3.2 or 15.4 Beta/RC). Initially I found that clearing some caches (AlternativeService.sqlite file in particular) in app's sandbox (partially) recovered web views to be working, yet that wasn't really effective for a production hotfix. Thus I hope this will be addressed in the Release version of the Simulator. 🙏😄 Hopefully this could help somebody else dealing with a very mysterious issue during this Beta cycle. 🫠 Reported as FB16846380.
Mar ’25
Reply to TvOS18 Simulator is crashing with collectionview dequeue
I'm getting a crash for decoration views somewhere inside UIKitCore which is definitely out of my control – the code doesn't dequeue or care about instantiation of decoration views at all – all it does is inserting the registered layout attributes in the flow layout subclass, the rest of it (instantiation of the registered view & queuing/dequeuing) is provided by UIKit. I have a ton of crashes starting with iOS 18, not a single one on iOS 17 and prior. Call stack: Thread 1: "*** -[__NSArrayM objectAtIndex:]: index 4 beyond bounds [0 .. 3]" #1 0x000000018039c67c in -[__NSArrayM objectAtIndex:] () #2 0x0000000185a9aa54 in -[_UICollectionViewSubviewManager dequeueReusableViewWithReuseIdentifier:elementKind:elementCategory:] () #3 0x00000001851bc3cc in -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] () #4 0x00000001851a6ab4 in -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:layout:withLayoutAttributes:applyAttributes:] () #5 0x00000001851af69c in -[UICollectionView _createVisibleViewsForSingleCategoryAttributes:limitCreation:fadeForBoundsChange:] () #6 0x00000001851af824 in -[UICollectionView _createVisibleViewsForAttributes:fadeForBoundsChange:notifyLayoutForVisibleCellsPass:] () #7 0x00000001851ad9c4 in -[UICollectionView _updateVisibleCellsNow:] () Array index out of bounds. Definitely not an array in reach, very internal operations. This is also preceded by the following warning thrown into Console: UICollectionView internal inconsistency: attempted to queue view that is already in the reuse queue. Collection view: <TripItineraryDayCollectionView: 0x146917400; baseClass = UICollectionView; frame = (0 0; 402 682); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000e5d770>; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x600000393440>; contentOffset: {0, 0}; contentSize: {402, 662}; adjustedContentInset: {0, 0, 0, 0}; layout: <TripItineraryDayViewLayout: 0x1463d6770>; dataSource: <TripItineraryDayView: 0x1463d6360; frame = (0 102; 402 682); clipsToBounds = YES; autoresize = W+H; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x6000003974a0>>>; view: <TransportLineDecorationView: 0x1059e51a0; baseClass = UICollectionReusableView; frame = (14 257; 54 69); userInteractionEnabled = NO; layer = <CALayer: 0x6000004180c0>>; layout attributes: <TransportDecorationViewLayoutAttributes: 0x1463e34a0; index path: (2-4); element kind: (TripItineraryDayTransportDecorationView); frame = (14 257; 54 69)> Disabling the decoration views makes the crash go away. Something has probably changed in iOS 18 which might have sense for cells (where providing the views in the delegate properly is mandatory) or supplementary views, yet it doesn't work really well with decoration views. It gives me the impression that supplementary and decoration views have been merged into one queue stack internally, but something's not right.
Oct ’24
Reply to Crash in iOS18
I'm getting a crash for decoration views somewhere inside UIKitCore which is definitely out of my control – the code doesn't dequeue or care about instantiation of decoration views at all – all it does is inserting the registered layout attributes in the flow layout subclass, the rest of it (instantiation of the registered view & queuing/dequeuing) is provided by UIKit. I have a ton of crashes starting with iOS 18, not a single one on iOS 17 and prior. Call stack: Thread 1: "*** -[__NSArrayM objectAtIndex:]: index 4 beyond bounds [0 .. 3]" #1 0x000000018039c67c in -[__NSArrayM objectAtIndex:] () #2 0x0000000185a9aa54 in -[_UICollectionViewSubviewManager dequeueReusableViewWithReuseIdentifier:elementKind:elementCategory:] () #3 0x00000001851bc3cc in -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] () #4 0x00000001851a6ab4 in -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:layout:withLayoutAttributes:applyAttributes:] () #5 0x00000001851af69c in -[UICollectionView _createVisibleViewsForSingleCategoryAttributes:limitCreation:fadeForBoundsChange:] () #6 0x00000001851af824 in -[UICollectionView _createVisibleViewsForAttributes:fadeForBoundsChange:notifyLayoutForVisibleCellsPass:] () #7 0x00000001851ad9c4 in -[UICollectionView _updateVisibleCellsNow:] () Array index out of bounds. Definitely not an array in reach, very internal operations. This is also preceded by the following warning thrown into Console: UICollectionView internal inconsistency: attempted to queue view that is already in the reuse queue. Collection view: <TripItineraryDayCollectionView: 0x146917400; baseClass = UICollectionView; frame = (0 0; 402 682); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000e5d770>; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x600000393440>; contentOffset: {0, 0}; contentSize: {402, 662}; adjustedContentInset: {0, 0, 0, 0}; layout: <TripItineraryDayViewLayout: 0x1463d6770>; dataSource: <TripItineraryDayView: 0x1463d6360; frame = (0 102; 402 682); clipsToBounds = YES; autoresize = W+H; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x6000003974a0>>>; view: <TransportLineDecorationView: 0x1059e51a0; baseClass = UICollectionReusableView; frame = (14 257; 54 69); userInteractionEnabled = NO; layer = <CALayer: 0x6000004180c0>>; layout attributes: <TransportDecorationViewLayoutAttributes: 0x1463e34a0; index path: (2-4); element kind: (TripItineraryDayTransportDecorationView); frame = (14 257; 54 69)> Disabling the decoration views makes the crash go away. Something has probably changed in iOS 18 which might have sense for cells (where providing the views in the delegate properly is mandatory) or supplementary views, yet it doesn't work really well with decoration views. It gives me the impression that supplementary and decoration views have been merged into one queue stack internally, but something's not right.
Topic: UI Frameworks SubTopic: UIKit
Oct ’24
Reply to MainActor and NSInternalInconsistencyException: 'Call must be made on main thread'
This is pretty weird. While the synchronous variant with completionHandler gets called correctly on Main thread with a FrontBoardServices → UIScene call stack, the async variant get called on a random thread via swift_job_runImpl, assuming some behind-the-scene magic related to Concurrency causing this call to be…Tasked? Or anything calling it outside of Main thread. It affects us by causing crashes in production. We can temporarily fix this by downgrading to the synchronous variant with completion block, but I guess this should be escalated because it's causing issues from somewhere within the OS stack as the actual crash occurs in [UIApplication _updateSnapshotAndStateRestorationWithAction:windowScene:] which has to be somewhere around the thread-splitting moment, causing both our delegate call and the UIApplication call scheduled outside of Main thread. As this protocol is realated to UIKit-based protocol in the first place (even tho legacy one in Objective-C code base), it should be carefully held on Main thread to be in sync with @MainActor requirements of UIKit stuff. Cc @eskymo
Oct ’24
Reply to A bug in Xcode lldb debugger for swift
You could try fr v yourVariable to print a frame variable description – at least that is mostly working in these cases. But I only came here to note down this is still an issue in Xcode 14.2, and it becomes more frustrating than printing when I f.e. want an override like thread return myVariable to perform an early return with a different value, getting the same error message instead. 😕
Topic: Programming Languages SubTopic: Swift Tags:
Jan ’23