Apple Maps Guides

Hmmm, that’s not good. While I don’t want to engage in ‘blame the victim’ here, there is something you can do to reduce the risk of problems like this occurring in the future, namely, testing with beta seeds as they’re released. The beta seed programme exists to help us find and fixing regressions like this. Anyway, let’s see if we can find you a workaround. If you add this to your app’s entitlement, does it prevent the failure: A key of com.apple.security.temporary-exception.mach-lookup.global-name With the value being an array With a single string element Whose value is com.apple.storagekitd If that works, we can then talk about the App Review implications |-: Note Temporary exception entitlements have an interesting history. I have a couple of links in App Sandbox Resources that explain more about them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

As per the Suggestion, Created CLBackgroundActivitySession and CLServiceSession in foreground to keep Core Location active. Recreated those sessions on background launch/APNS. Persisted and restored fence definitions so CLMonitor can re‑register fences after background launch. But the restore only re‑registers fences that were already created before. If a fence is first created while the app is terminated and only launched in background, CLMonitor did not deliver the initial “enter” until a foreground session exists. Comparision with old CLLocationManager region monitoring: Old API (CLLocationManager region monitoring) is system‑managed. The OS keeps monitoring even when your app is terminated, and it can accept new region registrations in background because that API was designed around long‑standing background delivery. New API (CLMonitor with CLBackgroundActivitySession/CLServiceSession) is session‑based. Apple expects the session to be created in foreground and then restored in background. It’s op

Thanks for checking this. And I’m glad to hear that things are improving. [quote='876543022, TChrist, /thread/813973?answerId=876543022#876543022, /profile/TChrist'] We will provide a leaks report … from the 26.4 device in the Feedback. [/quote] Thanks. Although I think you might be better off creating a new bug for that. The current bugs were used to track the fix for the major memory issue that landed in 26.4 beta. The remaining minor leak is likely to have a different cause and thus it’s better to have a different bug. If you do file a new bug, please post its bug number here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can find your answer on the submission form. You select your runtime environment using a popup, and below that popup is this text: Xcode app playgrounds are run in Simulator. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

First up, I want to be clear about terminology. You don’t sign code with a certificate, you sign it with a digital identity, that is, the combination of a certificate and its associated private key. There’s no need to protect the certificate; it’s the private key that matters. I talk more about this in TN3161 Inside Code Signing: Certificates. Second, the Secure Enclave (SE) doesn’t store private keys. Rather, you protect a private key with the SE. The SE generates the private key and returns it wrapped in a way so that only that SE can use it. You then send key operations, like ‘sign this blob with this wrapped key’, to the SE, it internally unwraps the key, does the operation, and returns you the result. So the unwrapped key material never leaves the SE, but it’s not stored in the SE. Note This is how the SE works but it’s not true for other hardware-based keys. Notably, with a smart card the private key is actually stored on the smart card itself. Folks using the smart card don’t work with a wrapped key, t

I just attached an allocation trace to the FB I run with my productive app on macOS 26.2. Instruments is showing a peak of 128 MB allocated memory, while Activity Monitor is showing approx. 50 MB on macOS 15. Unfortunately, I wasn't able to collect a similar allocation trace with macOS 15.6.1: It's running in a VM, and due to restrictions of virtual machines I cannot register my Apple development account for proper application signing - but I'm happy to go this extra mile if DTS was able to provide related instructions. Looking forward to any response in the ticket...

[Different DTS engineer here; I’m picking up this thread because it’s directly aligned with my area of expertise.] [quote='876554022, Tenjikato, /thread/815899?answerId=876554022#876554022, /profile/Tenjikato'] it does not appear in Xcode Organizer. [/quote] Right. The issue here is that you have a third-party crash reporter installed and it’s failing to preserve the Apple crash report. Let’s look at the backtrace in your first post: Crashed: com.apple.main-thread 0 KSCrash … ksmemory_notifyUnhandledFatalSignal + 12 1 KSCrash … handleSignal + 100 2 libsystem_platform.dylib … _sigtramp + 56 3 libsystem_kernel.dylib … mach_msg2_internal + 76 4 libsystem_kernel.dylib … mach_msg_overwrite + 428 5 libsystem_kernel.dylib … mach_msg + 24 6 CoreFoundation … __CFRunLoopServiceMachPort + 160 7 CoreFoundation … __CFRunLoopRun + 1188 8 CoreFoundation … _CFRunLoopRunSpecificWithOptions + 532 9 GraphicsServices … GSEventRunModal + 120 10 UIKitCore … -[UIApplication _run] + 792 Frames 10 through 3 are all standard

We just posted a TN3179 update with info about the AllowedEthernetLocalNetworkAddresses and AllowedWiFiLocalNetworkAddresses user defaults. I think this might be useful in your situation, where you have limited control over the software involved but deep control over the Mac on which it runs. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm in the same situation. I submitted a week ago an app update. It stays in review since then with no updates whatsoever. I submitted a support case yesterday but no response either. It's really annoying. Apple has no shame asking for 99euros/dollars subscription a year but in return they are not able to provide proper support.

Same here. New app, Apple ID: 6748582437. Today is day 5 and nothing seems to move. In the past I had apps approved in a matter of hours!