Post

Replies

Boosts

Views

Activity

Xcode 15.3 crippled with "internal inconsistency error"
Since Xcode 15.3 it has become impossible to build our project more twice in a row without encountering a batch of "internal inconsistency error: never received target ended message for target ID …". This issues appeared a few months ago (15.0 i think, but i'm not sure), but xcode 15.3 makes it almost unusable. We're a team of 3 iOS devs, and we're all having the problem. Our project involves a lot of SPM packages, a few cocoa pods, a few iOS Frameworks, and a bit of swiftgen. Nothing particularly special for a large project, and no custom build steps that does anything fancy. It is now to the point where we're looking for alternative to xcode, because we can't decently kill xcode and restart every time we have to build our code...
23
17
9.6k
Mar ’24
URLSession invalidateAndCancel() doesn't release delegate as documented
This test doesn't pass, and i'm wondering why. It looks like the url session isn't releasing its delegate after invalidateAndCancel() is called, contrarely to what the documentation says. I've tried adding some dispatch.async in case this would be due to some event loop side effects to no success. import XCTest final class URLSessionTests: XCTestCase { @objc class DelegateObject: NSObject, URLSessionDelegate { var onDidBecomeInvalid: (() -> Void)? lazy var urlSession = URLSession(configuration: .default, delegate: self, delegateQueue: nil) func urlSession(_ session: URLSession, didBecomeInvalidWithError error: Error?) { onDidBecomeInvalid?() } } func testURLSessionRelease() throws { weak var del: DelegateObject? let didBecomeInvalidExp = expectation(description: "did become invalid") func instanciateDelegateObjectAndInvalidateSession() { let t = DelegateObject() t.onDidBecomeInvalid = { didBecomeInvalidExp.fulfill() } del = t t.urlSession.invalidateAndCancel() } instanciateDelegateObjectAndInvalidateSession() wait(for: [didBecomeInvalidExp], timeout: 3) XCTAssertNil(del) } }
12
0
2.1k
Oct ’22
shared HTTPCookieStorage flushing , session cookies
After a few experiments with HTTPCookieStorage.sharedCookieStorage , it seems that the behavior for the storage in that scenario involves some kind of OS flushing / synchronisation: There seem to be cases when the storage is updated, yet the updates aren't visible. Examples are: update by a process not visible by other processes from the same app group, hard crash / killing, etc. This all led me believe that there is some caching involved (of course, i can only guess, as the documentation provides 0 clues on internals). In some cases, such as authentication session cookies, this could have disastreous consequences (such as login out a user for no reason). => Is there some kind of way to force the flushing on the cookies, for the important ones ? Are there recommended alternatives for storing authentication cookies shared accross apps and extensions (keychain ?)
1
0
686
Jul ’22