Seeing different behaviour when similar code is presented in a Mac app and either a Mac Playground or command line app. The objective is create an array of range references into a string. /* Define a string */ let source = "Hello" /* Define an array that is a collection of ranges within the string. In this case use the whole range. */ let array = [source.startIndex..<source.endIndex, source.startIndex..<source.endIndex] /* Iterate */ for r in array { ... } This works in the Playground and Command Line versions but in a Mac app, the same code produces: For-in loop requires 'Range<String.Index>?' to conform to 'Sequence'; did you mean to unwrap optional? The Range<String.Index> items in the array are themselves not Sequences. Unclear why essentially the same code loop is producing an error message when used in the Mac app but no error for the Playground or command line. Nothing defined is an optional. Experimented with 12.1 and 12.2 - same results so far. Has anybody seen anything similar?

Are there any known reasons why a single NSFilePresenter instance has its presentedItemDidChange function called twice when the contents of the file is rewritten just once? Big Sur 11.2.3 I have extracted out the functionality into a reader and writer app and currently can't reproduce the issue in a simplified case. But when it is put into a full app context, I can see that two separate threads are initiating the call to presentedItemDidChange(). Checking file size and date modified show that they should be identical files. Only writing a string into a file, so not changing the file in any other way. So it doesn't seem to be two changes being made to the file. I only have one instance of the NSFilePresenter, it is referencing a file, not a directory. Breakpointing at presentedItemDidChange shows that the framework is going through an identical call sequence. But it's happening in two different threads. Not currently using any file coordination since there's only one file and one write operation. The meta data would suggest that it's not emptying the file, then writing it, causing two events 1) when the file size goes to zero and then 2) when the file is written and closed. Checking the file presenter object, and there's only one instance and the same sender object is defined. So it looks like the framework is triggering twice from two different threads. I don't have multiple processes or multiple file presenters. So unclear why two different threads are originating this.

Tracking down some errors in ValueTransformers in an old project. It seems that String.self can't be returned as AnyClass since it is a value type. So this works in Xcode 12.5: func test() - AnyClass { // just for checking     type(of: NSString.self)     type(of: String.self)     type(of: NSNumber.self)     return NSString.self } But this doesn't: func test2() - AnyClass {     return String.self } Cannot convert return expression of type 'String.Type' to return type 'AnyClass' (aka 'AnyObject.Type') So back to the ValueTransformer. This was the code that seemed to compile circa 2016. Now has a warning that it will fail. override class func transformedValueClass() - AnyClass {   return String.self as! AnyClass } String is a struct not a class. And doing this produces an error - because String is a struct override class func transformedValueClass() - AnyClass {   return String.self } So is the correct approach to work with NSStrings in ValueTransformers? Simply cast the last return with: return swiftNSString(utf8String:string) Similarly, Bool is also a struct and has the same issues. But BOOL isn't available so it looks like NSNumber.

I have a Share Extension project that is working fine in Monterey but fails to appear in the Share Sheet for Ventura. It is a simple text share. Are there any obvious changes to the info.plist requirements in Ventura? Debugging output isn't giving any obvious clues (there's a lot from the host application). Starting from scratch with a clean project and using the default (not-for-release) NSExtensionActivationRule TRUEPREDICATE works. Using Strict = 1 and DictionaryVersion = 2 works for Monterey but is causing a crash on Ventura, which suggests something that used to work isn't anymore.

fault: Illegal attempt to return an error without one in /Library/Caches/com.apple.xbs/Sources/Persistence/sqlcore/NSSQLCore.m Has anybody seen this error message before? Totally unclear what is causing this. Fairly straightforward core data / CloudKit / SwiftUI app. The app doesn't crash it just locks / freezes the screen on a SwiftUI app. A list view becomes unresponsive - it no longer scrolls. https://stackoverflow.com/questions/75944617/icloud-app-hangs-crashes-if-user-signs-into-account-while-app-is-running it's more than just me....

