Posts

Post not yet marked as solved
8 Replies
I have a similar issue. In my case, there is a package called GraphicsRenderer causing problems. During build, either Xcode Cloud or a fresh local build (done after xcodebuild clean), xcodebuild will claim it finds a new package called graphicsrenderer (the case matters here), but new package is not allowed when automatic package resolution is disabled. Then a fatalError is triggered and the build failed. Below is all speculation. I believe due to some bug in either Xcode or SwiftPM, xcodebuild treats GraphicsRenderer (which is the name recorded in my Package.resolved) and graphicsrenderer, which is the default name derived by Xcode, as two different packages. By the way, I failed to modify my Package.resolved to make Xcode believe they are the same thing. Notice that locally, a second run can happen smoothly, probably because some cache that helps Xcode correctly identify the two as the same thing. I found a not very practical workaround when attempting to creating a minimal case to report to Apple. That is, recreating your Xcode project using Xcode 14. It seems that a version 2 Package.resolved has been put in use since Swift 5.6. In that format, I can see there is an identity for each resolved package, and GraphicsRenderer has that field set to graphicsrenderer. I no longer face any issue. But I cannot get xcodebuild to generate a version 2 Package.resolved for my existing. My guess is that for any Xcode project, there is a minimum compatibility specified. My old projects were created with Xcode 13 and thus locked the version 1 Package.resolved. By the way, I have zero idea when this issue might occur. It certainly won’t happen for Apple packages, which all adopt an all lowercased naming such as swift-markdown. But this didn’t happen for GRDB and many other packages with capital letters.
Post not yet marked as solved
8 Replies
I am an AppKit noob with a UIKit background who just stumbled on the same issue. However, this unrelated StackOverflow question gives me some insight: you can override loadView of a NSCollectionViewItem and simply create any view programmatically: class TestViewItem: NSCollectionViewItem {     override func loadView() {         self.view = NSView()     } } I suppose this is the place where the default implementation from AppKit looks for NIB files.
Post marked as solved
2 Replies
It turns out that my very mistake is to use my own gestrue recognizer. It will somehow interfere with UITextInteraction’s. I am not quite familiar with the whole mulitple gesture recognizer, but I seem to have much to learn.Furthermore, the adoption of UITextInteraction will relieve me from drawing my own caret, selection, et cetera. So this is really great.