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.

General: DevForums tags: Debugging, LLDB, Graphical Debugger Xcode > Debugging documentation Diagnosing memory, thread, and crash issues early documentation Diagnosing issues using crash reports and device logs documentation Choosing a Network Debugging Tool documentation Testing a release build documentation Isolating Code Signing Problems from Build Problems DevForums post What is an exception? DevForums post Language Exception from RCTFatal DevForums post Standard Memory Debugging Tools DevForums post Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem DevForums post Posting a Crash Report DevForums post Creating a test project DevForums post Implementing Your Own Crash Reporter DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am trying to debug the AAX version of my plugin (MIDI effect) on Pro Tools, but I am getting the following error (Mac console) when attempting to load it: dlsym cannot find symbol g_dwILResult in CFBundle etc.. I used Xcode 16.4 to build the plugin. Has anybody come across the same or a similar message? Best, Achillefs Axart Labs

dSYM size became thrice for builds generated via xcode 26 compared to xcode 16. These are all release builds.

ICEcard app is "Emergency as a Service" platform. One of the key feature is to know about primary info, health info, or in case missing child , elderly using Face scan of registered user of app via another registered user of ICEcard app. App was working fine but last 2-3 week back got issue reported of app getting closed as soon Face scan option is selected. to simulate issue > register > open face scan icon at bottom home screen> select any of option accident or health issue or information >> app closes immediately. Android app is working fine. link of app store. https://apps.apple.com/in/app/ice-card-app/id6736453602 android link for reference https://play.google.com/store/apps/details?id=com.rannlab.ice_card.ice_card&pcampaignid=web_share

We are building a CarPlay app and have run into an issue with data updates. When the app is running on the CarPlay display and the iPhone screen is locked, no data updates are shown on the CarPlay screen. As soon as the phone is unlocked, the data updates appear instantly on the CarPlay display. Has anyone encountered this behavior before? Is there a specific setting, entitlement, or background mode we need to enable in order to ensure the CarPlay app continues to receive and display data while the iPhone is locked? Any guidance would be greatly appreciated.

When the app launches, it assigns the correct string stored in NSUserDefaults to the instance variable (serverAddress) of type NSString.
Afterwards, when the app transitions to a suspended state and receives a VoIP Push notification approximately 4 hours later, causing the app to enter the background state, referencing the value of serverAddress may result in it showing as <NSMallocBlock: 0x106452d60> even though it hasn't been deallocated. This does not occur every time. The specific class definitions are as follows. @implementation NewPAPEOPLEClient
{
    NSString* serverAddress;
    NSString* apiKey;
    dispatch_semaphore_t lock;
    NSMutableArray* errCallID;
} #define PREF_STR(key)  [[NSUserDefaults standardUserDefaults] stringForKey:(key) The global instance variable (serverAddress) is set with the following value when the application starts: serverAddress = PREF_STR(@"APP_CONTACT_SERVICE_SERVER_ADDRESS") Based on the above, please answer the following questions. (1) If the instance variable's value becomes <NSMallocBlock: 0x106452d60>, does that mean the memory area has been released? (2) Can the memory area of an instance variable be automatically released without being explicitly released?
 Can an instance variable of type NSString that is not autoreleased be automatically released? (3) Please tell me how to prevent the memory area from being automatically released. Will using retain prevent automatic release?