I have an app that has lots of booking dates. I need a quick way to open the Mac Calendar on the date of the booking just so the user can cross check the dates for clashes. At this stage, I don't need to build UI into my app that shows the dates. What is already in Calendar is sufficient - don't reinvent the wheel. A long time ago, calshow seemed to be the way to do this. But that seems to have withered away. Opening a URL with ical:// opens calendar, but not at the date required since there seems to be no URL scheme defined. I could query Event Kit, but that means building unnecessary UI at this time. There's possibly a way to do this with Scripting Bridge and probably a way to do this with a call to an AppleScript. Is there no simpler way to do this in 2023 on a Mac?

Looking at having editable text as the detail view within a master detail interface. There are various examples out there that show how to build the NSViewRepresentable wrapper around NSTextView. e.g. https://developer.apple.com/forums/thread/125920 However, when I try to embed the NSViewRepresentable within a NavigationSplitView the various examples (and my own attempt) don't work properly. There seems to be a race condition competing to update the internal bindings. I also see updateNSView being called multiple times when only one event, say selection change, is called once. Using the SwiftUI TextEditor view actually works. (it is just so limited) When the master selected item is changed the change isn't automatically propagated through to update the Coordinator. That's because there isn't a delegate for "master did change". Take any of the TextViews on their own (not within a split view) and they work as you would expect. The SwiftUI TextEditor does this without any obvious connection to the master. So the first question is: has anybody solved this type of problem? I haven't yet found a link to the solution or a discussion on the internal trick to make this work. In principle the view structure is: NavigationSplitView { // master list List(selection : $selectedItem { } } content: { TextEditor(text: $selectedItem.text) // works // or CustomTextView(text: $selectedItem.text) // all examples I've found so far fail to properly display changes to the text when edited } My current thought is that the internal Coordinator needs to know that there has been a selection change so you can synchronise the significant change in the contents of the text binding. Again TextEditor doesn't need to know that. makeNSView is only called once, so there isn't any regeneration of the NSTextView that you could rely on. Have tried on both macOS and iOS and see the same results.

Porting some Core Data code that was written several years ago. It has an entity called Transaction. This pre-dates Transaction that appeared in Animation. So Apple is now colliding with my naming. Looks like light weight migration isn't going to do the trick and I need to do more work for migration to work. Checking whether there is some magical use of namespace where I could separate my entity use of Transaction. Or it's full weight migration...

On macOS I'm seeing that only one .fileImporter modifier is called when two are defined. Anybody seeing the same issue? The scenario I have is two different file sources share the same file extension but they need to be loaded by two slightly different processes. Select the first option. Nothing happens. Select the second option, it works. Seeing this also in another project. Because the isPresented value is a binding, it isn't straightforward to logically OR the boolean @States and conditionally extract within the import closure. @main struct Dual_File_Importer_ExpApp: App { @State private var showFirstDialog = false @State private var showSecondDialog = false var body: some Scene { DocumentGroup(newDocument: Dual_File_Importer_ExpDocument()) { file in ContentView(document: file.$document) .fileImporter(isPresented: $showFirstDialog, allowedContentTypes: [.commaSeparatedText]) { result in print("first") } .fileImporter(isPresented: $showSecondDialog, allowedContentTypes: [.commaSeparatedText]) { result in print("second") } } .commands { CommandGroup(after: .importExport) { Button("Import First") { showFirstDialog.toggle() } Button("Import Second") { showSecondDialog.toggle() } } } } }```

Experimenting with #Playground macro with Xcode 26 beta 3, out of the box I see a conflict between duplicates in the XcodeDefault Toolchain. Essentially a clean install of macOS Tahoe 26 25A5306g FB18930059 Was trying to follow the first Foundation Model WWDC video example but distilling it down to the most basic use of the Playground macro produces the same error. import Playgrounds #Playground { } Any solutions / workarounds? Wasn't sure whether to attempt to delete one of these–but they are internal libraries. objc[3241]: Class PGLConcurrentMapNode is implemented in both /Applications/Xcode-beta 3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/Developer/Platforms/MacOSX.platform/Developer/Library/PrivateFrameworks/PlaygroundLogger.framework/Versions/A/PlaygroundLogger (0x10db98c10) and /Applications/Xcode-beta 3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libLiveExecutionResultsLogger.dylib (0x10db18050). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed. error: Couldn't look up symbols: protocol descriptor for Playgrounds.__PlaygroundsContentRecordContainer```