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.

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.

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.

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

See previous discussion in this thread.

@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.

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.

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.

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.

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.

trying to understand there is a different results when checking the two strings "a🥀" and "a😀" And those two emoji would produce different results in your letters test because: U+1F940 WILTED FLOWER gets corrupted to U+F940 CJK COMPATIBILITY IDEOGRAPH-F940 which is actually categorized as a letter in Unicode: 1> print("\u{F940}".unicodeScalars.first!.properties.generalCategory) otherLetter U+1F600 GRINNING FACE gets corrupted to U+F600 which is not a valid Unicode character (it’s in a “private use area”) so it’s not a letter: 2> print("\u{F600}".unicodeScalars.first!.properties.generalCategory) privateUse

Arguably it’s even more confusing: not even considering combining sequences, NSString is indeed basically “UTF-16 code unit string” and doesn’t process surrogate pairs (for code points outside the BMP) for operations such as length. But then NSCharacterSet does actually support surrogate pairs and all the supplementary planes, aside from the bug that @Amiorkov encountered here. BTW, you can actually see the bug in Apple open source in CFCharacterSet.c. In the specific scenario of creating a character set of both BMP and non-BMP characters, you end up in CFCharacterSetAddCharactersInRange() which assumes the range is in BMP and silently truncates the range’s location (starting code point) to 16 bits while appending to the existing string of BMP code points.

Do you mean update that key via code while your app is installed on the user’s device? That’s not possible. Two issues with that: Your entire app bundle is read-only so you can’t modify Info.plist or any other file at all. LSApplicationQueriesSchemes is thus also read-only because its whole purpose is to minimize abuse of the canOpenURL API. Previously, apps could use it to scrape a list of other apps that are installed on the device. So their stance is: you aren’t allowed to do that any more. The limit of 50 entries is a simple compromise to allow legitimate use of canOpenURL without letting malicious/advertising apps get away with scraping too much information. What exactly are you trying to accomplish?

See here for some background on why you shouldn’t expect to find a simulator for every release. And can you clarify: does your app not crash on 17.4 beta? Have you locally tested your app in Release build (which is what TestFlight users get) in addition to the usual Debug build you use during the edit/debug cycle? Have you tested on a real device running 17.3? Do you have crash reports from TestFlight that shed any light on the cause of the crash?

Was sent here when I asked in the general forums and they pointed out I was running public beta, so had to ask here. That’s bad advice over there. This forum isn’t the right place for troubleshooting app issues, whether on beta or on an official release. According to the beta FAQ, about all you can do is this: When you experience an issue or something does not work as expected, send your feedback directly to Apple with Feedback Assistant.