I have Xcode on my mac. I am iOS Dev. I do not know what version of Xcode was before I did next steps, but I could say that I had iOS Simulator 18.3.1. So I update my Xcode to Version 16.3 (16E140). At this version is available iOS Simulator 18.4. But from some time before Xcode separate downloading components and actual Xcode itself. So i make update and do not download latest iOS simulator. What i have: in Xcode -> Settings -> Components under " Other Installed Platforms" i have iOS 18.3.1 and 17.5 in Choose Destination dropdown menu i have nothing. And Xcode say me that i need install iOS Simulator. After some time with ChatGPT I could not do nothing from this. I try go to : Window -> Device and Simulators and here create new simulator with 18.3.1 and make it appear Always. But it didn't help. Solution I did: I download latest version 18.4 because i could not wait because i need fix bug only 1 hour shift and it was this hour so i fast download the simulator. After downloading 18.4 in Choose Destination dropdown it appears all versions of simulaors and 18.3.1 and that i created and 17.5 Question: Does Xcode force to install latest version of iOS simulator? What is the sense of this upgrade that now Xcode is updating faster because it download 8 GB not 16 if eventually I need download 8 GB again ? The new what i could do download Xcode in the evening and Simulator in the morning?

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 you try to reset settings through the Apple Vision Pro simulator (VisionOS 2.4) you get an error "Preferences quit unexpectedly". Bug report: FB17666053

Xcode version 16.4 (16F6) now only supports uploading a 1024x1024 icon, but during archiving, it keeps prompting that a 120x120 icon is missing. Attempts to add the image in Assets didn't work. How can this issue be resolved?"

The WatchOS developer is not allowed to obtain healthKit permission status. The result is always unauthorized (either by clicking the dot/cross in the upper left corner or by turning on all Health, on some, off all). WatchOS 开发获取 healthKit 的权限状态authorizationStatus不准。结果始终都是未授权（无论是点击左上角的点叉号还是开启全部健康项开关，开启部分，关闭所有），怎么处理？

I'm trying to distribute an app for internal testing but I'm always getting the below error and the SwiftSupport folder is not created although I tried different fixes/configurations. How can I debug/see the reason why the SwiftSupport folder is not generated? Xcode 16.4 Build version 16F6 I tried distributing from the Transporter, Xcode organizer, I tried to archive it both from Xcode and from the command line. There are a couple of answers on StackOverflow, nothing helped. What could be the problem? One of the things I tried: xcodebuild \ -project PhotoBook.xcodeproj \ -scheme PhotoBook \ -configuration Release \ -archivePath Release/PhotoBook.xcarchive \ -destination 'generic/platform=iOS' \ -verbose \ archive xcodebuild \ -exportArchive \ -archivePath Release/PhotoBook.xcarchive \ -exportPath Release \ -exportOptionsPlist ExportOptions.plist \ -destination 'generic/platform=iOS' \ -verbose ExportOptions.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>teamID</key> <string>T672CQXP54</string> <key>uploadSymbols</key> <true/> <key>uploadBitcode</key> <false/> <key>signingStyle</key> <string>manual</string> <key>provisioningProfiles</key> <dict> <key>com.mandelbrotsc.PhotoBook</key> <string>iOS Distribution Profile</string> </dict> </dict> </plist> The error: ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.

Hi, This maybe somewhat confusing, but please bear with me. I currently have an app in the App Store that supports iOS and tvOS. But the tvOS version was a separate app during the development process. I'd like to combine the iOS and tvOS app into one project so its easier to handle and keep track of internally. Can I upload the new Apple TV version to the same place where the current one is, or would I have to delete the current Apple TV version before uploading the newly combined version? I hope I made that clear enough :-) Thank you, Dan Uff

The Mac has an Intel chip and has Xcode 15.2 installed. After launching Xcode, the canvas interface keeps spinning and cannot display synchronously normally. The simulator also takes a long time to start. Seeking help to resolve this issue.

I've recently upgraded my project from Xcode 15 to Xcode 16. Without changing any build settings or compiler flags, I noticed that the final executable size has increased significantly when building the same C++ code. Investigation: To investigate further, I compared the Link Map outputs from both versions of Xcode. One key difference I found: The symbol size for std::sort increased from 4,336 bytes (Xcode 15) to 6,084 bytes (Xcode 16) – a ~40% increase. This seems to be part of a broader trend where other standard library symbols are also taking up more space in the binary when built with Xcode 16. Questions: Has Apple Clang or libc++ in Xcode 16 changed the implementation of STL algorithms like std::sort? Are there changes in inlining, template instantiation, or debug info that could explain the increase? Is this expected behavior? If so, is there any guidance on minimizing the binary size regression?

