I often get questions about third-party crash reporting. These usually show up in one of two contexts: Folks are trying to implement their own crash reporter. Folks have implemented their own crash reporter and are trying to debug a problem based on the report it generated. This is a complex issue and this post is my attempt to untangle some of that complexity. If you have a follow-up question about anything I've raised here, please put it in a new thread with the Debugging tag. IMPORTANT All of the following is my own direct experience. None of it should be considered official DTS policy. If you have a specific question that needs a direct answer — perhaps you’re trying to convince your boss that implementing your own crash reporter is a very bad idea — start a dedicated thread here on the forums and we can discuss the details there. Use whatever subtopic is appropriate for your issue, but make sure to add the Debugging tag so that I see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Scope First, I can only speak to the technical side of this issue. There are other aspects that are beyond my remit: I don’t work for App Review, and only they can give definitive answers about what will or won’t be allowed on the store. Implementing your own crash reporter has significant privacy implications. IMPORTANT If you implement your own crash reporter, discuss the privacy impact with a lawyer. This post assumes that you are implementing your own crash reporter. A lot of folks use a crash reporter from another third party. From my perspective these are the same thing. If you use a custom crash reporter, you are responsible for its behaviour, both good and bad, regardless of where the actual code came from. Note If you use a crash reporter from another third party, run the tests outlined in Preserve the Apple Crash Report to verify that it’s working well. General Advice I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility. Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features: If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports. If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store. iOS 14 and macOS 12 report crashes in MetricKit. This is a very cool feature, and I’m surprised by how few people use it effectively. If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision. Why Is This Impossible? Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here: On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems [1]. To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle. I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process. Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues. WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about. [1] On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. Preserve the Apple Crash Report You must ensure that your crash reporter doesn’t disrupt the Apple crash reporter. This is important for three reasons: Some fraction of your crashes will not be caused by your code but by problems in framework code, and accurate Apple crash reports are critical in diagnosing such issues. When dealing with really hard-to-debug problems, you need the more obscure info that’s shown in the Apple crash report. If you’re working with someone from Apple (here on the forums, via a bug report, or a DTS case, or whatever), they’re going to want an accurate Apple crash report. If your crash reporter is disrupting the Apple crash reporter — either preventing it from generating crash reports entirely [1], or distorting those crash reports — that limits how much they can help you. IMPORTANT This is not a theoretical concern. The forums have many threads where I’ve been unable to help folks debug a gnarly problem because their third-party crash reporter didn’t preserve the Apple crash report (see here, here, and here for some examples). To avoid these issues I recommend that you test your crash reporter’s impact on the Apple crash reporter. The basic idea is: Create a program that generates a set of specific crashes. Run through each crash. Verify that your crash reporter produces sensible results. Verify that the Apple crash reporter produces the same results as it does without your crash reporter With regards step 1, your test suite should include: An un-handled language exception thrown by your code An un-handled language exception thrown by the OS (accessing an NSArray out of bounds is an easy way to get this) Various machine exceptions (at a minimum, memory access, illegal instruction, and breakpoint exceptions) Stack overflow Make sure to test all of these cases on both the main thread and a secondary thread. With regards step 4, check that the resulting Apple crash report includes correct values for: The exception info The crashed thread That thread’s state Any application-specific info, and especially the last exception backtrace [1] A particularly pathological behaviour here is to end your crash reporter by calling exit. This completely suppresses the Apple crash report. Some third-party language runtimes ‘helpfully’ include such a crash reporter, which makes it very hard to debug problems that occur within your process but outside of that language. Signals Many third-party crash reporters use UNIX signals to catch the crash. This is a shame because using Mach exception handling, the mechanism used by the Apple crash reporter, is generally a better option. However, there are two reasons to favour UNIX signals over Mach exception handling: On iOS-based platforms your crash reporter must run in-process, and doing in-process Mach exception handling is not feasible. Folks are a lot more familiar with UNIX signals. Mach exception handling, and Mach messaging in general, is pretty darned obscure. If you use UNIX signals for your crash reporter, be aware that this API has some gaping pitfalls. First and foremost, your signal handler can only use async signal safe functions [1]. You can find a list of these functions in sigaction man page [2] [3]. WARNING This list does not include malloc. This means that a crash reporter’s signal handler cannot use Objective-C or Swift, as there’s no way to constrain how those language runtimes allocate memory [4]. That means you’re stuck with C or C++, but even there you have to be careful to comply with this constraint. The Operative: It’s worse than you know. Captain Malcolm Reynolds: It usually is. Many crash reports use functions like backtrace (see its man page) to get a backtrace from their signal handler. There’s two problems with this: backtrace is not an async signal safe function. backtrace uses a naïve algorithm that doesn’t deal well with cross signal handler stack frames [5]. The latter point is particularly worrying, because it hides the identity of the stack frame that triggered the signal. If you’re going to backtrace out of a signal, you must use the crashed thread’s state (accessible via the handlers uap parameter) to start your backtrace. Apropos that, if your crash reporter wants to log the state of the crashed thread, that’s the place to get it. Your signal handler must be prepared to be called by multiple threads. A typical crashing signal (like SIGSEGV) is delivered to the thread that triggered the machine exception. While your signal handler is running on that thread, other threads in your process continue to run. One of these threads could crash, causing it to call your signal handler. It’s a good idea to suspend all threads in your process early in your signal handler. However, there’s no way to completely eliminate this window. Note The need to suspend all the other threads in your process is further evidence that sticking to async signal safe functions is required. An unsafe function might depend on a thread you’ve suspended. A typical crashing signal is delivered on the thread that triggered the machine exception. If the machine exception was caused by a stack overflow, the system won’t have enough stack space to call your signal handler. You can tell the system to switch to an alternative stack (see the discussion of SA_ONSTACK in the sigaction man page) but that isn’t a complete solution (because of the thread issue discussed immediately above). Finally, there’s the question of how to exit from your signal handler. You must not call exit. There’s two problems with doing that: exit is not async signal safe. In fact, exit can run arbitrary code via handlers registered with atexit. If you want to exit the process, call _exit. Exiting the process is a bad idea anyway, because it will prevent the Apple crash reporter from running. This is very poor form. For an explanation as to why, see Preserve the Apple Crash Report (above). A better solution is to unregister your signal handler (set it to SIG_DFL) and then return. This will cause the crashed process to continue execution, crash again, and generate a crash report via the Apple crash reporter. [1] While the common signals caught by a crash reporter are not technically async signals (except SIGABRT), you still have to treat them as async signals because they can occur on any thread at any time. [2] It’s reasonable to extend this list to other routines that are implemented as thin shims on a system call. For example, I have no qualms about calling vm_read (see below) from a signal handler. [3] Be aware, however, that even this list has caveats. See my Async Signal Safe Functions vs Dyld Lazy Binding post for details. [4] I expect that it’ll eventually be possible to write signal handlers in Swift, possibly using some facility that evolves from the the existing, but unsupported, @_noAllocation and @_noLocks attributes. If you’d like to get involved with that effort, I recommend that engage with the Swift Evolution process. [5] Cross signal handler stack frames are pushed on to the stack by the kernel when it runs a signal handler on a thread. As there’s no API to learn about the structure of these frames, there’s no way to backtrace across one of these frames in isolation. I’m happy to go into details but it’s really not relevant to this discussion [6]. If you’re interested, start a new thread with the Debugging tag and we can chat there. [6] (Arg, my footnotes have footnotes!) The exception to this is where your trying to generate a crash report for code running in a signal handler. That’s not easy, and frankly you’re better off avoiding signal handlers in general. Where possible, handle signals via a Dispatch event source. Reading Memory A signal handler must be very careful about the memory it touches, because the contents of that memory might have been corrupted by the crash that triggered the signal. My general rule here is that the signal handler can safely access: Its code Its stack (subject to the constraints discussed earlier) Its arguments Immutable global state In the last point, I’m using immutable to mean immutable after startup. It’s reasonable to set up some global state when the process starts, before installing your signal handler, and then rely on it in your signal handler. Changing any global state after the signal handler is installed is dangerous, and if you need to do that you must be careful to ensure that your signal handler sees consistent state, even though a crash might occur halfway through your change. You can’t protect this global state with a mutex because mutexes are not async signal safe (and even if they were you’d deadlock if the mutex was held by the thread that crashed). You should be able to use atomic operations for this, but atomic operations are notoriously hard to use correctly (if I had a dollar for every time I’ve pointed out to a developer they’re using atomic operations incorrectly, I’d be very badly paid (-: but that’s still a lot of developers!). If your signal handler reads other memory, it must take care to avoid crashing while doing that read. There’s no BSD-level API for this [1], so I recommend that you use vm_read. [1] The traditional UNIX approach for doing this is to install a signal handler to catch any memory access exceptions triggered by the read, but now we’re talking signal handling within a signal handler and that’s just silly. Writing Files If your want to write a crash report from your signal handler, you must use low-level UNIX APIs (open, write, close) because only those low-level APIs are documented to be async signal safe. You must also set up the path in advance because the standard APIs for determining where to write the file (NSFileManager, for example) are not async signal safe. Offline Symbolication Do not attempt to do symbolication from your signal handler. Rather, write enough information to your crash report to support offline symbolication. Specifically: The addresses to symbolicate For each Mach-O image in the process: The image’s path The image’s build UUID [1] The image’s load address You can get most of the Mach-O image information using the APIs in <mach-o/dyld.h> [2]. Be aware, however, that these APIs are not async signal safe. You’ll need to get this information in advance and cache it for your signal handler to record. This is complicated by the fact that the list of Mach-O images can change as you process loads and unloads code. This requires you to share mutable state with your signal handler, which is exactly what I recommend against in Reading Memory. Note You can learn about images loading and unloading using _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image respectively. [1] If you’re unfamiliar with that term, see TN3178 Checking for and resolving build UUID problems and the documents it links to. [2] I believe you’ll need to parse the Mach-O load commands to get the build UUID. What to Include When deciding what to include in a crash report, there’s a three-way balance to be struck: The more information you include, the easier it is to diagnose problems. Some information is hard to obtain, either because there’s no public API to get that information, or because the API is not available to your crash reporter. Some information is so privacy-sensitive that it has no place in a crash report. Apple’s crash reporter strikes its own balance here, and I recommend that you try to include everything that it includes, subject to the limitations described in the second point. Here’s what I’d considered to be a minimal list: Information about the machine exception that triggered the crash For memory access exceptions, the address of the access that triggered the crash Backtraces of all the threads (sometimes the backtrace of a non-crashing thread can yield critical information about the crash) The crashed thread Its thread state A list of Mach-O images, as discussed in the Offline Symbolication section IMPORTANT Make sure you report the thread backtraces in a consistent order. Without that it’s hard to correlate information across crash reports. Revision History 2025-08-25 Added some links to examples of third-party crash reports not preserving the Apple crash report. Added a link to TN3178. Made other minor editorial changes. 2022-05-16 Fixed a broken link. 2021-09-10 Expanded the General Advice section to include pointers to Apple crash report resources, including MetricKit. Split the second half of that section out in to a new Why Is This Impossible? section. Made minor editoral changes. 2021-02-27 Fixed the formatting. Made minor editoral changes. 2019-05-13 Added a reference to my Async Signal Safe Functions vs Dyld Lazy Binding post. 2019-02-15 Expanded the introduction to the Preserve the Apple Crash Report section. 2019-02-14 Clarified the complexities of an out-of-process crash reporter. Added the What to Include section. Enhanced the Signals section to cover reentrancy and stack overflow. Made minor editoral changes. 2019-02-13 Made minor editoral changes. Added a new footnote to the Signals section. 2019-02-12 First posted.

