I'm trying to use Xcode UI tests for the first time. I added a UI Tests target and set up the signing, then opened the default AppnameUITests.swift file. I added a new function named testAboutPage(), clicked inside the block and clicked the Record UI Test button (red circle) at the bottom of the editor window. If the app is already running when I do this, Xcode crashes immediately. If the app is not running, Xcode builds and runs the app, then crashes. I've seen reports of this going back years, but none of the posts have a solution. I do have a crash log to share. Does anyone know how to get past this? This forum won't let me upload the complete crash log because it exceeds the size limit, but here's the first part through the stack trace of the crashed thread: Process: Xcode [46652] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 16.2 (23507) Build Info: IDEApplication-23507000000000000~2 (16C5032a) App Item ID: 497799835 App External ID: 870964517 Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 503 Date/Time: 2025-02-04 12:58:05.5200 -0800 OS Version: macOS 15.3 (24D60) Report Version: 12 Anonymous UUID: 144B0B99-8D44-736B-0D9A-1F6FA6DF85F7 Time Awake Since Boot: 48000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Xcode [46652] Application Specific Information: abort() called Application Specific Signatures: ((result)) != nil Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x18a3b3720 __pthread_kill + 8 1 libsystem_pthread.dylib 0x18a3ebf70 pthread_kill + 288 2 libsystem_c.dylib 0x18a2f8908 abort + 128 3 IDEKit 0x109e81554 +[IDEAssertionHandler _handleAssertionWithLogString:assertionSignature:assertionReason:extraBacktrace:] + 964 4 IDEKit 0x109e819e4 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] + 876 5 DVTFoundation 0x10600d358 _DVTAssertionHandler + 424 6 DVTFoundation 0x10600d4d8 _DVTAssertionFailureHandler + 196 7 IDEKit 0x10a1f99e4 -[IDEUIRecordingManager _workspaceTabController] + 176 8 IDEKit 0x10a1fa528 __94-[IDEUIRecordingManager _startRecordingWithLaunchSession:alwaysAskForAPIAccess:reservedNames:]_block_invoke_3 + 252 9 DVTFoundation 0x10611fc9c __DVT_CALLING_CLIENT_BLOCK__ + 16 10 DVTFoundation 0x1061206c4 __DVTDispatchAsync_block_invoke + 152 11 libdispatch.dylib 0x18a237854 _dispatch_call_block_and_release + 32 12 libdispatch.dylib 0x18a2395b4 _dispatch_client_callout + 20 13 libdispatch.dylib 0x18a248040 _dispatch_main_queue_drain + 984 14 libdispatch.dylib 0x18a247c58 _dispatch_main_queue_callback_4CF + 44 15 CoreFoundation 0x18a5139d0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 16 CoreFoundation 0x18a4d35bc __CFRunLoopRun + 1996 17 CoreFoundation 0x18a4d2734 CFRunLoopRunSpecific + 588 18 HIToolbox 0x195a41530 RunCurrentEventLoopInMode + 292 19 HIToolbox 0x195a47348 ReceiveNextEventCommon + 676 20 HIToolbox 0x195a47508 _BlockUntilNextEventMatchingListInModeWithFilter + 76 21 AppKit 0x18e04a848 _DPSNextEvent + 660 22 AppKit 0x18e9b0c24 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 23 AppKit 0x18e03d874 -[NSApplication run] + 480 24 IDEKit 0x109e50f14 -[IDEApplication run] + 192 25 AppKit 0x18e014068 NSApplicationMain + 888 26 dyld 0x18a06c274 start + 2840

