I want to implement a scheme whereby the server gets instructed by the app during a handshake whether the server should send pushes over the Apple sandbox environment or the production environment. There's several variations where the push environment will vary depending upon the circumstances: Debug build/scheme with app installed via XCode Release build/scheme with app installed via XCode Developer distribution installed via .ipa/Apple Configurator app Ad hoc distribution installed via .ipa/Apple Configurator app App is installed from Testflight App is installed from the app store Is there a way the app can programmatically detect at run time which push server should be used and thus it can instruct the server accordingly during its handshake with it? I guess this boils down to if the app is able to programatically detect at run time if there's a production provisioning profile being used or not? Or is there some other mechanism to detect which push server should be used? There's a couple questions/answers on Stackoverflow about programatically detecting if a provisioning profile is present but they look a bit hacky and I don't know if they can be trusted to be future proof.

If Xcode is running lots of endless Socstream messages appear in the console: SocketStream read error [0x10cdb3c80]: 1 54 nw_protocol_socket_reset_linger [C172.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cc349e0]: 1 54 nw_protocol_socket_reset_linger [C174.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x10cd21fb0]: 1 54 nw_protocol_socket_reset_linger [C175.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b734fd0]: 1 54 nw_protocol_socket_reset_linger [C176.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C177.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C177.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] nw_socket_handle_socket_event [C179.1.1:1] Socket SO_ERROR [54: Connection reset by peer] nw_protocol_socket_reset_linger [C179.1.1:1] setsockopt SO_LINGER failed [22: Invalid argument] SocketStream read error [0x11b71b6b0]: 1 54 <snip> I'm running a React Native app and I think these might be due to the Metro connections. But they're very irritating and clog up the console making it difficult to see the app's own logging. Does anybody know if they can be made to shut up?

