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

I haven't received the latest Beta Software version which is 17.0.1. There was no beta for 17.0.1. You need Settings → General → Software Update → Beta Updates: Off in order to see it.

The code in that article is still correct. It’s this line in the test which is going wrong: print(s?.isBlank) This unwraps the optional s and then calls isBlank only if s was non-nil. If s was nil then the result of the entire expression is nil. Note this isBlank method is defined in an extension on String, which is given in the article but not shown here. To test this correctly, the line should be this: print(s.isBlank) This calls the isBlank method which is defined in the extension on Optional<String>. It’s totally separate from the other isBlank.

It was my 2nd time already, I am frustrated. I asked [App Review] to give suggestion and it refuses. Right. They mostly just review apps and apply the guidelines. But someone from App Review did make an excellent tech talk video on this topic: Write clear purpose strings.

The fine print on the iPadOS 17 product page says this: Available in English (Australia, Canada, United Kingdom, U.S.) on iPad and on AirPods Pro (2nd generation). Does this match your setup?

Well that’s weird. Your test case is working correctly for me here in Xcode 15.0 (15A240d) on a Mac with M1 Max. Does the behavior change if you format the literal as @(-1) with parentheses? Can you format the key via some code (like a number formatter) to confirm the issue is really the compiler, vs just an issue in the debugger? That value 18446744073709551615 happens to be 2^64-1, the same bit pattern as -1 in a 64-bit signed integer. Maybe that’s a clue.