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

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.

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.

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

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

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"} ]

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.

it says the title is a string that is not optional But the compiler disagrees, as the error message basically says the title property is an Optional<String>. Can you show the definition of the Recipe type?

How about you flip the name around so the primary behavior (saving) comes before the secondary (checking): saveIfNeeded() or saveIfDirty(). Or build in a little more flexibility to disable the checking, such as for testing: func save(onlyIfDirty: Bool = true, completionHandler: SaveCompletionHandler) func save(onlyIfDirty: Bool = true) async throws

There’s no public API for any of that. See this previous discussion for more.

Can we add back a device once it's been removed via the reset? Yes. Your plan to wipe the list and then re-add individual devices as needed will work fine.

Do you mean in web pages you design (and view in Safari) or do you mean in an app you are building? For web pages that’s just what Safari does. For a custom app, take a look at the inputAccessoryView property on UITextField and UITextView.

Are we able to connect this Bluetooth Device using Core Bluetooth? The screenshots show it’s a BLE device and advertises that it’s connectable, so Core Bluetooth should be able to connect. (Assuming you haven’t tried yet.) The bigger question is: do you know how to use those services (0xFFE0 and 0xFFF0), if those aren’t your own design?

Are we able to connect this Bluetooth Device using Core Bluetooth? According to the screenshots it’s a BLE device and advertises that it’s connectible, so yes Core Bluetooth should be able to connect. The bigger issue is that once connected, do you know how to use those services (0xFFE0 and 0xFFF0), if not your own design?

I also tried to debug view hierarchy, but keyboard does not show in debugView. FWIW, I can see the keyboard window in the view debugger, but it’s in a special separate scene rather than the main scene. And in the memory graph I can find no path to access it. So this proposed hack would be not only tricky and fragile, but seemingly impossible. File a feedback asking for what you'd like to see but that currently does not exist Run the keyboard out-of-process like SFSafariViewController so people can’t even begin to try to hack it. 😉