I've got an app which has a notification service extension (and has had so for a few years). I noticed that the pushes were getting delivered directly to the user for a handset, and in the log could see a SpringBoard error saying Error Domain=PluginKit Code=4 RBSLanchRequest error trying to launch plugin Error Domain=RBSRequestErrorDomain Code=5 Launch failed ErrorDomain=NSPOSIXErrorDomain Code=111 Unknown error:111 I rebooted the phone and it started working as expected. But it's worrisome this happened, and it's not the first time I've seen it either. Observed with iOS 17.3.1

I'm getting Sandbox:rsync.samba deny errors trying to build an app using Xcode 16 betas. There's lots of info on this on google, and the solution everybody used to fix it is to change the Xcode build setting User Script Sandboxing from NO to YES. However this doesn't exist with Xcode 16. Does it have a replacement?

If using Xcode beta 16 beta 4, a target type of Contact Provider Extension is created, then the auto-generated template code has errors right off the bat. Compiler be like what in the dickens is this?: class ContactProviderExtension: ContactProviderExtension

With iOS 18 there are now five ways for a caller to be blocked/silenced: the caller can be blocked via the Live Caller ID extension the caller can be blocked via the Call Kit extension the caller can be blocked via Block Caller via the call history recents the call could be silenced via Silence Junk Callers the call could be silenced via Silence Unknown Callers These are all totally separate and there's no way of reconciling all of them and presenting a holistic overview and management system to the user. Call blocking applications have no way of knowing which numbers will be blocked by 3) or silenced by 4) or 5), or even of determining 4) and 5) are enabled. And iOS doesn't indicate to users what will be blocked by 1) or 2). Currently users have no way of knowing what's been blocked/silenced where. Neither via call blocking apps nor via the OS. From users' perspectives its a confusing and frustrating mess. If the OS exposed which numbers have been blocked via 3) to applications and exposed if Silence Unknown Callers and Silence Junk Callers are enabled then call blocking applications could present a unified way for users to see and manage what's going on with their device holistically.