I have been using tvOS 18 and Xcode 26 all summer without issue but since updating the tv to the latest tvOS 26 beta I am now unable to attach to debug builds. When using the Run button in Xcode the build completes, the tv screen goes black and then I see a warning in Xcode: Launching "App Name" is taking longer than expected. Do you want to continue to wait? LLDB is likely reading from device memory to resolve symbols. If I continue to wait after around 5 mins, in the Xcode console, I see: warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. But the process on the tv hangs indefinately. Hitting stop in Xcode disconnects the debugger but the app then finishes launching successfully on the TV. Trying to use "Debug > Attach to process > [App Name]" once it is running also just hangs the app and waits until stopped. When stopping the hung debugger I see an Xcode error with the following: Could not attach to pid : “1222” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: internal error User Info: { DVTErrorCreationDateKey = "2025-09-01 09:51:54 +0000"; DVTRadarComponentKey = 855031; IDERunOperationFailingWorker = DBGLLDBLauncher; RawUnderlyingErrorMessage = "Xcode has killed the LLDB RPC server to allow the debugger to detach from your process. You may need to manually terminate your process."; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008110-000240CE1A87801E"; "device_isCoreDevice" = 1; "device_isWireless" = 1; "device_model" = "AppleTV14,1"; "device_osBuild" = "26.0 (23J5348a)"; "device_osBuild_monotonic" = 2309534800; "device_os_variant" = 1; "device_platform" = "com.apple.platform.appletvos"; "device_platform_family" = 4; "device_reality" = 1; "device_thinningType" = "AppleTV14,1"; "device_transport" = 2; "launchSession_schemeCommand" = Run; "launchSession_schemeCommand_enum" = 1; "launchSession_targetArch" = arm64; "launchSession_targetArch_enum" = 6; "operation_duration_ms" = 76122; "operation_errorCode" = 3; "operation_errorDomain" = IDEDebugSessionErrorDomain; "operation_errorWorker" = DBGLLDBLauncher; "operation_error_reportable" = 1; "operation_name" = IDERunOperationWorkerGroup; "param_consoleMode" = 0; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.appletvos"; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 0; "param_diag_allowLocationSimulation" = 0; "param_diag_checker_mtc_enable" = 0; "param_diag_checker_tpc_enable" = 0; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 1; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 256; "param_lldbVersion_component_idx_1" = 0; "param_lldbVersion_monotonic" = 170300300002; "param_runnable_appExtensionHostRunMode" = 0; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "appletvos26.0"; "sdk_osVersion" = "26.0"; "sdk_platformID" = 3; "sdk_variant" = appletvos; "sdk_version_monotonic" = 2309534400; } -- System Information macOS Version 26.0 (Build 25A5349a) Xcode 26.0 (24208.14) (Build 17A5305k) Timestamp: 2025-09-01T10:51:54+01:00 I have another AppleTV still running on tvOS 18 and builds continue to run and attach fine there. I've tried rebooting the 26 beta AppleTV but I'm at a bit of a loss what else to try?

We are experiencing troubles in our organization when we want to debug iOS applications on physical iPhones and iPads. Our iPhones (iPhone 16e, iOS 18.5) are not recognized by Xcode 16.4, but in the Finder they show up fine using the USB cable. We are aware, that the communication is different and there is an ad-hoc network that gets created to exchange the device profile. Together with our IT department responsible for our security infrastructure we narrowed it down to the following reason: As we are blocking all IPv6 traffic for local networking, the iPhone cannot communicate with Xcode to make the first connection and load the device profile. As they are not planning on changing this behavior, I am reaching out to you, if there is a way to force this first handshake between Xcode and iOS device to use IPv4? Or is there any other way to enable debugging for these devices? Any ideas would be very helpful.

Hi, I have a .NET MAUI app running on .NET 9. When I test locally in debug or release mode it works perfectly fine, but when testing from TestFlight it crashes almost immediately every time. I have sent the crash report to TestFlight and produced the symbolicated.crash file (attached), but I'm not sure it's helpful for understanding how to fix the issue. If anyone can help me understand what the issue might be and any possible fixes it'd be very much appreciated. I'm developing using Visual Studio 2022 paired to my Mac. I have distributed previously without issue, but now can't seem to, even after reverting recent code. net9.0-ios 15.0 symbolicated.crash

Xcode will transfer the app to the iPhone, and I can run it on the iPhone, but the Xcode debugger fails to attach. I am using iPhone 14 Pro with iOS 18.6. I've tried connecting via cable, also via network - same issue both ways. The message raised by Xcode says: Could not attach to pid: "6303" Ensure “<a\AppName>” is not already running, and has permission to debug it. I don't know how to determine if I have permission. I assume I do; I am the owner of the account, with admin role.

