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.

Start here: TN3111 - iOS Wi-Fi API overview.

That’s great news!

Your JSON file contains a single Menu object, but your code is trying to decode it as an array. The type to decode should be Menu.self rather than [Menu].self. Then maybe check if your menu property should still be an array of Menu that probably only ever has one element, or just a single Menu. Or if the JSON could actually contain multiple Menu objects, then the server should always include the array brackets even when there happens to be only one.

Now a question back at you is: why do you want this information? Is there a location capability your app requires beyond what Core Location already provides? And here’s a 7th and more recent item for your list: https://developer.apple.com/forums/thread/691886 From that discussion, note that “satellite count” may not even be meaningful in all cases where location data is available. Core Location does the hard work of abstracting away all the complex technology that goes into determining your location, to give you a simple “you are here (in this circle)” result which all that most apps need.

I updated but it didn't fix macOS: Big Sur 11.7.7 Xcode: 13.2.1 The question isn’t entirely clear. Did you update to Xcode 14.1 or later? As the error message says, Xcode 13.2.1 can’t build for the App Store any more.