When trying to use the watchOS preview the simulator fails to load and throws about 15 errors. Clearly the simulator is trying to load all of the iOS packages to the watchOS simulator. However, these packages clearly aren't included in the watchOS app. Furthermore, both apps build successfully to the main simulators, just not the previews. Having a list of errors that simply should not be there is a pretty big annoyance when something is going wrong. How do I fix this?

I'm trying to evaluate if we can support AR navigation with MapKit. The feature is supposed to be available for users in US. I tried to run the sample on my iPhone: https://developer.apple.com/documentation/arkit/tracking-geographic-locations-in-ar?language=objc But I'm in a location that ARGeoTrackingConfiguration.checkAvailabilityWithCompletionHandler: always return false. I think ARGeoAnchor isn't supported in my location. I tried to use simulated locations by Adding a gpx file when launching the app. Enabling Xcode -> Debug -> Simulate Location -> New York, NY, US But the availability for ARGeoAnchor is still false. Is that possible for me to develop the ARGeoAnchor feature outside of the covered areas?

I am using ARKit with RealityKit to scan objects using LiDAR on iOS. I can generate an OBJ file from ARMeshAnchors, but I am missing the texture export (JPG + MTL). What I Have So Far: Successfully capturing mesh using ARMeshAnchor. Converting mesh into MDLAsset and exporting .obj. I need help generating the .jpg texture and linking it to the .mtl file. private func exportScannedObject() { guard let camera = arView.session.currentFrame?.camera else { return } func convertToAsset(meshAnchors: [ARMeshAnchor]) -> MDLAsset? { guard let device = MTLCreateSystemDefaultDevice() else {return nil} let asset = MDLAsset() for anchor in meshAnchors { let mdlMesh = anchor.geometry.toMDLMesh(device: device, camera: camera, modelMatrix: anchor.transform) // Apply a gray material to the mesh let material = MDLMaterial(name: "GrayMaterial", scatteringFunction: MDLScatteringFunction()) material.setProperty(MDLMaterialProperty(name: "baseColor", semantic: .baseColor, float3: SIMD3(0.5, 0.5, 0.5))) // Gray color if let submeshes = mdlMesh.submeshes as? [MDLSubmesh] { for submesh in submeshes { submesh.material = material } } asset.add(mdlMesh) } return asset } func export(asset: MDLAsset) throws -> URL { let directory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first! let url = directory.appendingPathComponent("scaned.obj") if MDLAsset.canExportFileExtension("obj") { do { try asset.export(to: url) return url } catch let error { fatalError(error.localizedDescription) } } else { fatalError("Can't export USD") } } if let meshAnchors = arView.session.currentFrame?.anchors.compactMap({ $0 as? ARMeshAnchor }), let asset = convertToAsset(meshAnchors: meshAnchors) { do { let url = try export(asset: asset) showScanPreview(url) } catch { print("export error") } } } extension ARMeshGeometry { func vertex(at index: UInt32) -> SIMD3<Float> { assert(vertices.format == MTLVertexFormat.float3, "Expected three floats (twelve bytes) per vertex.") let vertexPointer = vertices.buffer.contents().advanced(by: vertices.offset + (vertices.stride * Int(index))) let vertex = vertexPointer.assumingMemoryBound(to: SIMD3<Float>.self).pointee return vertex } // helps from StackOverflow: // https://stackoverflow.com/questions/61063571/arkit-3-5-how-to-export-obj-from-new-ipad-pro-with-lidar func toMDLMesh(device: MTLDevice, camera: ARCamera, modelMatrix: simd_float4x4) -> MDLMesh { func convertVertexLocalToWorld() { let verticesPointer = vertices.buffer.contents() for vertexIndex in 0..<vertices.count { let vertex = self.vertex(at: UInt32(vertexIndex)) var vertexLocalTransform = matrix_identity_float4x4 vertexLocalTransform.columns.3 = SIMD4<Float>(x: vertex.x, y: vertex.y, z: vertex.z, w: 1) let vertexWorldPosition = (modelMatrix * vertexLocalTransform).columns.3 let vertexOffset = vertices.offset + vertices.stride * vertexIndex let componentStride = vertices.stride / 3 verticesPointer.storeBytes(of: vertexWorldPosition.x, toByteOffset: vertexOffset, as: Float.self) verticesPointer.storeBytes(of: vertexWorldPosition.y, toByteOffset: vertexOffset + componentStride, as: Float.self) verticesPointer.storeBytes(of: vertexWorldPosition.z, toByteOffset: vertexOffset + (2 * componentStride), as: Float.self) } } convertVertexLocalToWorld() let allocator = MTKMeshBufferAllocator(device: device); let data = Data.init(bytes: vertices.buffer.contents(), count: vertices.stride * vertices.count); let vertexBuffer = allocator.newBuffer(with: data, type: .vertex); let indexData = Data.init(bytes: faces.buffer.contents(), count: faces.bytesPerIndex * faces.count * faces.indexCountPerPrimitive); let indexBuffer = allocator.newBuffer(with: indexData, type: .index); let submesh = MDLSubmesh(indexBuffer: indexBuffer, indexCount: faces.count * faces.indexCountPerPrimitive, indexType: .uInt32, geometryType: .triangles, material: nil); let vertexDescriptor = MDLVertexDescriptor(); vertexDescriptor.attributes[0] = MDLVertexAttribute(name: MDLVertexAttributePosition, format: .float3, offset: 0, bufferIndex: 0); vertexDescriptor.layouts[0] = MDLVertexBufferLayout(stride: vertices.stride); let mesh = MDLMesh(vertexBuffer: vertexBuffer, vertexCount: vertices.count, descriptor: vertexDescriptor, submeshes: [submesh]) return mesh } } What I Need Help With: How do I generate the JPG texture from the AR scene? How do I save an MTL file linking the OBJ model to the texture? How can I correctly apply the texture when viewing the OBJ in an external 3D viewer? I appreciate any guidance, including sample code or resources! If you have a complete working solution, I’d love to discuss further via private channels.

We are renaming the project and a Static Library the is critical to the operation on the app is not found during compiling. We have the same project working fine. We have reviewed the project.pbxproj file and searched for erroneous linking, reviewed the Target settings and there is nothing obviously wrong. (Copied and secured the original) Typically workflow is: Clean Delete Derived Data dir D/l Swift Packages Build/Run The team has many years using Xcode / Swift and the project and this is not clear how to resolve. We have scoured SO and the solutions do not apply. Facts: -No cocoapods -Search Paths all set Linker all set Thoughts?

The 'view' and 'modifier' were displayed on my particular project, but it is no longer displayed. I don't know which shortcut key was hidden. What should I do to display it again?

Like the title says, I'll commit some changes no problem with my Git name and email displayed properly, then work for a while longer and when use the integrate menu to stage and commit I find the git name/email are empty. My credentials are properly entered in settings. The only fix i've found is quitting and restarting. Any less frustrating option?

I'm integrating Apple Pay with PayFort in a Swift iOS application, and I’m currently working on preparing a valid purchase request using Apple Pay, as described in PayFort’s documentation: 🔗 https://docsbeta.payfort.com/docs/api/build/index.html?shell#apple-pay-authorization-purchase-request The documentation outlines the following required parameters: apple_data apple_signature apple_header apple_transactionId apple_ephemeralPublicKey apple_publicKeyHash apple_paymentMethod apple_displayName apple_network apple_type Optional: apple_applicationData I understand these should be derived from the PKPayment object after Apple Pay authorization, but I’m having trouble mapping everything correctly. Here’s what I’m seeing in code: payment.token // Returns something like: <PKPaymentToken: 0x28080ae80; transactionIdentifier: "..."; paymentData: 3780 bytes> payment.token.paymentData // Contains 3780 bytes of encrypted data payment.token.paymentData.base64EncodedString() // Returns a long base64 string, which at first glance seems like it could be used for apple_data, // but PayFort doesn't accept it as-is — so this value appears to be incomplete or incorrectly formatted I can successfully retrieve the following values from payment.token.paymentMethod: apple_displayName apple_network apple_type However, I’m still unsure how to extract or build the following in the format accepted by PayFort: apple_data apple_signature apple_header apple_transactionId apple_ephemeralPublicKey apple_publicKeyHash apple_paymentMethod These may be contained within the paymentData JSON, but I’m not sure how to decode it or if Apple allows decrypting it in a way that matches PayFort’s expected format. How can I correctly extract or build apple_data, apple_signature, and apple_header from the Apple Pay token? Also, how should I handle the decryption or decoding (if necessary) of paymentData to retrieve values like apple_transactionId, apple_ephemeralPublicKey, and apple_publicKeyHash? If anyone has successfully set this up or has example code that bridges Apple Pay and PayFort’s expected request format, it would be super helpful! Thanks in advance 🙏

When renaming A.value, it also causes the value inside the conditional compilation in checkRename to be renamed. How to resolve or avoid this situation? class A { let value = "1" } class B { var value = 0 } func checkRename() { var b = B() #if os(iOS) b.value = 456 #elseif os(macOS) b.value = 789 #endif } Xcode Version 15.4 (15F31d).

Hello All I'm encountering an issue with Keychain access in iOS simulators after reinstalling Xcode. My app successfully accesses the Keychain on physical devices, but simulators consistently fail with errors. Details: App uses Keychain to store API keys Works perfectly on physical devices After Xcode reinstall, simulator Keychain access fails Error logs show "Keychain retrieve failed for key with status: -25300" I've properly configured Keychain Sharing entitlements My entitlements file includes: $(AppIdentifierPrefix)******* What I've tried: Resetting simulators Deleting simulator Keychain databases manually Adding Keychain Sharing capability Ensuring entitlements are correct My app worked fine with simulators before reinstalling Xcode, which suggests something changed in the development environment rather than my code. Has anyone encountered similar issues? Is there a recommended approach for handling Keychain access in simulators that's more resilient to Xcode environment changes? Thanks for your help!

Xcode renders a beautiful bubble with PR comments inline with my code. However, I'd like to edit my code without that comment in the way. How do I turn / toggle that feature off? I've looked through Settings for editing and source control, menus for the editor and view, as well as the drop down menus and diff toggles for the specific editor box.

I have tried several options so far to no avail: Unarchiver shuts down silently (after ~1.5hr of trying to unarchive). xip console tool fails after ~1.5hr with this error: xip: signing certificate was "Software Update" (validation not attempted) xip: error: The archive “Xcode_12.5.1.xip” failed to be moved to the final destination due to the error: The operation couldn’t be completed. No such file or directory. extracted .app is incomplete though weighs about 30GB unxip extracts for ~1.5hr (being stuck for ~40min on Expanding items from “Xcode_12.5.1.xip”: 99%) and then shuts down. extracted .app is incomplete with the size of ~1.9GB Are there any other options I can try to extract Xcode 12.5.1 xip archive? Would external drive be an issue (I have Xcode_12.5.1.xip on external drive)?

Hello, I recently received feedback from two users that they charged twice after entering their password when trying to initiate payment on the app. I checked my front-end and back-end codes, both of which only initiate one order, but I don't know why the user deducts two payments after entering the password. I hope everyone can help me analyze this problem and how it came about? Additionally, I wonder if there is a possibility that the system may prompt the user to enter their password again due to network issues, resulting in the deduction of two payments. But the user told us that they only entered the password once (I don't know if the user lied). I am unable to find how the problem arose. I hope you can help me analyze how to solve this problem? If you also encounter such a problem, can you teach me how to solve it?

Hi all, I’m running into a persistent linker error when building my Unity 6 project (IL2CPP, iOS target) that calls a Swift method via an Objective-C++ wrapper. Despite following all known steps, I keep getting: Undefined symbols for architecture arm64: "_placeGeoAnchor", referenced from: _GeoAnchorTrigger_placeGeoAnchor in libGameAssembly.a ... ld: symbol(s) not found for architecture arm64 I’m trying to place a persistent AR anchor at real-world GPS coordinates (so that the same asset can appear at the same location for a returning user). Since I’m targeting iOS, I can’t use Google’s geospatial anchors (but I sooo wish I could--please apple I beg of you stop being so selfish lol). I've already done these things: Swift file is added to Unity-iPhone target. .mm and .h files are in Unity-iPhone target under Compile Sources. Bridging header is set to Unity-iPhone-Bridging-Header.h. Generated header name is correct (GeoTest-Swift.h). Build Active Architecture Only set to No. Function has attribute((visibility("default"))). Unity project uses IL2CPP scripting backend. Yet I'm still getting the same linker error — it appears Unity (via IL2CPP) references the function, but Xcode doesn't link it. It’s something small that’s being missed with how IL2CPP links native symbols? Or maybe I need to explicitly include something in Link Binary With Libraries? I’ve verified symbol visibility and targets repeatedly. I’ve built AR features in Unity before (for Quest), but this is my first time trying to bridge C# → Objective-C++ → Swift in this way for a geolocation-based AR anchor for an iphone. I'm going crazy, I’ve been stuck on this for 12+ hours now, so any insight or nudge would be deeply appreciated. SPECS: Macbook Pro M4 Pro--Sequoia 15.4 Unity 6000.0.45f1 IPhone 11 iOS 18.4 Xcode 15

Within Xcode's settings location section is a drop down menu to switch between setting the derived data location to be default, relative or custom. However its a global setting. I work on more than one project simultaneously, and for one of them I want the location set to relative, but default for all the others. Is there any way of achieving that?

When I build UITabBarController on (iPad + iOS18), selectedImage on each tabBarItems don't appear. (SwiftUI TabView can change iconImages by state change, so no problem on SwiftUI.) Could someone tells me how to solve this problem? sample project which produce the problem: github before after

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?

难道是电脑版本问题吗 macos15.3.1 错误报告

I have the 'warnings as errors' policy set to Yes for Apple Clang and Swift compiler. As far as I know, there is no way to make exceptions to the warning policies from Swift compiler (correct me if I am wrong), what about Clang warning policies, specifically when it comes to header files from 3rd party pods? They don't show up on the Compile Sources so I can't apply flags such as -Wno-error=deprecated to them. Adding #pragma GCC... to them won't help as a fresh pod install will wipe the #pragma statements out. Is there a way to exclude the header files from pods from getting the warning policies from Clang so I won't see errors from them when compiling Clang modules that's a part of the build process?

We're building an SDK (let's call it MyFramework) which is distributed as an .xcframework for developers to integrate it into their own apps. Recently, we've added tvOS support by adding it as a supported destination for the SDK. Essentially, the SDK became a cross-platform framework and easy to be adopted in both iOS and tvOS apps. The .xcframework is generated fine, all builds correctly. We've tested the SDK integrated in test apps. We've also submitted an iOS archive app to the AppStore connect, just to make sure all is well with the AppStore submission. However, when I tried submitting a tvOS archive app (that integrates the same SDK) to the AppStore connect, the build was marked as invalid binary and we've got the following error message: ITMS-90562: Invalid Bundle - One of the nested bundles is built for a platform which is different from the main bundle platform. Please make sure that all bundles have correct platform specification. First, I thought that any of the modules of the framework was not correctly configured for tvOS but that was not the case. Everything compiles ok and it runs in debug as expected. It only fails when trying to submit the tvOS app that integrates the SDK. After a lot of investigating, we realised that the reason for the AppStore submission error is because we codesign the framework. We use codesign to distribute it as cryptographically signed xcframework. codesign --timestamp -v --sign "Apple Distribution: Company (xxxxxxxxxx)" "MyFramework.xcframework" As soon as we remove the above line from our CI/CD pipeline that generates the xcframework, and submit a tvOS archive app that integrates the unsigned framework, the AppStore submission error goes away and the TestFlight build can be tested. I've also tried to just strip the _CodeSignature folder from the .xcframework package but it still fails. So the only solution currently is to not codesign the xcframework to be able to upload tvOS archive apps that integrate the SDK to the AppStore connect. However, we're still puzzled as to why only the tvOS archive app gets the invalid binary error when it integrates a signed SDK. I feel like the error message is quite misleading if we have to stop signing the SDK xcframework for it to be accepted during the AppStore submission. Anyone has any idea? Or has anyone encountered a similar issue? Thanks!