Use a project hosted by a filesystem/local Git repository. Make changes to any file in the project. Switch to the "Source Control" Navigator, and the "Changes" sub-navigator within that. Select "Uncommitted Changes", or any file below that. Verify that your changes appear in the source change browser/editor on the right. Click the "Stage All" button. Absolutely nothing happens, 90% of the time. Go back to the Changes navigator, right-click on an item there and select the "Stage Changes in..." popup menu item. It works, every time. I haven't found any pattern to the 10% of the time the "Stage All" button actually works, wrt what changes are selected in the navigator, whether I've already typed a commit message, etc.. I happen to be using Xcode 16.0 on two Macs: a Mac Studio running MacOS 14.6.1, and a 2019 MacBook Pro running MacOS 14.7.1. Both exhibit the same symptoms.

I submitted feedback as FB16463501 -- posting here for others to see, or maybe for Apple to share any help if there are workarounds, etc.: Targets below iOS 18.x fail to launch app due to dyld[xxxxx]: Symbol not found: errors when referencing: MeshResource.init(from:) async - https://developer.apple.com/documentation/realitykit/meshresource/init(from:)-b7hb i.e. dyld[61511]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE4fromACSayAD0C10DescriptorVG_tYaKcfC MeshResource.replace(with:) async - https://developer.apple.com/documentation/realitykit/meshresource/replace(with:)-8uvri i.e. dyld[78830]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE7replace4withyAcDE8ContentsV_tYaKF Targets tested that exhibit issue: (DYLD errors) Device: iOS 17.7.2, iPhone 14 Pro Max Simulator: iOS 17.5 (21F79), iPhone 15 System Information: macOS Version 15.3 (Build 24D60) Xcode 16.2 (23507) (Build 16C5032a) MRE -- include this code in your app: (no need to invoke, just reference) static func addOrUpdateEntityModel_MRE(_ entity: ModelEntity) async { let descriptor = MeshDescriptor(name: "MyDescriptor") do { if let modelComponent = entity.model { // update existing ModelComponent if let model = try? MeshResource.Model(id: "MyModelId", descriptors: [descriptor]) { var contents = MeshResource.Contents() contents.models = .init([model]) try await modelComponent.mesh.replace(with: contents) /// `dyld[78830]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE7replace4withyAcDE8ContentsV_tYaKF` } } else { //create new ModelComponent /// Comment-out the 2 lines below == dyld error for above `MeshResource.replace(with:)` let meshRes = try await MeshResource(from: [descriptor]) /// `dyld[61511]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE4fromACSayAD0C10DescriptorVG_tYaKcfC` entity.model = .init(mesh: meshRes, materials: [SimpleMaterial()]) } } catch { fatalError() } }

I'm having an issue specifically with SwiftUI previews in my iOS project. The project builds and runs fine on devices and simulators (in Rosetta mode), but SwiftUI previews fail to load in both Rosetta and native arm64 simulator environments. The main error in the preview is related to the Alamofire dependency in my SiriKit Intents extension: Module map file '[DerivedData path]/Build/Products/Debug-iphonesimulator/Alamofire/Alamofire.modulemap' not found This error repeats for multiple Swift files within my SiriKit Intents extension. Additionally, I'm seeing: Cannot load underlying module for 'Alamofire Environment Xcode version: 16.2 macOS version: Sonoma 14.7 Swift version: 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1) Dependency management: CocoaPods Alamofire version: 5.8 My project is a large, older codebase that contains a mix of UIKit, Objective-C and Swift Architecture Issue: The project only builds successfully in Rosetta mode for simulators. SwiftUI previews are failing in both Rosetta and native arm64 environments. This suggests there may be a fundamental issue with how the preview system interacts with the project's architecture configuration. What I've Tried I've attempted several solutions without success: Cleaning the build folder (⇧⌘K and Option+⇧⌘K) Deleting derived data Reinstalling dependencies Restarting Xcode Removing and re-adding Alamofire

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?

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 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.

in Project/Package Dependencies, some problem occurs while i add Exact Version value like '1.1.0-0fec058'. the finally value i input will be random updated to 1.0.0 or other value. Reproduce by input any version value like '1.2.0-"0"' which second part begin with 0. So bad experience.