Hello I work for a company which is not itself a carrier, however we develop applications on behalf of carriers (the relationship between us and several large household name US carriers has existed for many years). The applications that we develop typically need carrier and/or special entitlements, for example: com.apple.CommCenter.fine-grained/public-subscriber-info com.apple.developer.coretelephony.sim-inserted com.apple.developer.pushkit.unrestricted-voip com.apple.developer.usernotifications.filtering com.apple.developer.associated-domains Obtaining those entitlements for the carrier applications that are released to the App Store is itself not a problem as the customers apply for them and they are duly granted and applied to the applications. However, what is a problem is working around the strict Apple development and distribution requirements and limitations, and the consequences that has given that the apps don't belong to our Apple account but the customers. Typically, a customer would provide us a developer certificate and set of provisioning profiles, but they would keep the distribution certificate and do the TestFlight/App Store release themselves. There's two limitations that come into play here, the first is that we can't distribute the app to TestFlight and secondly, we can only install the customer's apps on hardware registered with their Apple account. Given how the limitation for that is 100 in total, and these are large companies, they just don't have slots available and hence we might have a single device on which their app can run. These are very severe limitations given the complex nature of the applications and the need to have several developers/testers involved, which isn't possible. To mitigate those limitations we have "mirror" versions of customers' apps, these are apps which are identical to the customer apps except they have bundle ids registered to our Apple account. This enables the apps to be developed by any number of developers and distributed via Testfight and hence to any number of testers. But the problem is, the functionality of the mirror apps is severely reduced due to the fact they don't have the entitlements of the customers' apps. To get to the point of the post - I would like to know if there any potential solutions to this? For example: could it be possible for our mirror applications to be granted required entitlements (given the relationships we have with the customers. I'm sure the customers could vouch for us as a company and the need for this) could the entitlements be granted if we switched the mirror apps over to an Enterprise account (as enterprise apps can't be released to the App Store)? any other technical options or suggestions? Thank you

The documentation for adding images for Live Caller ID specify that they should be in .heic format and be less than 64KB. However the majority of the time they just don't display. Mostly they would with iOS 18 beta 4, but with beta 5, 90% of the time they don't display. Seems there's some other factor at play, such as pixel size of width/height, or resolution density?

If I run an app with a message filter extension on a phone with iOS 17.N then it works as expected. However if I run the same app (totally unchanged) on a phone with iOS 18 RC then there's multiple problems. I noticed there's no longer any logging from the extension in the Console (while there is for iOS 17 devices) in the messages app the filter sub categories aren't displayed (but they are on iOS 17 devices) if I try to debug the extension and place breakpoints in it, then there's an exception that occurs when the extension is enabled and the OS logs this (this doesn't occur with iOS 17 devices) '/private/preboot/Cryptexes/OS/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file), '/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file, not in dyld cache) I tried running on: iPhone with iOS 17.6 - no problems iPhone with iOS 18.1 beta - has all the above problems iPhone with iOS 18 RC - has all the above problems Was surprised the RC is so broken in this area as its release will be imminent. As things stand, I can't get a MFE to work at all with iOS 18. Anybody else with the same issues?

Over the past few weeks I've seen several people mention pushes sent via the sandbox haven't been getting delivered. Today I'm also seeing that (though pushes sent via production are fine). So it would appear to be down again. What's going on recently, any reason it's so unstable these last few weeks?

I've got a few years old app which was created using an Xcode template type of app. I'd like to split the model part of the code (model as in model-view-controller) out into a framework. Removed the view/controller source files to leave the model code is quick and easy, however the model code is large and complex with a couple of hundred of source files. Rather than create a new Xcode template type of framework and move the source files into there, is it possible to simply just change the template type of the existing project from app to framework?

I'm getting literally hundreds and hundreds of these lines appearing in the Xcode console when running the app. What's the cause? Too much logging? (if so this didn't used to appear with earlier version of Xcode, I'm currently running Xcode 16.2) How to do this: "set IDELogRedirectionPolicy to oslogToStdio in the environment of the executable." And what does doing that do? <snip> 1 log/signpost messages lost due to high rates in live mode recording. To guarantee delivery of all logs, set IDELogRedirectionPolicy to oslogToStdio in the environment of the executable. 1 log/signpost messages lost due to high rates in live mode recording. To guarantee delivery of all logs, set IDELogRedirectionPolicy to oslogToStdio in the environment of the executable. <snip>

I've got an app with several app extensions (call extension, action extension, notification service extension, message filtering extension, notification content extension). If I need to interactively debug these then I can select the scheme and run the extension within Xcode for all of them except for the notification content extension, with that I get an error dialog summary saying: Failed to install the app on the device / The provided item to be installed is not of a type that CoreDevice recognizes. Which when expanded has the blumpf posted below. Why can I not run the notification content extension, when I can run any other type of app extension? Failed to install the app on the device. Domain: com.apple.dt.CoreDeviceError Code: 3002 Failure Reason: The provided item to be installed is not of a type that CoreDevice recognizes. User Info: { DVTErrorCreationDateKey = "2024-12-27 16:39:54 +0000"; IDERunOperationFailingWorker = IDEInstallCoreDeviceWorker; NSURL = "file:///Users/Me/Library/Developer/Xcode/DerivedData/XFinity-celiagrvtevxcagztrguseawvjkl/Build/Products/Debug.Ceq.QA-iphoneos/NotificationContentExtension.appex"; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008101-00115D623460001E"; "device_isCoreDevice" = 1; "device_model" = "iPhone13,3"; "device_osBuild" = "18.2 (22C152)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPhone13,3"; "dvt_coredevice_version" = "397.28"; "dvt_coresimulator_version" = "993.7"; "dvt_mobiledevice_version" = "1759.40.2.100.1"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = arm64; "operation_duration_ms" = 7; "operation_errorCode" = 3002; "operation_errorDomain" = "com.apple.dt.CoreDeviceError"; "operation_errorWorker" = IDEInstallCoreDeviceWorker; "operation_name" = IDERunOperationWorkerGroup; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 1; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphoneos"; "param_diag_113575882_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 0; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_mtc_enable" = 0; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 0; "param_launcher_substyle" = 2; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.app-extension"; "param_structuredConsoleMode" = 1; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphoneos18.2"; "sdk_osVersion" = "18.2"; "sdk_variant" = iphoneos; } -- System Information macOS Version 14.7 (Build 23H124) Xcode 16.2 (23507) (Build 16C5032a) Timestamp: 2024-12-27T08:39:54-08:00

I've noticed issues with logging in the Mac's console app for a very long time now (from Xcode 15?) but have just spent several hours trying to objectively observe and monitor what's going on and try to set up reliable logging. But I've totally been unable to and my conclusion is that logging just absolutely cannot be relied upon at all, its so chronically bad as to be unusable. If I for example add some logging lines right at the start of didFinishLaunchingWithOptions() and use a variety of logging mechanisms NSLog(), print(),os_log_with_type(), OSLog() (AppDelegate is in Obj-C and calls Obj-C logging, then calls a swift function for Swift logging), then none of them are reliable. If the app is build/installed via Xcode then logging is reliable within Xcode's console and also within the Mac's console app. But then if the app is uploaded/installed via Testflight it's a very different matter. Sometimes, but not very often, the logging is as expected, but more often than not, some of it is missing. How much is missing seems totally random, sometimes its a little, sometimes its a lot, and something else that very very often happens is there's lots of duplicate logging, each logging line will appear 2 or three times. Here's a very simple example to illustrate what happens (in this example for simplicity I'm just showing using NSLog, don't focus on that as I know NSLog is "old", its the exact same result regardless of how the logging is actually performed). - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { appDelegate = self; NSLog(@"Log line 1"); NSLog(@"Log line 2"); NSLog(@"Log line 3"); NSLog(@"Log line 4"); NSLog(@"Log line 5"); When the app is downloaded from Testflight then only very rarely will I see 5 lines of logging, sometimes it'll be 4, sometimes 2, sometimes none. And quite often the logging is duplicated i.e. I might see for example in the Console app: Log line 1 Log line 1 Log line 2 Log line 2 Log line 3 Log line 3 In general it's just totally unusable and unreliable. It just cannot be be used at all. Why is it this bad? What can be done to make logging reliable and useful? I've spent days and days reading the recommended approaches, trying things out, including the new stuff like OSLog etc. But it remains dreadful. What is the recommended approach to make logging 100% reliable? There's never any problem with Xcode's console, it's only with the Mac's console app. However, when an app is being tested which has been installed from Testflight then using Xcode's console can't be used. So If a QA team find problems with a Testflight build and attach the Console log its utterly useless as its contents are effectively random.

I want to set the minimum deployment to 16.0, however Xcode (16.2) won't let me select that. In the drop down box it shows 18,17,16,15, however if any of these is selected it sets them as 18.6, 17.6, 16.6 or 15.6 (see image) If an attempt is made to edit the value manually, to 16.0, then after change it, Xcode just deletes that value and sets it to nothing. What's going on here? Why is Xcode only allowing the version other than be something.6 and why will it not let you manually edit it?

I've got an existing app which is using some 3rd party xcframeworks within its app extensions (for example within a Notification Service Extension). Within the target for the app extensions there is a Frameworks and Libraries section where the xcframework was dragged and dropped into. However now I want to create a new project and do a similar thing, within the app's target there is a Frameworks and Libraries section, but when an app extension target is created, Xcode is not adding a Frameworks and Libraries section. There is a Link Library with Binary section, however this doesn't have an embed section (where you can select to embed, don't embed, embed without signing etc.) and I get build error trying to drag and drop the xcframework in here. Where id the Framewoks and Libraries section go for app extensions for projects created with Xcode 16? How can this section be added?

If an iOS app gets terminated by watchdog due to, for example, hanging the main thread, is that considered to be a crash or something different. I'm asking because, according to google and AI, Crashlytics can detect and report these,but in my experience it does not. If I deliberately cause a watchdog termination by for example sleeping on the main thread for a long time then these never appear in Crashlytics. I know Apple folks here don't comment on non Apple software, so I'm not asking about Crashlytics, just wondering and interested about watchdog timeout terminations and how they differ from a "regular" crash.