Hi, I am using a rich, detailed view to show information in an MKAnnotationView's detailAccessoryView. As such, I don't need to use the 'title' or 'subtitle' fields that come with the callout view. However, I also want to show the 'title' under the MKMarkerAnnotationView on the map. Unfortunately it looks like the same MKAnnotation's 'title' property is used for both the marker's name on the map, as well as in the callout view. So I'm trying to figure out if there's any way to hide the 'title' in just the callout view. One thing I was considering was hiding the 'title' when an annotationView is selected, but doing this in 'didSelectAnnotationView' is too late to take affect for the callout view, and there doesn't seem to be an option for a delegate call like 'willSelectAnnotationView'. Is there any other way to figure out just before the annotation is selected?

I want to use the "SF Pro Text" font in my app. It works fine when I build my app on my main computer running macOS11 Big Sur, but I have a 2nd partition to run macOS Monterey, and it doesn't seem to be available there at all, whether through Interface Builder or through code (using NSFontManager). Using this returns nil on my Monterey partition: NSFont* regularFont = [[NSFontManager sharedFontManager] fontWithFamily:@"SF Pro Text" traits:NSFontWeightRegular weight:5 size: 16.0]; Maybe I'm missing something here ... should I have to install the font manually? I thought the SF Font is a 'system font', so it would be available on all Macs?

I have been using CLGeocoder’s “geocodePostalAddress” API for many years, and it’s been working just fine. Since yesterday, a lot of users have started complaining that they are getting “no results” for their geocoding requests, and I have also confirmed this case. It seems like the “geocodePostalAddress” returns “No Result” in many cases where it used to work correctly before, even though the “geocodeAddressString” API still works correctly. Has anyone else noticed this problem? Has there been some server change that is causing this? Here's a unit test I wrote to test this out: import CoreLocation final class CJTestCLGeocoderRequests: XCTestCase { func testGeocoderWithCNPostalAddressBerkeley() async throws {         let geocoder = CLGeocoder()         do {             let postalAddress = CNMutablePostalAddress()                         postalAddress.street = "2300 College Ave"             postalAddress.city = "Berkeley"             postalAddress.state = "CA"             postalAddress.postalCode = "94108"             postalAddress.country = "United States"             let placemarks3 = try await geocoder.geocodePostalAddress(postalAddress)             XCTAssertTrue(placemarks3.count > 0, "Geocoder works and gets an placemark")             XCTAssertTrue(placemarks3.first?.postalCode == "94108", "Geocode placemark has right postal code")         } catch {             XCTFail("Geocoder failed: placemarks = \(error).") // get failure here, with error code 8 (         }         do {             let collegeAveString = "2300 College Ave, Berkeley, CA, 94704, United States"             let placemarksString = try await geocoder.geocodeAddressString(collegeAveString)             XCTAssertTrue(placemarksString.count > 0, "Geocoder works and gets an placemark")             XCTAssertTrue(placemarksString.first?.postalCode == "94704", "Geocode placemark has right postal code")         } catch {             XCTFail("Geocoder failed: placemark string = \(error).")         }     } Would love any help regarding this.

Hi, I have been using the BackgroundTasks API on iOS for a while, and it works great. I want to do something similar on macOS, where I can easily run some background process from my app every X minutes, even if the app is closed. My Mac app runs in the sandbox, and isn't Catalyst-based, so I can't run the UIKit 'BackgroundTasks' API, and I haven't found anything similar on macOS. Does something like that exist, that is easy to adopt?

