Do you mean the JSON decoding is throwing an error and landing in this catch block? } catch { print("could not parse json data") } If so, you should print out the actual error that is being thrown. What does it say?

This library is included. Maybe there is some incorrect path setting for it in your old project? Can you link a fresh test app using pthreads successfully?

See this thread for details on why /usr/lib looks a little thin these days. On my machine with Xcode 15.3 installed, the library is found here: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libpthread.tbd And with Command Line Tools installed, also found here: /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/lib/libpthread.tbd Note those are .tbd files, not .dylib any more.

it “closes” itself and returns to the originally intended app. Unfortunately that’s not a thing on iOS. Calling exit() is equivalent to just crashing, which always dumps the user back at the home screen.

See this thread for an answer. Having said that, also consider whether any network session APIs may meet your needs, such as allowsConstrainedNetworkAccess (link) and allowsExpensiveNetworkAccess (link).

Search in the More page there: https://developer.apple.com/download/all/?q=Additional%20Tools

Sounds like hang detection is active and doing its job. See this link for more. Can someone tell if it is possible to get rid of it and how ? Hang detection is a helpful feature so it’s best to leave it enabled. Then the “right way” to get rid of the warning is to update the app using the advice on that linked page, to eliminate the hang that is getting reported.

Can MetricKit support collecting these specific metrics at such frequent intervals? Unfortunately that iOS Network Signal Strength post already calls out MetricKit as an approach that won’t help. Note that MXCellularConditionMetric contains only a single property (see histogrammedCellularConditionTime at link) which is basically a crude bar chart of signal strengths aggregated over the 24-hour reporting period. There’s no API to get at the underlying data points or timestamps, and note this metric deals in signal bars rather than actual dBm units. I'm curious about how such an [internal Apple] app might collect data that is otherwise inaccessible through public APIs. Apple’s built-in apps can use whatever private APIs they want, and in many cases the OS has the means to allow access to such APIs by only specific apps (i.e. theirs or carrier apps) that are entitled to do so. For the specific case of accessing low level telephony data, the restriction was added as a security fix way back in iOS version 8.3 or so. So even if you had the secret header files or documentation, the code wouldn’t actually work without your app having that special entitlement which will never be available. is there any leeway or additional tools available for private/internal applications to gather more detailed cellular metrics? Nothing that would be documented by Apple or suitable for discussion on this forum.

Guessing that you mean some arbitrary other app not developed by your team: there is no API that can give you that information. Unlike on Android, the iOS platform has no APIs to discover what other apps are even installed [*], much less tell you anything about them. That’s example of how the concept of user privacy can differ between the platforms. [*] There’s actually a small crack in the armor with an API called canOpenURL (link) but it’s intended for a limited sort of cross-app integration, not for open-ended discovery of other apps, and tells you nothing about version numbers.

You’ll want to transfer ownership of the app from the old account to the new account; see here for details.

I have one here (model A1701) and can confirm that the iPadOS 18 beta isn’t available. The Settings → General → Software Update → Beta Updates menu does now include the iPadOS 18 Developer Beta option, but it has no effect.

Hear me out, developers at Apple! This forum isn’t an official channel for suggestions like this, so make sure to also submit a Feedback with your suggestion.

Start here: https://developer.apple.com/bug-reporting/ You can’t remove a forum post (unless there’s some pressing reason such as accidental disclosure of PII) but don’t worry about it.

btw, why make such a big deal about FlatBuffers in the session video if its strictly an internal implementation detail? I suspect the motivation is found in the transcript here: If you are using the Swift API, this optimization comes for free. While if you use the REST API, it is optional, and you can activate it by specifying an accept header. And here: If you are using the REST API, please consider taking advantage of the new FlatBuffer response. So they are telling REST API users to go grab FlatBuffers from GitHub for whatever platform they are using, while the WeatherKit framework of course remains closed source and just so happens to use FlatBuffers too.

Start here: TN3111: iOS Wi-Fi API overview. Especially note this part: iOS does not have a general-purpose API for Wi-Fi scanning and configuration.