It’s a little surprising that usage: .weather isn’t respecting your locale settings, but if your goal anyway is to override the locale and always use ºC, then use usage: .asProvided.

Nope, that’s not valid JSON. The top level is an object (starts with curly brace) so it needs to contain keys and values. But you can have an array as the top level in the JSON document, like this: [ {"id": 1, "name": "Otto Matic", "icon": "", "developer": "Pangea Software"}, {"id": 2, "name": "Minecraft", "icon": "", "developer": "Mojang"} ]

That’s often called a HUD or heads-up display. Here’s one library that implements that sort of thing: https://github.com/jdg/MBProgressHUD

I’m sure you realize this, but looking for a technical fix for this is almost certainly not going to be fruitful. It’s a new major OS release and Apple decided to improve their text layout logic, and of course they are perfectly free to do that since there’s never been any guarantee of pixel-perfect consistency across releases. I’d be floored if they really decided to add a Text Kit 1 compatibility mode in order to address what you must admit is an edge case not relevant to the overwhelming majority of apps. The real issue, of course, is that someone in your organization unfortunately committed you to a requirement that’s technically infeasible. Aside from finding someone on the other side of the negotiating table who understands and accepts this (that your app isn’t a game and doesn’t draw all the pixels), don’t expect an easy solution. (But I’d love to be wrong. Maybe someone with an  in their username will chime in and disclose an undocumented API that does exactly what you need. 😉)

My takeaway from those videos is this: UITextView needs a TextKit 1 compatibility mode because its existing API lets you access the underlying TextKit 1 objects, most notably the layoutManager property. If they removed support for that, then existing code would break. In contrast, UITextField and UILabel never had API for accessing the underlying TextKit 1 objects. So updating the implementation to use only TextKit 2 can’t break existing code. For your pixel-perfect problem, at least TextKit 1 isn’t going away, so you could build your own drop-in UILabel replacement, using either UITextView in TextKit 1 mode or a plain UIView with a whole TextKit 1 stack implemented inside. Not exactly trivial but you would be back in full control.

It’s true, all of it. In this line you are telling the decoder to expect an array of MemberModel objects: let informations = try JSONDecoder().decode([MemberModel].self, from: data) But the JSON you showed is a single JSON object, not an array of them. If you want to decode a single object, then specify the type to decode as MemberModel.self rather than [MemberModel].self.

Believe the documentation. That note specifically addresses the sort of unsupported hack you found elsewhere online.

Actually according to the documentation both direction and compassDirection should refer to the direction the wind is coming from. Respectively, Direction the wind is coming from in degrees, with true north at 0 and progressing clockwise from north. ...and: General indicator of wind direction, often referred to as “due north”, “due south”, etc. Refers to the direction the wind is coming from, for instance, a north wind blows from north to south. In the example Wind object: WeatherKit.Wind(compassDirection: East, direction: 90.0 °, speed: 7.09 km/h, gust: Optional(18.18 km/h)) It’s indicating “wind out of the east” (as a simplified weather report may phrase it), specifically from compass direction 90º, which is due east. A wind blowing from due west would be blowing from a direction of 270º.

I think the wind API should be interpreted as documented, and you’re just seeing bad data as mentioned in your other post. In simple testing here, I get perfect agreement between the iOS 16 Weather app and WeatherKit for various test locations (including Penticton, BC), but disagreement between those and the iOS 15 Weather app. In particular the wind direction there is roughly backwards between the two.

Are you sure WeatherKit doesn’t match the Weather app in the iOS 16 beta? I just tested and got perfect agreement between WeatherKit and the app. Then of course I’m seeing minor disagreement with the iOS 15 Weather app, which is to be expected since the underlying data source is different.

How are you formatting those time strings? You would need to use a date formatter with the time zone set correctly. WeatherKit uses the good old Date type and (in my testing here) they are correct, whether I view them in the debugger or print them using a date formatter set to my time zone.

Scratch that. Now I’m going with the theory (commented in your other thread) that your chart is correct but actually showing weather data from somewhere else. If the longitude were flipped from 119ºW to 119ºE then it would designate a place with the same season and the same daily sun cycle, just shifted about 8 hours behind. This could explain all the weird results you’re seeing.

That will work. Elsewhere the documentation makes it more explicit: WeatherKit requires iOS 16, iPadOS 16, macOS 13, tvOS 16, or watchOS 9. REST APIs can be used for websites and other platforms. Older versions of iOS would fall under “other platforms”.

Your NSExceptionAllowsInsecureHTTPLoads key is in the wrong place. It needs to be a child of the domain key (your redacted red item) rather than a child of the Exception Domains key which is one level up. It should look like the last screenshot shown on this page. Tip: In Xcode’s property list editor, to add a key to a dictionary, make sure to expand the dictionary (so the disclosure chevron points down) before you click the ⊕ button. That will create the new key as a child of the current row. Otherwise (if not expanded) it will add the new key as a sibling of the current row, which may have happened in your case.

if the calling code was already on the main thread, and the function they called also called the DispatchQueue.main.async, it seems like that call was delayed/not-called, and being requeued on the run loop for the next call. That is correct behavior, not a bug. No matter what queue you are currently executing on, the async() call just adds your closure to the target queue and returns. Is there any better way to debug this? No magic bullet here, but I’ve found this function is handy for verifying assumptions about what queue you are executing on: dispatchPrecondition(condition: .onQueue(.main)) // or whatever queue you want to check