Intro I am reporting multiple persistent UI animation issues observed in tvOS 26 (Beta 6). These issues have been reproducible across multiple tvOS releases. They are subtle but noticeable, and they affect the overall polish and perceived quality of the system. I am happy to provide high-quality video captures for each of the issues described below. ⸻ Bug #1: App launch animation stutter/jump Summary: The zoom-in animation from a Springboard icon to full-screen app stutters or jumps at the moment the app becomes full screen. Steps to reproduce: 1. On Springboard, select any app icon. 2. Observe the zoom-in animation. Expected result: Smooth, continuous zoom without frame drops or jumps. Actual result: Animation visibly stutters/jumps at the full-screen transition. Possible cause: Timing issue in Core Animation interpolation or abrupt view hierarchy switch. ⸻ Bug #2: Text rendering weight change (“jump”) during transitions Summary: Text inside apps changes visual weight mid-transition from scaled preview to full screen. Steps to reproduce: 1. From Springboard or App Switcher, launch an app with visible text. 2. Observe text during the zoom animation — initially slightly bolder, then thinner once full screen. Also occurs in: • Top Shelf banners in the Dock • App Switcher → full-screen transitions Expected result: Consistent text rendering throughout the transition. Actual result: Visible “pop” in text weight/anti-aliasing during transition. Possible cause: Different rasterization/anti-aliasing mode between preview snapshot (CALayer.contents) and live CoreText/UIKit rendering. ⸻ Bug #3: Focus shadow jumps instead of interpolating smoothly Summary: Shadows around focused UI elements (icons, buttons) change abruptly during focus transitions. Steps to reproduce: 1. Navigate between focusable UI elements on Springboard or in apps. 2. Observe the shadow effects. Expected result: Shadows interpolate smoothly (offset, opacity, radius) during focus transitions. Actual result: Shadows “jump” abruptly, breaking animation smoothness. Possible cause: UIFocusEngine not interpolating shadow parameters consistently. ⸻ Bug #4: Abrupt jumps when swiping horizontally between content items Summary: In horizontally scrollable poster/content rows, focus snaps abruptly instead of scrolling smoothly. Steps to reproduce: 1. In the TV app or any app with horizontal poster rows, swipe left/right. 2. Observe the transition between focused items. Expected result: Smooth horizontal navigation with continuous motion. Actual result: Occasional abrupt snapping/jumping between items. ⸻ Impact While none of these bugs block core functionality, they degrade the premium feel and visual polish of tvOS. They are persistent across releases and occur in core system UI, so they are visible to all users. Note I can provide video recordings for each bug to assist engineering in reproducing and analyzing the issues.

