Hold on, don’t run outside to play in the sleet just yet. The documentation for Precipitation.sleet (link) says: A form of precipitation consisting of ice pellets. That’s American sleet, and remember that Apple APIs and documentation generally are written in American English.

What OS/version is this happening on? I just tried it on iOS 16 simulator and the REPL in Monterey, and the URL gets created successfully. However, while unencoded apostrophe works (at least on these versions) indeed it’s a best practice to encode it. But that still won’t work in your specific example, because the URL of your actual page uses a curly quote (U+2019 RIGHT SINGLE QUOTATION MARK in Unicode-speak). That character also works unencoded, or is more properly encoded as %E2%80%99. Probably an even better practice would be to manually remove this character from the URL (which is obviously derived from the page title) if you have control over that.

That alert didn't come from iOS. You should double check your third party libraries. Maybe this is a stealth feature of one of them for some reason. (Maybe such a library secretly harvests user data and has determined that it’s out of date itself, and hopes your next app release includes a newer version that can secretly harvest even more user data. It’s explained more clearly using colored string on my conspiracy board.) Clues that this isn’t an Apple-authored alert: iOS doesn’t even have a feature to prompt users to update apps like this. The title yells at the user with an exclamation point. Apple doesn’t yell. The apostrophe is vertical rather than curly. Apple knows a thing or two about typography.

Sounds like an annoying change, but was the old behavior (the relative order of the notification and delegate call) actually documented? If not, then I wouldn’t be surprised to hear back from Apple that this isn’t a bug.

Well, does the “MAC” in “SQUADMAC” refer to Mac computers, like you’re a squad of experts on that particular platform? Or is it totally unrelated? If the former, then you’re probably out of luck. If the latter, then you can try to write up and submit a detailed explanation of what the name means and why it shouldn’t be considered a trademark conflict. Good luck.

why it works if i set .ascii instead of .utf8? That’s the critical clue here. It turns out that file is not encoded using UTF-8, and contains some bytes that are not a legal UTF-8 encoding. So the file is being downloaded just fine but the string initializer fails because it can’t handle those non-UTF-8 bytes. Note the file actually uses the Windows-1252 encoding, according to this line: <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> Specifically the issue is around line 551 which contains a degree symbol for latitude and longitude. It’s encoded as single byte B0 in the file, but in UTF-8 that would be the byte sequence C2 B0. So the most correct encoding to specify would be .windowsCP1252, though you’ve seen that .ascii also happens to work in this case since they are mostly compatible.

Using an example of code block formatting: is the second line here for real, or just a copy/paste error while redacting your code for the forum? — request.addValue("application/json", forHTTPHeaderField: "Accept") request.setValue("application/json", forHTTPHeaderField: "Authorization") Assuming a bad authorization header isn’t the problem, can you be more clear about what is going wrong? it doesn't record the information What does that mean exactly? Does the upload execute successfully (without hitting any of the error cases) and the data is simply not available on the backend? Or does it execute one of the error handling cases? If so, which one? Also (at least for next time) please try to cut down the code to the smallest amount that demonstrates the problem. That makes people more likely to read it and often helps to figure out the problem directly. In this case, the code for validating input and dispatching results to the UI isn’t relevant to the core problem and is best omitted when posting.

In your bug report, you could also mention the screenshot in the online user guide is even more confused about latitude and longitude:

I use the (navigator bar height + status bar height) to calculate the originY of the content view. That assumes the navigation bar always abuts the status bar with no gap or overlap, but I don’t know if that relationship has ever actually been documented by Apple. If that happened to be true for past models, it seems not to be true for the iPhone 14 Pro models for whatever reason. Maybe they just want the bottom of the nav bar, including the 1-pixel shadow below it, to fall on an integral point boundary. Sounds like you should use the bottom edge of the nav bar’s frame as the top of your content view. The status bar frame isn’t relevant to that calculation.

As you’ve seen in the other thread, there’s no documented support for this. But even worse, note that starting with iOS 16 the whole CTCarrier class is marked as deprecated with no replacement. All properties of CTCarrier will eventually return placeholder values “at some point in the future.” (Your carrierNames array elements will all be "--".) So it’s not too soon to start thinking about how you will handle this loss of functionality.

See also this thread about similar weird behavior for iPhone 14 Pro models with TestFlight.

There’s actually a form to fill out to request the entitlement. It’s linked from the documentation page for the entitlement.

Or does it mean it is yes if the app is built with iOS 15.4 SDK or later? That’s the one. This lets old apps keep working the same based on the default that was current when they were built, but as soon as you build a new app or an update, you’re now responsible for knowing about and handling the new behavior. Note it says linked rather than compiled, which implies that you (building the final app) are are responsible for handling the behavior change even if you use 3rd party libraries that were built before the behavior change and which may contain assumptions about the old behavior.

not sure I'm familiar with the "Standard" and "Zoomed" options you're referring to It’s an end-user feature so you access it within iOS itself: In the simulator, go to Settings → Developer → View On a device, go to Settings → Display & Brightness → View (or Display Zoom on iOS 16)

There are lots of great online resources for learning constraints, but for now the short answer is: the order doesn’t matter. Don’t think of constraints like an assignment operation in a procedural language. Rather, a constraint just expresses the result you want. The layout system then looks at the constraints and figures out a layout that satisfies them. In this case, the safe area is always fixed in position, so the system knows unambiguously exactly where the label should go: 326 points up from the bottom. But if you prefer, you can switch the order of the views to (say) make things more clear in Interface Builder. In the attributes inspector for the constraint, click on either First Item or Second Item and then select Reverse First And Second Item.