Main Issue: While building an iOS project using IL2CPP in Unity, I encountered the following error: Command PhaseScriptExecution failed with a nonzero exit code Sub-Issue: Unity is unable to detect a compatible iPhoneOS SDK, even though Xcode is correctly installed and functioning as expected. Error Message: Unity.IL2CPP.Bee.BuildLogic.ToolchainNotFoundException: IL2CPP C++ code builder is unable to build C++ code. In order to build C++ code for Mac, you must have Xcode installed. Building for Apple Silicon requires Xcode 9.4 and Mac 10.12 SDK. Xcode needs to be installed in the /Applications directory and have a name matching Xcode*.app. Or be selected using xcode-select. It's also possible to use /Library/Developer/CommandLineTools if those match the listed requirements. More information and installation instructions can be found here: https://developer.apple.com/support/xcode/ Specific Xcode versions can be downloaded here: https://developer.apple.com/download/more/ Unable to detect any compatible iPhoneOS SDK! Additional Errors & Observations: bee_backend Not Found chmod: /Users/vaunicacalji/Desktop/DinoKite/Il2CppOutputProject/IL2CPP/build/deploy_x86_64/bee_backend/mac-x86_64/bee_backend: No such file or directory Issue: Manually checking the file, bee_backend does exist and is executable, but the build process still reports it as missing. 2. IL2CPP Build Failure Build failed with 0 successful nodes and 0 failed ones Error: Internal build system error. BuildProgram exited with code 1. 3. Xcode Not Detected by Unity Unable to detect any compatible iPhoneOS SDK! Issue: Running xcode-select -p confirms that Xcode is installed at /Applications/Xcode.app/Contents/Developer, and xcodebuild -showsdks lists available SDKs, including iOS 18.2. Environment Details: macOS Version: Sonoma 14.5 Mac Model: MacBook Air (Retina, 13-inch, 2018) Processor: 1.6 GHz Dual-Core Intel Core i5 Memory: 8GB 2133 MHz LPDDR3 Graphics: Intel UHD Graphics 617 1536MB Unity Version: 2022.2.21f1 Installed Unity Modules: ✅ iOS Build Support ✅ Mac Build Support (IL2CPP) ✅ IL2CPP Current Status & Key Issues: ✅ Xcode is properly installed, and xcode-select -p shows the correct path. ✅ xcodebuild -showsdks confirms that iOS SDK 18.2 is available. ✅ bee_backend is present and executable when checked manually. ❌ Unity still reports Unable to detect any compatible iPhoneOS SDK! during the build process. ❌ Unable to successfully build the iOS project. Could you please provide guidance on how to resolve this issue? Xcode Build Settings (for reference): ALWAYS_SEARCH_USER_PATHS = NO ARCHS = arm64 ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon CLANG_CXX_LANGUAGE_STANDARD = c++0x CLANG_CXX_LIBRARY = libc++ CLANG_ENABLE_OBJC_ARC = YES CODE_SIGN_IDENTITY[sdk=iphoneos*] = iPhone Distribution CODE_SIGN_IDENTITY[config=Debug] = Apple Development CODE_SIGN_IDENTITY[config=Release] = Apple Distribution CODE_SIGN_STYLE = Manual DEVELOPMENT_TEAM[sdk=iphoneos*] = 4429TL28T7 IPHONEOS_DEPLOYMENT_TARGET = 15.6 LD_RUNPATH_SEARCH_PATHS = $(inherited) @executable_path/Frameworks PRODUCT_BUNDLE_IDENTIFIER = com.torihiplay.DinoKite PROVISIONING_PROFILE_SPECIFIER[sdk=iphoneos*] = DinoKite. SDKROOT = iphoneos SUPPORTED_PLATFORMS = iphoneos TARGETED_DEVICE_FAMILY = 1,2 UNITY_RUNTIME_VERSION = 2022.2.21f1 UNITY_SCRIPTING_BACKEND = il2cpp This build is intended for a production release. I would appreciate any help in resolving this issue. Thank you!