I regularly bump into folks confused by this issue, so I thought I’d collect my thoughts on the topic into a single (hopefully) coherent post. If you have questions or comments, put them in a new thread here on the forums. Feel free to use whatever subtopic and tags that apply to your situation, but make sure to add the Debugging tag so that I see your thread go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Testing and Debugging Code Running in the Background I regularly see questions like this: My background code works just fine in Xcode but fails when I download the app from the App Store. or this: … or fails when I run my app from the Home screen. or this: How do I step through my background code? These suggest a fundamental misunderstanding of how the debugger interacts with iOS’s background execution model. The goal of this post is to explain that misunderstanding so that you can effectively test and debug background code. Note The focus of this post is iOS. The advice here generally applies to any of iOS’s ‘child’ platforms, so iPadOS, tvOS, and so on. However, there will be some platform specific differences, especially on watchOS. This advice here doesn’t apply to macOS. It’s background execution model is completely different than the one used by iOS. Understand the Fundamentals The key point to note here is that the debugger prevents your app from suspending. This has important consequences for iOS’s background execution model. Normally: iOS suspends your app when it’s in the background. Once your app is suspended, it becomes eligible for termination. The most common reason for this is that the system wants to recover memory, but it can happen for various other reasons. For example, the system might terminate a suspended app in order to update it. Under various circumstances your app can continue running after moving to the background. A great example of this is the continued processed task feature, introduced in iOS 26 beta. Alternatively, your app can be resumed or relaunched in the background to perform some task. For example, the region monitor feature of Core Location can resume or relaunch your app in the background when the user enters or leaves a region. If no app needs to be executing, the system can sleep the CPU. None of this happens in the normal way if the debugger is attached to your app, and it’s vital that you take that into account when debugging code that runs in the background. An Example of the Problem For an example of how this can cause problems, imagine an app that uses an URLSession background session. A background session will resume or relaunch your app in the background when specific events happen. This involves two separate code paths: If your app is suspended, the session resumes it in the background. If your app is terminated, it relaunches it in the background. Neither code path behaves normally if the debugger is attached. In the first case, the app never suspends, so the resume case isn’t properly exercised. Rather, your background session acts like it would if your app were in the foreground. Normally this doesn’t cause too many problems, so this isn’t a huge concern. On the other hand, the second case is much more problematic. The debugger prevents your app from suspending, and hence from terminating, and thus you can’t exercise this code path at all. Seek Framework-Specific Advice The above is just an example, and there are likely other things to keep in mind when debugging background code for a specific framework. Consult the documentation for the framework you’re working with to see if it has specific advice. Note For URLSession background sessions, check out Testing Background Session Code. The rest of this post focuses on the general case, offering advice that applies to all frameworks that support background execution. Run Your App Outside of Xcode When debugging background execution, launch your app from the Home screen. For day-to-day development: Run the app from Xcode in the normal way (Product > Run). Stop it. Run it again from the Home screen. Alternatively, install a build from TestFlight. This accurately replicates the App Store install experience. Write Code with Debugging in Mind It’s obvious that, if you run the app without attaching the debugger, you won’t be able to use the debugger to debug it. Rather: Extract the core logic of your code into libraries, and then write extensive unit tests for those libraries. You’ll be able to debug these unit tests with the debugger. Add log points to help debug your integration with the system. Treat your logging as a feature of your product. Carefully consider where to add log points and at what level to log. Check this logging code into your source code repository and ship it — or at least the bulk of it — as part of your final product. This logging will be super helpful when it comes to debugging problems that only show up in the field. My general advice is that you use the system log for these log points. See Your Friend the System Log for lots of advice on that front. One of the great features of the system log is that disabled log points are very cheap. In most cases it’s fine to leave these in your final product. Attach and Detach In some cases it really is helpful to debug with the debugger. One option here is to attach to your running app, debug a specific thing, and then detach from it. Specifically: To attach to a running app, choose Debug > Attach to Process > YourAppName in Xcode. To detach, choose Debug > Detach. Understand Force Quit iOS allows users to remove an app from the multitasking UI. This is commonly known as force quit, but that’s not a particularly accurate term: The multitasking UI doesn’t show apps that are running, it shows apps that have been run by the user. The UI shows recently run apps regardless of whether they’re in the foreground, running in the background, suspended, or terminated. So, removing an app from the UI may not actually quit anything. Removing an app sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Keep these behaviours in mind as you debug your background execution code. For example, imagine you’re trying to test the URLSession background relaunch code path discussed above. If you force quit your app, you’ll never hit this code path because iOS won’t relaunch your app in the background. Rather, add a debug-only button that causes your app to call exit. IMPORTANT This suggestion is for debugging only. Don’t include a Quit button in your final app! This is specifically proscribed by QA1561. Alternatively, if you’re attached to your app with Xcode, simply choose Product > Stop. This is like calling exit; it has no impact on your app’s ability to run in the background. Test With Various Background App Refresh Settings iOS puts users in control of background execution via the options in Settings > General > Background App Refresh. Test how your app performs with the following settings: Background app refresh turned off overall Background app refresh turned on in general but turned off for your app Background app refresh turned on in general and turned on for your app IMPORTANT While these settings are labelled Background App Refresh, they affect subsystems other than background app refresh. Test all of these cases regardless of what specific background execution feature you’re using. Test Realistic User Scenarios In many cases you won’t be able to fully test background execution code at your desk. Rather, install a TestFlight build of your app and then use the device as a normal user would. For example: To test Core Location background execution properly, actual leave your office and move around as a user might. To test background app refresh, use your app regularly during the day and then put your device on charge at night. Testing like this requires two things: Patience Good logging The system log may be sufficient here, but you might need to investigate other logging solutions that are more appropriate for your product. These testing challenges are why it’s critical that you have unit tests to exercise your core logic. It takes a lot of time to run integration tests like this, so you want to focus on integration issues. Before starting your integration tests, make sure that your unit tests have flushed out any bugs in your core logic. Revision History 2025-08-12 Made various editorial changes. 2025-08-11 First posted.