I’m exploring the new AI-assisted development features in Xcode 26, particularly the integration with MCP (Model Context Protocol) servers. I have two related questions about future capabilities: 1. Configuration flexibility – Will future versions of Xcode provide more granular configuration options? For example, being able to adjust model parameters, set custom request headers? 2. Custom MCP servers – Will it be possible to connect Xcode to a custom MCP servers? It would be great to know if these capabilities are on the roadmap, and if so, what the expected level of customization might be. Thank you.

hông thể cài đặt “TrungDemo” Domain: IXUserPresentableErrorDomain Code: 14 Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.kpOILI/extracted/TrungDemo.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Please ensure that the certificates used to sign your app have not expired. If this issue persists, please attach an IPA of your app when sending a report to Apple. User Info: { DVTErrorCreationDateKey = "2025-04-29 10:51:27 +0000"; IDERunOperationFailingWorker = IDEInstallCoreDeviceWorker; } Failed to install the app on the device. Domain: com.apple.dt.CoreDeviceError Code: 3002 User Info: { NSURL = "file:///Users/studiozego/Library/Developer/Xcode/DerivedData/TrungDemo-blspaulbkwypvhgaxxfjqbppuugg/Build/Products/Debug-iphoneos/TrungDemo.app"; } Không thể cài đặt “TrungDemo” Domain: IXUserPresentableErrorDomain Code: 14 Failure Reason: Không thể cài đặt ứng dụng này vì không thể xác minh tính toàn vẹn của ứng dụng. Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.kpOILI/extracted/TrungDemo.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.kpOILI/extracted/TrungDemo.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Domain: MIInstallerErrorDomain Code: 13 User Info: { FunctionName = "+[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]"; LegacyErrorString = ApplicationVerificationFailed; LibMISErrorNumber = "-402620392"; SourceFileLine = 80; } Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008132-0001786E22B9001C"; "device_isCoreDevice" = 1; "device_model" = "iPad16,4"; "device_osBuild" = "18.4 (22E240)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPad16,4-A"; "dvt_coredevice_version" = "443.19"; "dvt_coresimulator_version" = "1010.10"; "dvt_mobiledevice_version" = "1784.102.1"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = arm64; "operation_duration_ms" = 1320; "operation_errorCode" = 14; "operation_errorDomain" = IXUserPresentableErrorDomain; "operation_errorWorker" = IDEInstallCoreDeviceWorker; "operation_name" = IDERunOperationWorkerGroup; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphoneos"; "param_diag_113575882_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_mtc_enable" = 1; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 0; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_structuredConsoleMode" = 1; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphoneos18.4"; "sdk_osVersion" = "18.4"; "sdk_variant" = iphoneos; } System Information macOS Version 15.4.1 (Build 24E263) Xcode 16.3 (23785) (Build 16E140) Timestamp: 2025-04-29T17:51:27+07:00

I'm experiencing an issue here on my Xcode 16.4, where i can't download the supported iOS 18.6 runtime because it stays stuck on the 'preparing' state. I have also tried getting it manually from the dev site but they only have 18.2. The only runtime that would download easily via Xcode was 17.5 but I can't build my project with that. I have tried using curl to even get a download url, nothing worked. All my terminal approach didn't work also. Any help or guidance to sort this out? Thank you.

I am passing UUID Key from View1 to View2. In View2, I need to Fetch entries using TabKey. userId is global variable working fine. Giving error TabKey. Please help. how to get rid of this error. If I keep this logic inside init method, Getting new error saying that "Cannot convert value of type 'FetchedResults' to expected argument type 'Binding' Here is the Code. @FetchRequest( sortDescriptors: [NSSortDescriptor(keyPath: \Table2.date, ascending: false)], predicate: { guard let currentUserId = AppSession.shared.currentUserId else { return NSPredicate(value: false) // Or handle the nil case as needed } return NSPredicate(format: "userId == %@ AND itemKey == %@", currentUserId as CVarArg, TabKey as CVarArg ) }(), animation: .default ) private var itab: FetchedResults

I created an app that uses the camera function in Xcode, but it says I don't have camera permission. The app only runs once and then won't run again. The log below says "No active account." Is this because my paid account isn't properly reflected in Xcode? In Xcode Settings > Account, I'm logged in my acciunt, with the team set to "my Organization name" and the role set to "admin." However, in Manage Certificates, the Status is blank. It should say "Valid." How can I properly reflect my account in Xcode? Error enumerating all transactions: Error Domain=ASDErrorDomain Code=509 "No active account" UserInfo={NSLocalizedDescription=No active account}

