Id be very thankful if anyone can help. Actually nobody can really help yet, because the try? in this line silently eats the thrown error: guard let loadedData = try? decoder.decode(T.self, from: data) else { You should move the decoding into a do / catch block, and then you can examine the error that gets thrown. What does it say?

add a subview in the keyboard, but it's hard to position correctly and has some side effects And note that in iOS 17, the keyboard runs outside your process. (See WWDC video Keep up with the keyboard.) So the unsupported technique of adding subviews to the keyboard may not even work at all any more.

Undocumented If a function happens to be visible to the compiler but is undocumented, then (1) why are you calling it?, and (2) what do you expect it to do? Swift? In this case, it’s not a function intended to be used from Swift programs, and especially not from SwiftUI. It’s actually an ancient C function in the underlying Darwin OS that happens to be available (maybe it could be useful to some types of program) but has no practical use. If you view the documentation (via man pause) then the manual page is dated 1993, and says the function first appeared in Version 6 AT&T UNIX which dates from 1975. Groovy! And the description in the manual page shows that what this function does is definitely not what you would want. Private API? Bug? Security flaw? I’d vote “not really” to all of those, but one could probably engage in a very nerdy discussion around that.

Did you get a deprecation warning when compiling? If so, it should include a helpful message. Or you can look in the SDK header file UITextView.h (the source of truth) where there is a new annotation that generates the message: API_DEPRECATED("Replaced by primaryActionForTextItem: and menuConfigurationForTextItem: for additional customization options.", ios(10.0, 17.0), xros(1.0, 1.0));

It sounds like you have encountered this behavior.

You almost have it. Note that JSONSerialization is all class methods, not instance methods, so you call it like this: let someArrayOrDictionary = try JSONSerialization.jsonObject(from: myDataObjectContainingJSON)

Yes, but... the corresponding page for tvOS (link) says: Please note that starting July 31, 2023, all tvOS apps submitted to the App Store must be built with Xcode 14.1 and tvOS 16.1 SDK or later.

Hmm, sounds like there aren’t great options for solving this. Is the MAC address at least printed somewhere on the accessory? One not-so-great idea would be to have the user “scan” the accessory’s printed MAC address for you using their eyeballs and fingers. The doc for NEHotspotConfiguration(ssidPrefix:) says the prefix must be 3 characters minimum, so you could get by with having them enter only the first 3 characters, or even just the first 2 if you know that the 3rd is (for example) always : or -. Or you could even try to scan a printed MAC address using the Vision framework. I’ve never used it but it sounds cool.

Binary value "11100010 10000000 10101111" In hex those bytes are E2 80 AF, the UTF-8 encoding for Unicode U+202F NARROW NO-BREAK SPACE. So that’s a plausible character to use for putting space between words when formatting a string. In documentation also have the [good old ASCII space character] “00100000” If you mean the space in the example string “3:30 PM” then notice it’s labeled as an example, not as any sort of API you should rely on. Dateformatter issue with short style What is the issue? If you are trying to parse the formatted date string and expecting to find a specific character (e.g. an ASCII space between words) then you shouldn’t do that. That would be a form of undefined behavior, since the exact output of the date formatter isn’t documented, and in fact can be very different across languages and locales. In this case it sounds like they decided to improve the typography of formatted dates a little. If you just display the formatted string as-is then it should still work fine.

BTW, it’s preferable to continue the conversation via a thread reply rather than a comment; see tip 5 here. Apple won't approve the Hotspot helper. Right, since it sounds like you are making an accessory rather than a hotspot for accessing the Internet. So you would fall under the Add an accessory to the user’s network case, which basically amounts to the Temporarily join a network case since you’re not doing WAC or HomeKit. These cases don’t require the entitlement. Mobile app will then scan all available local wifi’s looking for a SSID that matches the a MAC Address Do you mean the SSID is the stringified version of the MAC address? And do you know it in advance, such as from scanning a QR code on the accessory? If so, then you can use NEHotspotConfigurationManager to connect to that known SSID. Or if the SSID has at least a known prefix (e.g. AcmeAccessory_) then you can use that.

Background execution on iOS is very different from Android and there is no equivalent to the autostart option you mentioned. To start evaluating the feasibility of what you are proposing, read this document very carefully: iOS Background Execution Limits.

Simulator with Ios 16.5 does not exists ? Correct. See this thread for discussion of why, and for other ideas on troubleshooting your problem. my tethered iPhone running 16.5, and Xcode 14.3.1 will not connect. That’s unexpected, as plenty of people can report that setup “works for me.” Maybe start a new forum thread for troubleshooting that problem.

Any idea about a technical workaround ? If @eskimo says “[There] is no API to get that” – believe it. my client wants an app that [does some unusual stuff] Unfortunately you’re in the position of needing the manage the client’s expectations. We get that a lot around here. Generally speaking, preflighting network access like this is discouraged on iOS. If possible, just proceed with your app’s desired network access and handle any errors gracefully. Remember that even if you could detect the Wi-Fi switch, and even if you used something like NWPathMonitor to check for network access, then any given network access could still fail for any reason. So first make sure the app is rock solid in those scenarios. Also, why specifically check for Wi-Fi? Is the app intended to be unusable over cellular data? That may be another of the client’s desires that could use a review.

Can you show the full code between the convertToJSONString() call and the point where you (seem to) print the result to the console? Are there multiple threads/queues running this code simultaneously? Anything unusual at all? If accurate, this suggests JSONEncoder is generating invalid JSON, and that’s not something I recall anyone ever reporting before. Very strange.

What version of Xcode are you using? Note that using if as an expression is new in Swift 5.9 and requires Xcode 15. If you are in Xcode 14 or earlier, then you can use one of the solutions given above. Unfortunately the default language book on Swift.org is for 5.9 already and I can’t even find an older version.