The reviewer may have choked on the JAJAJAJAJ.

Off-topic, but I'm curious: what is the word you wrote that got censored to "****"? Doesn't seem like you would have used a profanity there.

You can't achieve that. The limitation imposed by this Info.plist design is to prevent apps from doing exactly what you are trying to do. For this you can thank certain rogue apps (of a different kind) that figured out years ago that they could survey installed apps to help feed their targeted advertising algorithms. That was a user privacy failure so Apple fixed it.

I've never played with CarPlay, but if you hang around the Apple developer world long enough you get a feel for these things. That's exactly the sort of API you shouldn't expect in a public SDK. If such an API exists, it would be available only to "Automaker Apps" (see here) and I'm guessing you're not actually manufacturing your own vehicles at this time.

Don’t assume anything about a beta that's not mentioned in the release notes. The good news is that your personal and/or mission-critical data is perfectly safe... because of course you would never install a beta on a device containing personal and/or mission-critical data in the first place, right? 😉

You can't. When the user explicitly kills an app, the OS shuts down the various background features it was using: fetch, URL sessions, location, etc. The app is very much dead until the next time the user explicitly launches it.

Try removing the alpha channel, per Creating Artwork and Copy for the App Clip Card. If that turns out to be the issue, also consider filing a bug report for the error message being correct but not complete.

Short answer: There is no public API for that information. Longer answer: Now we have reached the point in the discussion where a certain DTS engineer asks why you need this information, and if you are working on behalf of a wireless network provider. If you are, then it’s expected that you or someone in your organization already knows who to contact at Apple for further assistance.

You didn't miss anything on forum usage; indeed it’s a single stream of messages with tags. Personally I just check in a few times per day and scan through the full overview list to see if there's anything interesting.

That's the file format for an object graph serialized by the NSKeyedArchiver API. As you've found, it’s built on Apple's lower level property list structure, which uses XML, but it’s definitely not intended to be human-readable. The format isn't officially documented that I know of, but a quick search turned up these pages that may be helpful: https://www.mac4n6.com/blog/2016/1/1/manual-analysis-of-nskeyedarchiver-formatted-plist-files-a-review-of-the-new-os-x-1011-recent-items https://digitalinvestigation.wordpress.com/2012/04/04/geek-post-nskeyedarchiver-files-what-are-they-and-how-can-i-use-them/ There are a few approaches you could try. The various tools referenced from those pages purport to convert this format into something more usable, though you'd still need more processing to yield your data in the format you want, using the programming language of your choice. Or you could try to reverse engineer the app's data model from the metadata in the file (class names, inheritance, and member names) and then mock up an equivalent data model in a Swift program to deserialize the file directly.

Incompatible device is right: the iPhone 11 came with iOS 13 so it can't run any previous version. Tip: try to create the simulator via Xcode's Devices and Simulators window. It won't let you try to configure an invalid combination of hardware and software.

Generally I'd say that getting throttled by a rate-limited API like this is a good clue that you should consider a different approach. It’s not explicit in the documentation, but it seems logical that the MKDirections API is intended for user-initiated actions like getting directions to a location after searching in a mapping app. That's way less demanding than what your code is trying to do under the covers in the location manager delegate callback. One could try to evade the rate limit by self-throttling the calculate() calls as you mentioned, but that would be very fragile and unlikely to produce the real-time behavior you want. Note how the MKDirections documentation is deliberately vague on exactly what the rate limit algorithm is, so it could change in any new OS release. (The clues in the error dictionary are interesting but not official API.) Whatever it is, surely Apple intends to calibrate it to support presenting directions to a user and not real-time route recalculation.

As a first sanity check, it’s not missing. In a quick test here on Xcode 14.5.1, I am able to call std::to_string() in an Objective-C++ (.mm) file here. You do need to add #import <string> at the top of the file. You mentioned using CMake rather than building directly in Xcode, so maybe that's the difference. Can you validate the SDK support by making a minimal test app in Xcode that can access std::to_string() successfully? Assuming that works (so it builds via Xcode but not CMake) then I'd see if the CMake build environment may be including some standard headers (<string> in this case) that aren't included automatically in an Xcode build.

Is your team set correctly in the target's signing settings? Xcode seems to think the target's team is for a non-paid developer account. Don't use the one with suffix (Personal Team).

Oh dear. Is this exactly the command you entered, including the space before the final * character? sudo rm -rf /usr/local/mysql * As you have discovered, this command (with the mistaken space) basically destroys your user account and its local data. Hopefully by now you are well along on restoring or recreating everything from backup or from iCloud or wherever. This isn't the right forum for getting support on repairing your system. But let me ask this: where did you get the instructions that included that command? I can find a few "how to remove MySQL" instructions online that don't seem to include any obvious destructive mistakes like this. But if there is some page out there containing this mistake, it would be best to alert its author to get it fixed before anyone else suffers the same fate. Or if the mistake was introduced just when you were typing in the command yourself, well that's better, I guess.