Just use the normal DateFormatter and you should get the new style in iOS 17. See this thread for more discussion.

You’ll probably get a gentle invitation to re-post this question in the user support forum, but on top of that: note the available emoji are defined in the Unicode standard which Apple simply uses. The Unicode Consortium presumably has some process for submitting feedback like this.

Looks like you encountered this known and reported bug.

Note that SCDisplay’s width and height properties are specified in points, while SCStreamConfiguration may expect width and height to be specified in pixels.

Is this the Xcode version I should install to work with macOS Ventura 14.6? Yes. What is the extension ".xip"? (See #3 in image above.) It’s a self extracting archive. After downloading, just double-click on the file and go grab a coffee.

try to avoid relying on the exact order of events @eskimo This could go with the topic of relying on undefined behavior that I proposed here.

See this thread for discussion of why you shouldn’t expect to find it. Why do you believe your project requires that exact version?

I can confirm your finding on iOS 17 and macOS Sonoma: JSONEncoder’s encoding of strings now stops at the first zero byte. It appears to be this bug which was introduced in the Swift rewrite of JSON encoding: JSONEncoder: Fixed escaping of certain strings. Since there’s no good workaround, is it feasible to change your blob encoding? Your current encoding scheme is pretty unusual. If you directly encode your image to JSON as a Data object, it uses base64 and just works.

Please help me understand why this change needed to happen. Because a hippie dropout named Steve Jobs audited a calligraphy class at Reed College in 1972. Seriously... sort of. That’s often cited as the genesis of Apple’s exacting quality of typography over the years. In this case, I’d argue that using a no-break space is a nice little improvement, so that (for example) 9:41 AM won’t get split across two lines if it falls at the end of a line in a formatted paragraph. Otherwise with a normal space, this could get split at a line break, which looks a little odd.

There is no API to discover the user’s phone number. That would be a massive privacy fail. (There used to be a non-deprecated way to get notified when the SIM is changed, but it still didn’t tell you the actual number. And it’s deprecated now anyway.) If @eskimo's suggestion in your other thread doesn’t satisfy your requirements, then I’d suggest you re-examine the requirements. Why are you trying to make the security of the app depend on hardware rather than than just user credentials? What is the threat you are trying to address? Just sayin’... I have lots of financial apps on my own phone from well-known institutions (banks, brokerages, etc.) and they all use the normal security features: username/password, Face ID, 2FA, etc. I’m curious why your app has requirements that go beyond this.

Look closely at the code example under Discussion in the documentation for registerForTraitChanges(_:handler:). Note that you need to specify the UITrait type(s) that represent the trait(s) you are interested in, which would be expressed like this: let traits = [UITraitUserInterfaceStyle.self]

Note that “deprecated” is not the same as “removed” — things marked deprecated generally continue to work fine in later releases. There are a few outliers that have changed more abruptly (e.g. fetching the device name or telephony information) but those tend to be privacy improvements and probably wouldn’t be grandfathered in an LTS arrangement anyway. Also note that users don’t expect apps to have “long term versions” that never get updated; active apps get new features or just bug fixes at least a few times per year and often every week or so. I personally won’t download any app that doesn’t appear to be in active ongoing development, judging by the release history.

Just embed the desired character directly in your localized string, the same as any emoji or other non-ASCII character. Consider: if the xcstrings format required using source code style escape sequences for non-ASCII characters, it wouldn’t be very friendly to anyone making localizations for most non-English languages in the world. So it just accepts all characters directly. Note the underlying format is JSON encoded in UTF-8, so it can store all possible characters.

Does this mean using a dot before an enum case name is just for show? Not quite. This compiles because allCases is declared in the same scope as the cases, so it knows what third is by simple name resolution. You could even declare allCases like this: static let allCases = [first, second, third] But if you were to use the cases outside the enum body, then the dot is needed to make them into implicit member expressions with type inference: let allStuffCases: [Stuff] = [.first, .second, .third] Or here’s another way to let type inference do its thing: let allStuffCases = [Stuff.first, .second, .third]

Try the Show only project-defined symbols button in the filter bar at the bottom of the symbol navigator. Or are you reporting that it’s not working? (Also note the symbol navigator was removed in Xcode 15.)