Hi, I am developing a 'framework' for a client so they can embed some of my code into their own custom app. I'm confused a bit about the best option to distribute this. I have created an iOS 'framework' within my Xcode project and added all the necessary files there. Can I just build the framework and send them the build folder for the framework? Or is it better to generate an .xcframework that I read about somewhere? I'm just not completely sure about the benefits for distributing an .xcframework file (which there doesn't seem to be an option to generate from Xcode) over just the .framework folder from the built products? Thanks.

Hi, Ever since I updated to macOS Tahoe and started using Xcode 26 daily, I've run into an issue where it gets stuck very frequently when launching and running my app in the simulator. It happens with the main app target as well as when running unit tests. If I restart Xcode and the simulator app, it works fine again for a while, but after some use, it goes back to the same situation. In Activity Monitor, Xcode ends up at 1000% CPU utilization for a minute or more, basically rendering the simulator and the debugger stuck. If I untick the "Debug Executable" option in the scheme editor, it works fine as well. Anyone else run into the same situation, or are there any tips I can follow to fix this issue? It makes it really tedious to make changes and then be stalled for a minute or more to see the app run. I've restarted the Mac, erased the booted simulator as well. I'm on a MacBook Pro M4 Pro. Everything used to run fine before macOS Tahoe / Xcode 26 on my main device. In fact, I used to run macOS Tahoe / Xcode 26 beta versions on a separate partition without any problems.

Hi, I just saw the "Use the camera for keyboard input in your app" talk, and had a question about it's capability that wasn't covered. From what I could tell, you have to designate a particular UITextField / UITextView as the 'target' (or is it 'responder'?). If I want to parse different types of content (name, email, phone number) into different UITextFields, for e.g to fill out a form ... how would that work? I don't want the user to launch the camera 3 times, one for each text field. Or would it be best to dump the contents into a UITextView and then have it parse the contents and detect the content types? Thanks.

Hi, With iOS15, is there still a limit for how many UserNotifications can be scheduled locally on a device? A lot of places suggest that the limit is for 64 notifications at a time, and this limit has been there since UILocalNotifications were a thing. Has that changed at all? Considering that modern devices are so much more powerful than in the past, one would imagine that they should be handle more than a few local notifications in the system. I filed a Radar for this 5 years ago, which was changed to this Feedback Request: FB5978935

The iPhone 14 Pro has a A16 Bionic chip with 16 Billion transistors, two performance cores + 4 high-efficiency cores, a 5-core GPU and 16-core neural engine, and can perform 4 trillion OPS per photo. But sadly, we can only schedule up to 64 User Notifications on it (per app). This limitation has been there since iOS3 I believe, when UILocalNotifications were first introduced, along with the iPhone 3G. What gives? Why does this limit never seem to change? I would love to understand the reasons. I am trying to build a 'timer' app, and can't understand how to build one with this limitation in place (unless I use Remote Push notifications, which requires a lot of infrastructure outside the app). Btw, I filed a Radar for this 5 years ago, which was changed to this Feedback Request: FB5978935

I am getting sporadic reports from end-users about a crash in my SwiftUI view. This is what the symbolicated crash report looks like: Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0 Thread 0 name: Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000001ba42e84c __pthread_kill + 8 1 libsystem_pthread.dylib 0x00000001d6cfc9e8 pthread_kill + 212 (pthread.c:1392) 2 libsystem_c.dylib 0x00000001972688f4 abort + 100 (abort.c:110) 3 AttributeGraph 0x00000001b5d36c7c AG::precondition_failure(char const*, ...) + 188 (ag-util.cc:51) 4 AttributeGraph 0x00000001b5d1cb84 AG::data::table::grow_region() + 288 (ag-data.cc:67) 5 AttributeGraph 0x00000001b5d1ced0 AG::data::table::alloc_page(AG::data::zone&, unsigned int) + 588 (ag-data.cc:212) 6 AttributeGraph 0x00000001b5d1d268 AG::data::zone::alloc_slow(unsigned int, unsigned int) + 228 (ag-data.cc:339) 7 AttributeGraph 0x00000001b5d1d524 AG::data::zone::alloc_bytes_recycle(unsigned int, unsigned int) + 240 (ag-data.h:417) 8 AttributeGraph 0x00000001b5d1d3b8 AG::data::zone::realloc_bytes(AG::data::ptrvoid&, unsigned int, unsigned int, unsigned int) + 112 (ag-data.cc:387) 9 AttributeGraph 0x00000001b5d25b64 AG::data::vectorAG::OutputEdge::reserve_slow(AG::data::zone&, unsigned int) + 96 (ag-data-vector.h:191) 10 AttributeGraph 0x00000001b5d237d4 void AG::Graph::add_output_edgeAG::Node(AG::data::ptrAG::Node, AG::AttributeID) + 144 (ag-data-vector.h:172) ... 73 SwiftUI 0x0000000194f3287c closure #1 in ViewRendererHost.updateViewGraphA(body:) + 92 (ViewRendererHost.swift:92) 74 SwiftUI 0x0000000194f2b0b4 ViewRendererHost.updateViewGraphA(body:) + 88 (compiler-generated:0) 75 SwiftUI 0x0000000194f31328 ViewRendererHost.sizeThatFits(_:) + 112 (ViewRendererHost.swift:249) 76 SwiftUI 0x0000000195087980 _UIHostingView.sizeThatFits(_:) + 112 (UIHostingView.swift:1865) 77 SwiftUI 0x00000001950879c8 @objc _UIHostingView._baselineOffsets(at:) + 48 78 UIKitCore 0x0000000190b58bf8 -[UIView(_UIConstraintBasedLayoutEmbedding) _layoutSizeThatFits:fixedAxes:] + 84 (UIView_UnifiedLayout.m:27) 79 UIKitCore 0x00000001911f5214 -[UIView(UIConstraintBasedLayout) intrinsicContentSize] + 92 (NSLayoutConstraint_UIKitAdditions.m:2112) 86 CoreAutoLayout 0x00000001a2b73934 -[NSISEngine withBehaviors:performModifications:] + 80 (NSISEngine.m:1917) 87 UIKitCore 0x00000001911fea98 __100-[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededWithViewForVariableChangeNotifications:]_block_invoke + 88 (NSLayoutConstraint_UIKitAdditions.m:4458) 88 UIKitCore 0x00000001911fd4bc -[UIView(AdditionalLayoutSupport) _withUnsatisfiableConstraintsLoggingSuspendedIfEngineDelegateExists:] + 120 (NSLayoutConstraint_UIKitAdditions.m:4157) 89 UIKitCore 0x00000001911fe6e4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededWithViewForVariableChangeNotifications:] + 160 (NSLayoutConstraint_UIKitAdditions.m:4457) 90 UIKitCore 0x00000001911ff6bc -[UIView(AdditionalLayoutSupport) _updateConstraintsAtEngineLevelIfNeededWithViewForVariableChangeNotifications:] + 428 (NSLayoutConstraint_UIKitAdditions.m:4722) 91 UIKitCore 0x00000001912cee00 -[UIView(Hierarchy) layoutBelowIfNeeded] + 860 (UIView.m:12277) 92 CJournal 0x00000001029e2894 MapCalloutView.setupView() + 948 (MapCalloutView.swift:80) 93 CJournal 0x00000001029e2aa0 specialized MapCalloutView.init(rootView:) + 320 (MapCalloutView.swift:43) 94 CJournal 0x0000000102a3b01c MapCalloutView.init(rootView:) + 8 (MapCalloutView.swift:0) 95 CJournal 0x0000000102a3b01c MapCalloutView.__allocating_init(rootView:) + 24 (CJMapsCalloutController.swift:19) 96 CJournal 0x0000000102a3b01c CJMapsCalloutController.makeMapsCalloutView() + 252 97 CJournal 0x0000000102a3b070 @objc CJMapsCalloutController.makeMapsCalloutView() + 28 (compiler-generated:0) 98 CJournal 0x00000001027cb2a8 -[CJCustomAnnotationView setupAnnotationDetailAccessoryViewWithAddress:] + 312 (CJCustomAnnotationView.m:114) 99 CJournal 0x00000001027cb154 -[CJCustomAnnotationView setupAnnotationForPersonAddress:] + 553300 (CJCustomAnnotationView.m:0) 100 CJournal 0x00000001027cb370 -[CJCustomAnnotationView setupAnnotationForClusterAnnotation:] + 553840 (CJCustomAnnotationView.m:0) 101 CJournal 0x00000001027cad70 -[CJCustomAnnotationView configureAnnotationViewWithAnnotation:] + 552304 (CJCustomAnnotationView.m:38) 102 CJournal 0x00000001027cacec -[CJCustomAnnotationView initWithAnnotation:reuseIdentifier:withDefaultColor:withCalloutDelegate:] + 552172 (CJCustomAnnotationView.m:32) 103 CJournal 0x0000000102884f74 -[MapViewShared annotationViewForMap:forAnnotation:withCalloutDelegate:] + 1314676 (MapViewShared.m:62) I'm not displaying a complicated SwiftUI view ... it's not based on List or Form and doesn't have Navigation either, though it does use GeometryReader in some cases (which doesn't seem to be part of this stack trace). The SwiftUI view is shown as part of an MKAnnotationView's detailCalloutAccessoryView. I use a wrapper UIView in which there is a UIHostingController, which is what contains the SwiftUI view. Would love any help or insight into this issue. Unfortunately I can't reproduce it on my end currently, so would be very helpful to get more details from the stack trace if possible.

I have an existing iOS app with shortcuts support, and I am trying to bring the same shortcuts to my Mac app in macOS Monterey. In my case, I have added the same intents definition file to my Mac target app, added "Intents eligible for in-app handling" to my Info.plust file and added the intent names, and made sure all the intent handling code is part of both iOS and Mac targets. Still, when I build and run the app on macOS Monterey, the new shortcuts don't show in the shortcut editor at all. I've tried closing and restarting the Shortcuts app, but no luck. The build logs do show the intents being built, but they're just not showing up in the Shortcuts app. I tried 'donating' one of the intents in my Mac app code, but got an error: Cannot donate interaction with intent that has no valid shortcut types Not sure what to try to make it work. Thanks.

Hi, I am getting a linking error when building my app to run against an iOS17 device, using Xcode15. Same project builds and runs fine with Xcode 14 and iOS16. The linking error just says: clang: error: unable to execute command: Segmentation fault: 11 clang: error: linker command failed due to signal (use -v to see invocation) Not sure what I should try to overcome this. I can't run my app on an iOS17 device. It builds, links and runs just fine on a simulator.

I have a UITableView which contains a UICollectionView in the first row. It used to work fine in iOS17, but now I get a crash when running with Xcode 16 / iOS18 beta: Expected dequeued view to be returned to the collection view in preparation for display. When the collection view's data source is asked to provide a view for a given index path, ensure that a single view is dequeued and returned to the collection view. Avoid dequeuing views without a request from the collection view. For retrieving an existing view in the collection view, use -[UICollectionView cellForItemAtIndexPath:] or -[UICollectionView supplementaryViewForElementKind:atIndexPath:] This is my UITableView delegate call: AddEditDataCell *cell = nil; if (indexPath.section == 0) { if (indexPath.row == 0) { AddEditDataContactsCell *contactNameCell = (AddEditDataContactsCell *)[self cellForContactNamesCollectionAtIndexPath:indexPath tableView:tableView]; return contactNameCell; - (AddEditDataContactsCell *)cellForContactNamesCollectionAtIndexPath:(NSIndexPath *)indexPath tableView:(UITableView *)tableView { AddEditDataContactsCell *contactsCell = (AddEditDataContactsCell *)[self.tableView dequeueReusableCellWithIdentifier:@"ContactsCell" forIndexPath:indexPath]; if (self.collectionNameCell == nil) { self.collectionNameCell = [contactsCell.collectionView dequeueReusableCellWithReuseIdentifier:@"LogContactNameCollectionCellIdentifier" forIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]]; contactsCell.nameCellDelegate = self; } contactsCell.frame = CGRectZero; [contactsCell setNeedsLayout]; [contactsCell.collectionView reloadData]; contactsCell.collectionViewHeightConstraint.constant = contactsCell.collectionView.collectionViewLayout.collectionViewContentSize.height; [contactsCell.collectionView.collectionViewLayout invalidateLayout]; return contactsCell; }

Hi, I am trying out the new UITabBar stuff in iOS18, and I don't think it'll be a good fit for my app. Is there a way to revert to the old iPad UITabBar look and placement that we've been using before? I don't want to make such a big change like this just yet, but I would need to make other changes to the app as well and I don't want to use the new UITabBar just yet. Is there a way to achieve this?

Hi, I need to keep supporting iOS16 for my widgets. I'm having a problem using the iOS17 'containerBackground' API. Ideally I would use a view extension: extension View { func adoptableWidgetBackground(_ color: Color) -> some View { if #available(iOS 17.0, *) { containerBackground(for: .widget) { color } } else { background(color) } } } But this gives an error: Branches have mismatching types 'some View' (result of 'Self.containerBackground(for:alignment:content:)') and 'some View' (result of 'Self.background(_:alignment:)') If I try to use this directly on the 'body' view modifier like this: if #available(iOS 17.0, *) { .containerBackground(for: .widget) { ContainerRelativeShape().fill(Color.init(UIColor.quaternarySystemFill)) } } else { .background(ContainerRelativeShape().fill(Color.init(UIColor.quaternarySystemFill))) } This doesn't work either. Instance member 'containerBackground' cannot be used on type 'View' How do I use this correctly?