Hello everyone, I'm encountering a MultipeerConnectivity connection issue while developing a visionOS app and would like to ask if other developers have experienced similar problems. Problem Description In visionOS 26.0 Beta 3 and Beta 4, when a visionOS device attempts to connect to an iPad via MultipeerConnectivity, the iPad side completely fails to receive connection requests, resulting in connection establishment failure. Specific Symptoms After executing serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) on the visionOS side The iPad side shows no response and receives no connection invitation Connection request times out after 10 seconds and is automatically rejected No error logs or exception information are generated Environment Information visionOS version: 26.0 Beta 3 and Beta 4 Development environment: macOS Tahoe 26.0 Beta (25A5306g) Target device: iPad (iOS 17.x) Network environment: Same WiFi network Comparative Test Results visionOS 2.6 (22O785): Functionality completely normal visionOS 26.0 Beta 1/2: Functionality normal visionOS 26.0 Beta 3/4: Exhibits the above problems Attempted Solutions Checked network configuration and firewall settings Adjusted MultipeerConnectivity parameters Reinitialized MCSession and MCNearbyServiceBrowser Cleared app cache and reinstalled Reset network settings Temporary Workaround Currently, the only solution is to downgrade the visionOS device to version 2.6. Impact of the Problem This issue severely affects the development of cross-device collaboration features in visionOS apps, particularly scenarios requiring peer-to-peer communication with iOS/iPadOS devices. Questions for Help Have other developers encountered similar issues? Are there any known solutions or workarounds? Is this a known issue with visionOS 26.0 Beta? Are there other known issues related to MultipeerConnectivity? Relevant Code Snippet // Connection invitation code private var serviceBrowser: MCNearbyServiceBrowser? let mcSession: MCSession // Execute connection invitation serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) Thank you for your help and suggestions! Development Environment: Xcode 15.x Target Platform: visionOS

I currently have a custom UITextView that properly changes the color of a link to the custom color I have set, however, when I click and hold the link, and the animation plays that makes the link bigger and creates a boarder around the link before previewing the website, the link changes briefly back to the system default color, and when letting go, it changes back to my custom color. Is there anyway to have the link always be my custom color, even when clicking and holding? struct AutoDetectedClickableDataView: UIViewRepresentable { let text: String let dataDetectors: UIDataDetectorTypes @Binding var height: CGFloat private func dataDectectorValue(_ dataDectecor: UIDataDetectorTypes) -> UInt64 { var checkingTypes: [NSTextCheckingResult.CheckingType] = [] if dataDetectors.contains(.phoneNumber) { checkingTypes.append(.phoneNumber) } if dataDetectors.contains(.link) { checkingTypes.append(.link) } if dataDetectors.contains(.address) { checkingTypes.append(.address) } if dataDetectors.contains(.calendarEvent) { checkingTypes.append(.date) } if checkingTypes.isEmpty { return 0 } let intCheckingTypes: UInt64 = checkingTypes.reduce(0) { result, checkingType in UInt64(result) | UInt64(checkingType.rawValue) } return intCheckingTypes } func makeUIView(context: Context) -> UITextView { let textView = UITextView() textView.dataDetectorTypes = dataDetectors textView.isEditable = false textView.isScrollEnabled = false textView.backgroundColor = .clear textView.font = UIFontMetrics(forTextStyle: .body).scaledFont(for: UIFont.systemFont(ofSize: 16.0), compatibleWith: textView.traitCollection) textView.textColor = UIColor.label textView.adjustsFontForContentSizeCategory = true textView.textContainer.lineBreakMode = .byWordWrapping textView.textContainerInset = .zero textView.textContainer.lineFragmentPadding = 0 textView.translatesAutoresizingMaskIntoConstraints = false textView.setContentCompressionResistancePriority(.defaultLow, for: .horizontal) textView.setContentHuggingPriority(.defaultHigh, for: .horizontal) textView.linkTextAttributes = [.foregroundColor: JeromesColors.UILinkColor] textView.tintColor = JeromesColors.UILinkColor for gesture in textView.gestureRecognizers ?? [] { if gesture is UITapGestureRecognizer { gesture.view?.tintColor = JeromesColors.UILinkColor } } return textView } func updateUIView(_ uiView: UITextView, context: Context) { let font = UIFontMetrics(forTextStyle: .body).scaledFont(for: UIFont.systemFont(ofSize: 16.0), compatibleWith: uiView.traitCollection) let color = UIColor.label let attributed = NSMutableAttributedString(string: text, attributes: [ .font: font, .foregroundColor: color ]) let detectorValue = dataDectectorValue(dataDetectors) var matchCount = 0 if !dataDetectors.isEmpty, detectorValue != 0 { let detector = try? NSDataDetector(types: detectorValue) detector?.enumerateMatches(in: text, options: [], range: NSRange(location: 0, length: text.utf16.count)) { match, _, _ in guard let match = match else { return } if match.resultType == .date, let date = match.date, date < Date() { return } else { attributed.addAttributes([ .foregroundColor: JeromesColors.UILinkColor, .underlineStyle: NSUnderlineStyle.single.rawValue, ], range: match.range) matchCount += 1 } } } uiView.attributedText = attributed if matchCount == 0 { uiView.isSelectable = false } else if matchCount > 0 { uiView.isSelectable = true } DispatchQueue.main.async { uiView.layoutIfNeeded() let fittingSize = CGSize(width: uiView.bounds.width, height: .greatestFiniteMagnitude) let size = uiView.sizeThatFits(fittingSize) height = size.height } } }

