I think you’re seeing a bug in initializing a CharacterSet with a multi-character string containing characters outside the Unicode Basic Multilingual Plane (BMP). In this case the emoji lives in the Supplementary Multilingual Plane with a 17-bit encoding, but the character set seems to lose the first bit. I get this in Swift REPL: 1> import Foundation 2> print(CharacterSet(charactersIn: "a")) <CFCharacterSet Items(U+0061)> 3> print(CharacterSet(charactersIn: "ab")) <CFCharacterSet Items(U+0061 U+0062)> 4> print(CharacterSet(charactersIn: "a\u{1F940}")) <CFCharacterSet Items(U+0061 U+F940)> If we assume the printed description is accurate, then the last line is clearly wrong: the string contains U+1F940 WILTED FLOWER but the resulting character set contains U+F940 CJK COMPATIBILITY IDEOGRAPH-F940 (a Chinese character). Given this broken character set, your diagnostic tests produce expected results. Oddly, this doesn’t happen if the string contains exactly one character. The description is formatted differently but appears to be correct, as 129344 == 0x1F940: 5> print(CharacterSet(charactersIn: "\u{1F940}")) <CFCharacterSet Range(129344, 1)> All this may relate to the known issue that NSString works differently from Swift String for characters outside the BMP because... reasons. Read the documentation around “extended grapheme clusters” if you want to dive into it.

There’s an undocumented-but-easy-to-search-for global defaults setting that controls cursor blinking in various apps in macOS. It does work for plain text fields within Xcode, but seems to have no effect in the main editor. You could submit a Feedback to request the Xcode editor respect this setting, or to just add a cursor blink setting directly in Xcode.

Can you point me to the right section of the dev portal? Please review again the information at Local Push Connectivity, particularly the box labeled Important.

Can I just manually edit the underlying xml file You can also just type the string freeform into the cell. There seems to be no validation during that step.

@eskimo: See this thread for more details. Basically the new file creation flow seems to work normally until the final save panel, but then hitting the Create button behaves as if you hit Cancel instead. Xcode keeps running fine but you get no new file and the project file is unchanged.

See previous discussion in this thread.

Yep it appears that DateComponents no longer implements Hashable correctly. In the Swift REPL on Sonoma I get this: 1> import Foundation 2> var dc1 = Calendar.current.dateComponents([.year, .month], from: Date()) 3> var dc2 = DateComponents(year: 2024, month: 1) 4> print(dc1 == dc2) true 5> print(dc1.hashValue == dc2.hashValue) false The rule is: if two values are equal (according to their Equatable implementation) then their hashValue must also be equal. As seen here, this doesn’t hold. Here’s a clue to the cause: 6> print(dc1.isLeapMonth) Optional(false) 7> print(dc2.isLeapMonth) nil Looking at the source code here shows that hash(into:) does include isLeapMonth in the hash calculation. And now we can test that theory: 8> dc2.isLeapMonth = dc1.isLeapMonth 9> print(dc1 == dc2 && dc1.hashValue == dc2.hashValue) true

this has halted our development Note that creating a File Type: Empty File still works, so this bug should be only an annoyance and not a showstopper until it gets fixed.

What is this line? What is IMUtil? Is the returned value of myDate what you expect? let myDate = IMUtil.stringtoDateConverter(startDateString: strdate) BTW, for working with fixed-format dates, see this thread and consider using ISO8601DateFormatter.

But this should be considered accessing a private view hierarchy (the containment for your view controller) which apps shouldn’t do. Note the superview is a UIViewControllerWrapperView which is an undocumented class internal to UIKit. If it’s not a view you create in your app, then it’s not safe to go add subviews to it or expect any particular behavior from it.

This is mentioned in the Apple silicon porting guide: On Apple silicon, the compiler defines the BOOL type to be a native bool, but on Intel-based Mac computers, it is a signed char. But even though it works on Intel, I’d suggest that overloading that way could result in a confusing and error-prone API.

Can you clarify “recent versions” and “lower deployment target”? On a 17.2 simulator (iPhone SE 3rd gen.) I still see this option under Settings → Developer → View. Note this isn’t the same Settings path as on a real device.

Please see TN3111: iOS Wi-Fi API overview.

Nobody can help with the error information in that format; please see points 5 and 8 in Quinn’s Top Fourteen DevForums Tips. But looking at the code, the signature for your delegate method isn’t correct: func centralManager(_: CBCentralManager, didDiscover: CBPeripheral, advertisementData: [String: Any], rssi: NSNumber) -> [Int] The return type of [Int] doesn’t match the protocol requirement (of no return type) and doesn’t make sense. This should have caused a compiler warning. If this method is actually getting called at run time, then the unexpected return value may cause undefined behavior, which could include sending your app off the rails with weird errors like that. What is the purpose of return BeaconRSSI in that method? Where is it attempting to return that value to? Even if it weren't crashing, Core Bluetooth calls the delegate method just to inform you of something (discovery of a peripheral) and wouldn’t know what to do with any value returned from it.

Does this thread describe what you are seeing?