I'm attempting to build and have lots of code sign dialogs pop up. I'm entering the correct password and selecting Always Allow (selecting just Allow doesn't make any different) but they won't dismiss, instead more appear. I've not found a way of getting rid of them - all the buttons are greyed out. Restarting the desktop doesn't get rid of them. I have to restart the Mac to get rid of them. Why won't they go away and how can I force them to go away? (Sonoma 14.2.1 / Xcode 15.2)

When I run my app there's lots of logging in the console appearing, with it appearing with my app's name as the process. My app is accessing contacts, however I'm not logging this, so is the OS? The thing is, I'm testing performance with contacts databases which have thousands of entries in them, not only is this logging cluttering up the console making it difficult to examine, but I think the logging of so many thousands of line is affecting performance. Where is it coming from? Can it be turned off?

I'm analyzing an app which is doing some processing with contacts, and stress testing it with tens and tens of thousands of contacts which are being processed. The code is being processed within DispatchQueue.global(qos: .background).async {) When the app moves to the foreground the processing starts and continues after the app moves to the background. What I've noticed is that if the app is downloaded from TestFlight, then ~20 seconds after moving to the background, a dialog is displayed saying the App Crashed. Though it hasn't actually "crashed" in the usual sense of crash - there's no crash log present on the device nor in TestFlight if the crash is reported nor is there anything reported to Crashlytics. In addition the is still displayed in the iPhone task manager, also ApplicationWillTerminate() isn't called so it wasn't killed by the OS. This doesn't happen if the app is installed via Xcode and then run (not run via Xcode, installed via Xcode, then run independently from Xcode). When running via TestFlight installation I can see the OS logging" ReportCrash recordCrashEvent; isBeta 1 app stored Received a beta app crash notification. What's going on here, why is TestFlight reporting this? Is it erroneously reporting the background processing after 20 seconds as a crash? Is there anything the app should be doing in this situation that it isn't? Otherwise why is TF popping up that dialog?

My app has occasionally randomly started hanging. I have extensive logging in it, so you'd think it'd be easy to find out where its hanging (look at the last line logged etc.) However its hanging at different places each time it runs, so its impossible to debug. I've got several .ips files from off the handset, and they're all different. But a few of them have the same pattern at the top which is: 0 __unlock_wait2 NSLog If I open some in Xcode, it doesn't display any useful info or jump to a line of my code, it shows "deferred_logger". What do these mean? The common theme of mentioning logging can't be a co-incidence? Is there something wrong with the logging, is it being overloaded or something? If I turn off verbose logging to reduce the amount, the issues still persist, implying its not an overloaded logging situation. What could be going on?

I'm trying to debug an elusive random probably timing related issue. However I don't know if I can trust the logging output from the console, I keep seeing "Shutting down live logging" in the console output. What does this mean, why is it happening, if its affecting the logging from the app, then how can I stop it from happening?

I don't follow the section in the wwdv video on http3 https://developer.apple.com/videos/play/wwdc2021/10094/ From about 07.00 onwards for a couple of minutes, the presenter says URLSession won't use http3 unless the server advertises it. Then he uses instruments to show the app is using http2 - BUT the server is advertising http3. Then he says the fact the server advertised http3 will be remembered for future sessions. Why does the app use http2 for the first session even though the server advertised http3? Does that mean the first time any app connects to a http3 server it'll actually be http2 and only http3 for subsequent connections?

I'm experimenting with creating a Framework and have noticed a difference when dragging and dropping/or adding it into a project. If I create a brand new app and add the Framework then Xcode automatically creates a "Frameworks, Libraries, and Embedded" section within the app settings general section. The framework gets added with a default embed setting of Do Not Embed, which can be changed to Embed & Sign or Embed without Signing. However, I have an existing app which doesn't already contain a "Frameworks, Libraries, and Embedded section" section, if I add the framework to that app then Xcode is NOT creating a "Frameworks, Libraries, and Embedded section", instead it is adding the framework to the existing "Link Libraries with Binary" section. However this section does not have the embed box that a "Frameworks, Libraries, and Embedded" section has. Why is there this difference? And how can you choose whether to sign or not the framework if its been added by Xcode to the "Link Binary With Libraries" section rather than the "Frameworks, Libraries, and Embedded" section. I am finding that when Xcode adds the framework to the "Link Binary With Libraries" section and the app is run then there are run time errors about the framework not being able to be found, this does not occur when it gets added to the "Frameworks, Libraries, and Embedded" section. Is it possible to there explicitly create a "Frameworks, Libraries, and Embedded" section? I can't find one, nor can I get Xcode to create one, it keeps insisting on adding the Framework to "Link Binary With Libraries", which results in the app not running.

Our company is going to develop an iOS library of functionality for inclusion in several apps, some of the apps will be developed in-house and some externally. When the library is included in external apps the source code shouldn't be visible. When the library is included in internal apps, having the option to view and step through the code within the library will be invaluable for debugging. How could I set things up so that two forms of the library can be easily generated - one exposing source code and the other not. Ideally they should be capable of being incorporated within the apps in the same manner regardless of if the source code is expose or not Is that possible? I looked at Swift Packages, but it seems its for distribution of source code only, and its not possible to hide the source code. However, conversely, a framework only contains binary and no source code. Is there any other option?

I've got a custom run script build phase in my Xcode iOS project, however I want it to run before the items in the Target Dependencies section get built. So I added a Pre-Actions phase to the target's build scheme and pasted the contents there. However, during a build, there's no way to see if the stuff in the pre action is successful or not. It's possible to put echo statements into a run script build phase which is useful to print values such as file paths etc. but these don't work when part of a scheme pre action. Also if I deliberately put garbage into the scheme pre action, then I can see Xcode is still running the pre action, but as its full of garbage it should fail, but Xcode doesn't report any errors anywhere. So, is there any way to see and confirm if a scheme pre-action was successful or not, or to output logging statements from it to verify values its using are as expected?

Hello Apps and their extensions are able to communicate with each other by reading/writing data stored in a shared group location. However this isn't the case with the the Live Caller ID Extension - if data is written to group defaults for example (as opposed to standard defaults) by the app, then that data isn't readable by the Caller ID extension. This has the consequence that its not possible for a user to dynamically switch which data set the extension connects to. Consider the use case where the Live Caller ID Server has one data set where callers are not blocked, and another where they are blocked, then the caller id extension can route different requests to different datasets based on the "user tier". However as the extension can't read data from the shared group then the app can't communicate user preferences to the extension, therefore the switching isn't possible. Is this by design or due to the immaturity of the feature? If its by design, then it means the use case outlined above isn't possible, and thus greatly reduces the possible functionality of the Live Caller Id feature. (It would be possible for the app to install multiple extensions, each of which connects to a different data set by specifying a different user tier, but the user having to flip these one and off within the Settings app is a dreadful user experience).

I have a project which when I attempt to build with XCode 16 RC fails with the message "XCBBuildService quit unexpectedly". This occurs 100% of the time, thus I am unable to build the project. It first occurred in Xcode 16 beta 1 and has been present ever since, ever present in every beta; and now as its still present in the RC its highly unlikely it'll be fixed when the RC release becomes the final release. I submitted a ticket for this many weeks ago (FB14062261), but its not been looked at/updated. This is a problem in the short term because my app needs updating to use some iOS 18 specific features, in the longer term, it won't be possible to submit the app to the App Store if it continues to only be buildable with Xcode 15. As its impossible to build the app, I attempted to create a support ticket to get assistance. However I am unable to create a support ticket because the web page won't permit me to proceed raising a ticket unless there is a test Xcode project that recreates the issue. However, the issue does not occur with small simple Xcode projects. The Xcode project which I cannot be build contains dozens of sources files, thousands of lines of code, and many dependences. I can't submit that as the text Xcode project as its larger than that stated minimum requirements to attach to a support ticket. So how can I proceed, I can't build the app, I've raised a feedback ticket which hasn't been looked at, and when I attempt to raise a support ticket, the website won't let me proceed and create one. What can I do to get a support ticket created? What Xcode outputs: Process: XCBBuildService [9024] Path: /Applications/Xcode.app/Contents/SharedFrameworks/XCBuild.framework/Versions/A/PlugIns/XCBBuildService.bundle/Contents/MacOS/XCBBuildService Identifier: com.apple.dt.XCBBuildService Version: 1.0 (23000.1.226) Build Info: XCBuild-23000001226000000~13 (16A242) Code Type: ARM-64 (Native) Parent Process: Xcode [8990] Responsible: Xcode [8990] User ID: 504 Date/Time: 2024-09-09 14:03:16.8948 -0700 OS Version: macOS 14.6.1 (23G93) Report Version: 12 Anonymous UUID: EB8CED5F-F888-D71F-3893-33504A2FE3FD Time Awake Since Boot: 1800 seconds System Integrity Protection: enabled Crashed Thread: 13 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: XCBBuildService [9024] Application Specific Information: abort() called Kernel Triage: VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1871fcdf4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x18720f5e4 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1872059c4 mach_msg_overwrite + 476 3 libsystem_kernel.dylib 0x1871fd178 mach_msg + 24 4 CoreFoundation 0x18731d680 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x18731bf44 __CFRunLoopRun + 1208 6 CoreFoundation 0x18731b434 CFRunLoopRunSpecific + 608 7 CoreFoundation 0x18739945c CFRunLoopRun + 64 8 libswift_Concurrency.dylib 0x24eabd4e0 swift_task_asyncMainDrainQueueImpl() + 40 9 libswift_Concurrency.dylib 0x24eabd4a0 swift_task_asyncMainDrainQueue + 92 10 XCBBuildService 0x1043b392c main + 84 11 dyld 0x186eb3154 start + 2476 Thread 1: 0 libsystem_kernel.dylib 0x1871fd9b4 read + 8 1 XCBServiceCore 0x104c34688 closure #3 in ServiceHostConnection.resume() + 624 2 XCBServiceCore 0x104c326ed partial apply for closure #1 in Service.registerMessageHandler<A>(_:) + 1 3 XCBServiceCore 0x104c32a55 closure #1 in closure #1 in OS_dispatch_queue.async(group:qos:flags:execute:) + 1 4 XCBServiceCore 0x104c32a55 closure #1 in closure #1 in OS_dispatch_queue.async(group:qos:flags:execute:) + 1 5 XCBServiceCore 0x104c35c21 $sxIeAgHr_xs5Error_pIegHrzo_s8SendableRzs5NeverORs_r0_lTRyt_Tg5TQ0_ + 1 6 XCBServiceCore 0x104c326ed partial apply for closure #1 in Service.registerMessageHandler<A>(_:) + 1 7 libswift_Concurrency.dylib 0x24eabe0f9 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 Thread 2:: llb_buildsystem_build 0 libsystem_kernel.dylib 0x1872005ec __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x18723e55c _pthread_cond_wait + 1228 2 libc++.1.dylib 0x187163b14 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 3 llbuild 0x10531730c (anonymous namespace)::BuildEngineImpl::executeTasks(llbuild::core::KeyType const&) + 4552 4 llbuild 0x105314390 llbuild::core::BuildEngine::build(llbuild::core::KeyType const&) + 580 5 llbuild 0x10532da38 (anonymous namespace)::BuildSystemImpl::build(llbuild::buildsystem::BuildKey) + 208 6 llbuild 0x10532dc14 llbuild::buildsystem::BuildSystem::build(llvm::StringRef) + 260 7 llbuild 0x1053203f4 llbuild::buildsystem::BuildSystemFrontend::build(llvm::StringRef) + 56 8 llbuild 0x1052a6d8c 0x10528c000 + 109964 9 XCBBuildSystem 0x104d8ad1c partial apply for closure #13 in BuildOperation.build() + 28 10 libswift_Concurrency.dylib 0x24ea89a4c TaskLocal.withValue<A>(_:operation:file:line:) + 304 11 XCBUtil 0x1048d8864 closure #1 in closure #1 in static Task<>.detachNewThread(name:_:) + 296 12 XCBUtil 0x1048854ec thunk for @escaping @callee_guaranteed @Sendable () -> () + 28 13 Foundation 0x188bc2e1c __NSThread__block_start__ + 76 14 libsystem_pthread.dylib 0x18723df94 _pthread_start + 136 15 libsystem_pthread.dylib 0x187238d34 thread_start + 8 <snip>

I've got a bit of code which is making a HTTPS GET request. On an iPhone it runs as expected, however when running on the simulator there's a HTTP 400 response. I've logged the url and my http headers that I'm adding, and in both cases they are identical for the simulator and iPhone (there is no http body content). Therefore, as everything is identical, I'm wondering how it could work with hardware and not with the simulator? Does the OS append any additional HTTP headers before the request goes out (such as User-Agent for example) and might those be different between iPhone/simulator?

If a new (iOS) project is created in Xcode then a default set of deployment targets and values gets automatically created and set as follows: If the iPad, Mac, and Apple Vision supported destinations are deleted from the Xcode general section, these deployment targets still remain. If the app is then built using Xcode 16 and uploaded to TestFlight/App Store then the following issue is reported: TMS-90899: Macs with Apple silicon support issue - The app isn‘t compatible with the provided minimum macOS version of 11.0. Why is XCode populating the macOS deployment target with a value that that results in this issue? Why is Xcode even populating all 6 of these targets at all when its for an iOS app and hence 5 of them are redundant? Can the macOS deployment value simply be increased to silence this issue? Or can these that aren't relevant to iOS be deleted (if so how)? TIA