My Xcode version is 16.4, I have added an old version simulator (iPhone 13 with iOS 17.2) to the simulator list, but I can't use it for debugging, and all on display are iPhone 16 with 18.6 (the latest iOS devices). The setting "Minimum Deployments" for my App is 16.6. In addition, when I downloaded an iOS 16.0 version simulator, Xcode automatically added all iPhone 15 models of the simulator, but I still can't use them. In short, I can only use the default iPhone 16 simulators. So, if I want to debug my App using iPhone 13 (iOS 17.2), what should I do? Thank you for your reply. :) Another small issue, my App's destination has been set to support only iPhone, why are those iPad simulators still appearing?

I am building a widget that supports 2 different widget kinds, each supporting systemSmall, systemMedium, and systemLarge size families. My widget does download and display images so I expect memory usage to be on the higher end, but in debugging some memory issues, I notice that when I build my widget scheme to a physical device, things start off reasonable at ~12MB of memory usage. But as I change the widgets intent, add the other widget kind, or add different widget size families, this memory usage grows until it ultimately hits the 30MB cap. My question is, is the 30MB memory limit spread across all my supported widget kinds/sizes? Or does each individual widget get its own 30MB cap? i.e., if I have systemMedium Widget A and systemLarge Widget B, are they sharing that 30MB memory limit?

I'm experiencing a specific issue where when using any of the MacOS 26 Tahoe betas with Low Power Mode enabled and using Vsync in fullscreen, my application framerate gets limited to a hard 30 fps. I have not experienced this on any older OS. For example Low Power Mode on 13.6 Ventura with Vsync fullscreen lets my application run at full 60 fps without issues. Is this a bug or a change in behavior of Low Power Mode on Tahoe? My application is 3D, runs at 60 fps and is sensitive to tearing, so I need Vsync and it is mostly utilized in fullscreen. And Low Power Mode is a default for many Macs, so default experience on Tahoe currently is a halved 30 fps. However there also seems to be inconsistencies of on which machines this happens, but older OSes are always fine.

As of now, there is no Kernel Debug Kit (KDK) available for macOS 26.0 Developer Betas after the first build. Kernel Debug Kits are crucial for understanding panics and other bugs within custom Kernel Extensions. Without the KDK for the corresponding macOS version, tools like kmutil fail to recognize a KDK and certain functions are disabled. Additionally, as far as I am aware, a KDK for one build of macOS isn't able to be used on a differing build. Especially since this is a developer beta, where developers are updating their software to function with the latest versions of macOS, I'd expect a KDK to be available for more than one build.