I know there has been issues with SFSpeechRecognizer in iOS 17+ inside the simulator. Running into issues with speech not being recognised inside the visionOS 2.4 simulator as well (likely because it borrows from iOS frameworks). Just wondering if anyone has any work arounds or advice for this simulator issue. I can't test on device because I don't have an Apple Vision Pro. Using Swift 6 on Xcode 16.3. Below are the console logs & the code that I am using. Console Logs BACKGROUND SPATIAL TAP (hit BackgroundTapPlane) SpeechToTextManager.startRecording() called [0x15388a900|InputElement #0|Initialize] Number of channels = 0 in AudioChannelLayout does not match number of channels = 2 in stream format. iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending iOSSimulatorAudioDevice-22270-1: Abandoning I/O cycle because reconfig pending SpeechToTextManager.startRecording() completed successfully and recording is active. GameManager.onTapToggle received. speechToTextManager.isAvailable: true, speechToTextManager.isRecording: true GameManager received tap toggle callback. Tapped Object: None BACKGROUND SPATIAL TAP (hit BackgroundTapPlane) GESTURE MANAGER - User is already recording, stopping recording SpeechToTextManager.stopRecording() called GameManager.onTapToggle received. speechToTextManager.isAvailable: true, speechToTextManager.isRecording: false Audio data size: 134400 bytes Recognition task error: No speech detected <--- Code private(set) var isRecording: Bool = false private var recognitionRequest: SFSpeechAudioBufferRecognitionRequest? private var recognitionTask: SFSpeechRecognitionTask? @MainActor func startRecording() async throws { logger.debug("SpeechToTextManager.startRecording() called") guard !isRecording else { logger.warning("Cannot start recording: Already recording.") throw AppError.alreadyRecording } currentTranscript = "" processingError = nil audioBuffer = Data() isRecording = true do { try await configureAudioSession() try await Task.detached { [weak self] in guard let self = self else { throw AppError.internalError(description: "SpeechToTextManager instance deallocated during recording setup.") } try await self.audioProcessor.configureAudioEngine() let (recognizer, request) = try await MainActor.run { () -> (SFSpeechRecognizer, SFSpeechAudioBufferRecognitionRequest) in guard let result = self.createRecognitionRequest() else { throw AppError.configurationError(description: "Speech recognition not available or SFSpeechRecognizer initialization failed.") } return result } await MainActor.run { self.recognitionRequest = request } await MainActor.run { self.recognitionTask = recognizer.recognitionTask(with: request) { [weak self] result, error in guard let self = self else { return } if let error = error { // WE ENTER INTO THIS BLOCK, ALWAYS self.logger.error("Recognition task error: \(error.localizedDescription)") self.processingError = .speechRecognitionError(description: error.localizedDescription) return } . . . } } . . . }.value } catch { . . . } } @MainActor func stopRecording() { logger.debug("SpeechToTextManager.stopRecording() called") guard isRecording else { logger.debug("Not recording, nothing to do") return } isRecording = false Task.detached { [weak self] in guard let self = self else { return } await self.audioProcessor.stopEngine() let finalBuffer = await self.audioProcessor.getAudioBuffer() await MainActor.run { self.recognitionRequest?.endAudio() self.recognitionTask?.cancel() } . . . } }

If you need help investigating a crash, please include a crash report in your post. To smooth things along, follow these guidelines: For information on how to get a crash report, see Acquiring crash reports and diagnostic logs. Include the whole crash report as a text attachment (click the paperclip icon and then choose Add File). This avoids clogging up the timeline while also preserving the wealth of information in the crash report. If you’re not able to post your crash report as an attachment, see Can’t Post Crash Report as Attachment below. If you want to highlight a section of the report, include it in the main body of your post. Put the snippet in a code block so that it renders nicely. To create a code block, add a delimiter line containing triple backquotes before and after the block, or just click the Code Block button. If possible, post an Apple crash report. Third-party crash reporters are often missing critical information and have general reliability problems (for an explanation as to why, see Implementing Your Own Crash Reporter). Symbolicate your crash report before posting it. For information on how to do this, see Adding identifiable symbol names to a crash report. If you need to redact the crash report, do so consistently. Imagine you’re building the WaffleVarnish app whose bundle ID is com.example.wafflevarnish but you want to keep your new waffle varnishing technology secret. Replace WaffleVarnish with WwwwwwVvvvvvv and com.example.wafflevarnish with com.eeeeeee.wwwwwwvvvvvvv. This keeps the text in the crash report aligned while making it possible to distinguish the human-readible name of the app (WaffleVarnish) from the bundle ID (com.example.wafflevarnish). Finally, for information on how to use a crash report to debug your own problems, see Diagnosing issues using crash reports and device logs. Can’t Post Crash Report as Attachment Crash reports have two common extensions: .crash and .ips. If you have an .ips file, please post that [1]. DevForums lets you attach a .crash file but not an .ips file (r. 117468172). To work around this, change the extension to .txt. If DevForums complains that your crash report “contains sensitive language”, leave it out of your initial post and attach it to a reply. That often avoids this roadblock. If you still can’t post your crash report, upload it to a file sharing service and include the URL in your post. Post the URL in the clear, per tip 14 in Quinn’s Top Ten DevForums Tips. Getting a Crash Report from the Xcode Organiser The Xcode organiser shows crash reports from customers. If you’re investigating such a crash and want to post a crash report: Navigate to the crash in the Xcode organiser. Note If you can’t see the right crash, check the filter popups at the top. In the list of crashes, secondary click on your crash and choose Show in Finder. That reveals the Xcode crashpoint document (.xccrashpoint) in the Finder. Secondary click on that and choose Show Package Contents. In the resulting Finder window, find a crash report (.crash) that accurately represents the crash you’re investigating and attach that to your forums post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Because it’s easy to go from an .ips file to a .crash file. I usually do this by choosing File > Quick Look in the Finder. For more info about these file formats, see this post. Revision History: 2025-08-29 Added the Getting a Crash Report from the Xcode Organiser section. 2024-11-21 Added a recommendation to post the .ips format if possible. 2024-05-21 Added some advice regarding the “contains sensitive language” message. 2023-10-25 Added the Can’t Post Crash Report as Attachment section. Made other minor editorial changes. 2021-08-26 First posted.

https://maps.googleapis.com/maps/api/place/autocomplete/json?input=station%20bab%20saadoun&key=GOOGLE_API_KEY&components=country:TN func googleAutocomplete(for query: String, completion: @escaping ([GooglePlaces]) -> Void) { let apiKey = GoogleMapAPIs.shared.apiKey let baseURL = "https://maps.googleapis.com/maps/api/place/autocomplete/json" guard let url = URL(string: "\(baseURL)?input=\(query)&key=\(apiKey)&components=country:TN") else { print("Invalid URL") completion([]) return } print(url) let task = URLSession.shared.dataTask(with: url) { data, response, error in if let error = error { print("Error fetching data: \(error.localizedDescription)") completion([]) return } guard let data = data else { print("No data received") completion([]) return } do { let decodedResponse = try JSONDecoder().decode(GooglePlacesResponse.self, from: data) completion(decodedResponse.predictions) } catch { print("Decoding error: \(error)") completion([]) } } task.resume() } struct GooglePlaces: Codable { let title: String? let region: StructuredFormatting? let placeID: String? enum CodingKeys: String, CodingKey { case title = "description" case region = "structured_formatting" case placeID = "place_id" } } struct StructuredFormatting: Codable { let main_text: String let secondary_text: String? } struct GooglePlacesResponse: Codable { let predictions: [GooglePlaces] } Error fetching data: The network connection was lost.

Trying to configure info.plist and the base application the application works with the application. I consistently get two errors. Validation failed Disallowed UTTypes value. The Info.plist key 'UTTypeIdentifier' under 'UTImportedTypeDeclarations' in 'Blood Pressure Management V2.0.app' has disallowed values '[com.example.item-document]'. A Uniform Type Identifier starting with one of the patterns in the list '( "com.example." )' is disallowed. (ID: f2dbfe04-4f06-47ac-b74f-28ec238238c4) Validation failed The product archive is invalid. The value of the CFBundleDocumentTypes key in the Info.plist must be an array of dictionaries, with each dictionary containing at least the CFBundleTypeName key. (ID: fad3e65a-dc9d-4d9e-9506-703b874f71c6) Is there any clear documentation with examples? I have not found it yet.

Hi! I am having trouble getting my app to build successfully or archive since an xcode update a few months ago. Below is the error that shows in the log. Thank you in advance for any help! Run custom shell script 'Run Script' Failed to package [project folder]. Command PhaseScriptExecution failed with a nonzero exit code

how to fix https:// i.ibb.co/SwZ76KzZ/Screenshot-2025-08-07-at-10-35-24-AM.png