Hello everyone, I’m facing an issue with running my app on my iPhone, and I’m hoping someone can help. Here’s my situation: I’m using Xcode 14.3.1 on macOS Ventura 13.7.4. My iPhone is running iOS 18.3.2 (Model: iPhone 14 Pro). When I connect my iPhone to Xcode, I get the error: "Could not locate device support files. You may be able to resolve the issue by installing the latest version of Xcode from the Mac App Store or developer.apple.com." I understand that Xcode 14.3.1 only supports up to iOS 16.4, and my iPhone’s iOS 18.3.2 is much newer. Unfortunately, I cannot update my macOS to Sonoma (14.x) due to hardware limitations, so I cannot install a newer version of Xcode (like 15.x or 16.x) that supports iOS 18.3.2. I’ve tried adding device support files manually, but the repositories I found (e.g., iGhibli/iOS-DeviceSupport and JinjunHan/iOSDeviceSupport) only have files up to iOS 16.4 or 17.3, and they don’t work for iOS 18.3.2. Does anyone have the device support files for iOS 18.3.2 (or a close version like 18.3) that I can add to my Xcode 14.3.1 to make it work with my iPhone? Alternatively, does anyone know a reliable source where I can download these files? Any other suggestions to resolve this issue without upgrading my macOS would be greatly appreciated! Thank you in advance for your help! [Your Name or Username]

Hi everyone, I’m trying to detect if Developer Mode is enabled on iOS 16+ devices using Swift but haven’t found any official APIs or documentation for this. Are there Apple-recommended ways to achieve this, or is it restricted for privacy/security reasons? Thanks!

Hi. I have a xcframework that has a dependency on 'RxSwift' and 'RxCocoa'. I deployed it using SPM by embedding it in a Swift Package. However when I import swift package into another project, I keep getting the following error: "Missing required module 'RxCocoaRuntime" How can I fix this? Below are the steps to reproduce the error. Steps Create Xcode proejct, make a dependency on 'RxSwift' and 'RxCocoa' (no matter doing it through tuist or cocoapods) Create XCFramework from that proejct. (I used commands below) xcodebuild archive \ -workspace SimpleFramework.xcworkspace \ -scheme "SimpleFramework" \ -destination "generic/platform=iOS" \ -archivePath "./SimpleFramework-iphoneos.xcarchive" \ -sdk iphoneos \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES xcodebuild archive \ -workspace SimpleFramework.xcworkspace \ -scheme "SimpleFramework" \ -archivePath "./SimpleFramework-iphonesimulator.xcarchive" \ -sdk "iphonesimulator" \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES xcodebuild -create-xcframework \ -framework "./SimpleFramework-iphoneos.xcarchive/Products/Library/Frameworks/SimpleFramework.framework" \ -framework "./SimpleFramework-iphonesimulator.xcarchive/Products/Library/Frameworks/SimpleFramework.framework" \ -output "./SimpleFramework.xcframework" Embed in Swift Package, and deploy. // swift-tools-version: 6.0 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: "SimplePackage", platforms: [.iOS(.v16)], products: [ .library( name: "SimplePackage", targets: ["SimplePackage"]), ], dependencies: [ .package(url: "https://github.com/ReactiveX/RxSwift", from: "6.8.0") ], targets: [ .binaryTarget( name: "SimpleFramework", path: "Sources/SimpleFramework.xcframework" ), .target( name: "SimplePackage", dependencies: [ "SimpleFramework", "RxSwift", .product(name: "RxCocoa", package: "RxSwift") ] ) ] ) Download Swift Package in another project and import module. I resolved this by removing dependencies from the Swift Package, downloading package in another project, and fetching dependencies by cocoapods. Thist works, but I don't want to use another dependency manager while using SPM. Development Environment CPU : Apple M4 Max MacOS : Sequoia 15.3 Xcode : 16.2