Hello everyone, I am having an issue where the attributed text that I have in my UITextView is not scaling dynamically with phone text size, whenever I remove the attributed text logic, it scales fine, however, with it, it stays at a set font size. struct AutoDetectedClickableDataView: UIViewRepresentable { let text: String @Binding var height: CGFloat func makeUIView(context: Context) -> UITextView { let textView = UITextView() textView.dataDetectorTypes = [.phoneNumber, .address, .link] textView.isEditable = false textView.isScrollEnabled = false textView.backgroundColor = .clear textView.font = UIFont.preferredFont(forTextStyle: .body) /*UIFontMetrics(forTextStyle: .body).scaledFont(for: UIFont.systemFont(ofSize: 16.0)) */ textView.adjustsFontForContentSizeCategory = true textView.textContainer.lineBreakMode = .byWordWrapping textView.textContainerInset = .zero textView.textContainer.lineFragmentPadding = 0 textView.translatesAutoresizingMaskIntoConstraints = false textView.setContentCompressionResistancePriority(.defaultLow, for: .horizontal) textView.setContentHuggingPriority(.defaultHigh, for: .horizontal) return textView } func updateUIView(_ uiView: UITextView, context: Context) { let attributed = NSMutableAttributedString(string: text, attributes: [ .font: UIFont.preferredFont(forTextStyle: .body) ]) let detector = try? NSDataDetector(types: NSTextCheckingResult.CheckingType.address.rawValue | NSTextCheckingResult.CheckingType.link.rawValue | NSTextCheckingResult.CheckingType.phoneNumber.rawValue) detector?.enumerateMatches(in: text, options: [], range: NSRange(location: 0, length: text.utf16.count)) { match, _, _ in guard let match = match else { return } attributed.addAttributes([ .foregroundColor: UIColor.systemBlue, .underlineStyle: NSUnderlineStyle.single.rawValue, ], range: match.range) } uiView.attributedText = attributed // uiView.text = text DispatchQueue.main.async { uiView.layoutIfNeeded() let fittingSize = CGSize(width: uiView.bounds.width, height: .greatestFiniteMagnitude) let size = uiView.sizeThatFits(fittingSize) height = size.height } } }

I'm developing a web extension for Safari on iOS using MV3. The extension is working fine in Chrome, but in Safari I experience some seemingly random issues. I would like to debug it, but here is my problem. I have my iPhone connected via cable to Mac, and it works fine with XCode, so I assume this part is OK. I open Safari or Safari Tech Preview (doesn't matter) on my Mac, developers options are enabled, and in the Develop menu, under my iPhone section, there are things I can debug. There is an entry "[Ext name] - Extension Service Worker" but when I click it, it's empty. Web inspector pops up, but there are no network requests, no logs, nothing. I know the extension is working, because I can stream log to my HTTP server, but I don't see them here at all. I can use console to trigger commands like chrome.storage.local.get(null, console.log) and it shows my local store, so why I don't see any logs? Also, the background script is not visible in the Sources tab, just one weird request: navigator.serviceWorker.register('safari-web-extension://E3449EA7-EC25-4696-8E6C-[ID HERE]/background.js'); </script> Any ideas what went wrong? The entire team of 4 people has the same issue and we can't move forward because of that. Also, the Develop => Service workers or any other menu section doesn't show my service worker. Logs for websites running on my phone are visible and in general web inspector for them works fine.

I am currently having an issue in where whenever I place a UITextView with text that's long, it simply pushes past the width of the container it is in, and when I do try and set a width, it does auto wrap and ignores that. I do not come from UIKit and come from SwiftUI, through a mix of ChatGPT and Stack overflow, I have come up with this solution, however, are there any better/simpler ones, I dont want to have to use expensive GeoReaders just to get a width. struct AutoDetectedPhoneNumberView: UIViewRepresentable { let text: String var width: CGFloat func makeUIView(context: Context) -> UITextView { let textView = UITextView() textView.dataDetectorTypes = [.phoneNumber] textView.isEditable = false textView.isScrollEnabled = false textView.backgroundColor = .clear textView.font = UIFont.systemFont(ofSize: 16) textView.textContainer.lineBreakMode = .byWordWrapping textView.translatesAutoresizingMaskIntoConstraints = false print(width) NSLayoutConstraint.activate([ textView.widthAnchor.constraint(equalToConstant: width) ]) return textView } func updateUIView(_ uiView: UITextView, context: Context) { uiView.text = text } } GeometryReader { geo in AutoDetectedPhoneNumberView(text: phone, width: geo.size.width) }