I’ve developed an Apple Watch extension for an existing iOS app. When I run the app on the watch via Xcode using the simulator, everything works fine. However, when I try to install it on my iPhone, the Watch app doesn’t show it in the "Available Apps" list, so I can't install it on the watch. The Apple Watch is connected to my iPhone, and I can see other apps available for installation without any issues. I also created a brand new project with watchOS support to troubleshoot, but the same problem occurred. Any ideas on how to resolve this?

Hi everyone, I've been working on an iOS app for about a year and a half. That application comes with unit and UI automated testings. Recently I started the development of the tvOS application so I added a new target and used the same bundle id as I want to eventually share purchases. What I need I'm working on an application that uses VLC (Need to play media more exotic than MP4) through these two pods pod 'MobileVLCKit', '3.6.0' (Only for iOS) pod 'TVVLCKit', '3.6.0' (Only for tvOS) What works Compilation works fine for both targets Unit tests work fine for both targets UI tests work fine ONLY for the original iOS target What doesn't work and how it fails When I launch the UI tests for the tvOS target, the compilation succeeds, but I get an error when calling app.launch() from my XCTestCase. Failed to get launch progress for <XCUIApplicationImpl: 0x600000c61e90 abergia.com.iptv at ...AppPath...>: App installation failed: Unable to Install “...AppName...”. This app is not made for this device. This app was not built to support this device family; app is compatible with ( 1, 2 ) but this device supports ( 3 ). (Underlying Error: Unable to Install “...AppName...”. This app is not made for this device. This app was not built to support this device family; app is compatible with ( 1, 2 ) but this device supports ( 3 ). What I tried Single target - Both Pods It looks like I can 'cheat' a little the system and make the Xcode target compatible with both iOS and tvO, but when declaring both pods inside the same CocoaPod target, the installation fails as one of the library is not compatible. Use a newer version of VLC (4.0.0) Works BUT that version is way too unstable, I will eventually use it again once they fix all the issues. Different Bundle ID Changing the bundle id of the tvOS application resolves the issue BUT I really want to use the same bundle id to share the purchases. Not UI testing the tvOS version It's an option I'm starting to contemplate out of frustration but I'm sure that we have people here who can help me!

Hi, I am in the last step "preparing for submission" and everything excepts "age rating" is fine. How can I fix this? I have two apps and on neither i can edit "age rating" :(

I just started working with Flutter. I use a Macbook m2 and my phone is an iPhone XR. I made a very simple application but no matter what I did, I couldn't start my application on my iPhone XR. I got help from all the AIs but we couldn't do it. I deleted everything including Xcode, Android Studio and Flutter and reinstalled them and I followed the SDK installation step by step on the Flutter page but I can't run my project on Xcode. I entered my Apple account including all the signings and certificates via the .workspace file extension but it didn't work. The error I get from Xcode keeps changing. We installed podfiles with the support I got from the AIs and after some fiddling, I got the only error right now: Command PhaseScriptExecution failed with a nonzero exit code

I have a warning on my AR app Virtual Tags that since July does not show its camera information telling: "ARCL.SceneLocationView implements focusItemsInRect: - caching for linear focus movement is limited as long as this view is on screen." I tried inserting the function, but documentation does not explain what it should return and how to generate it. Is someone able to help me? Thanks,

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?

Hello! When trying to use MLTensor, I am getting the error that it is not found in scope even though I am using Xcode 15.1 (it says fully up to date) and set my deployment target to iOS 17.2. Is there something else I need to be doing in order to use MLTensor? Thanks! Michael

When renaming a variable in the active scheme, it's not renamed for the non active ones. As a result when you have code that operates in both schemes (with #if os() conditions) a compile time error is introduced. Is this an Xcode bug or expected behaviour?