Keep in mind that the user can change the text size category (in the Settings app) while using your app. So your code should be listening for that change and updating the constraints as needed.

A standard UITableViewCell with a style of .value1 should give the desired results. If you want your own custom cell class with your own labels, you will need to apply one of two different sets of constraints depending on the current size category. Update the constraints any time the size category changes.

Thanks Quinn. Good information.

You do not need to plug your iPhone in to use it with Xcode. Debugging will likely be slower, but Xcode can communicate with your iOS device wirelessly.

@DTS Engineer I really appreciate the response. Very helpful. After looking into SMAppService, it does seem like a launch agent is most appropriate. The biggest issue I have now is trying to figure out how to make this work. My app and its needs are very far from simple. I have a very large data model that is stored locally in a SQLite database and the user can optionally choose to sync their data via iCloud (CloudKit). Trying to figure out how refactor all of the existing code and logic that deals with CKSyncEngine syncing, reading and writing the SQLite database, and updating the in-memory data model into the launch agent, all in a way that can be coordinated with the main GUI app (when it might happen to be running), it going to be, shall I say, challenging. Oh, and doing this in such a way that doesn't change how the iOS version currently works using background tasks.

Are your issues specific to Xcode 26.2? All of my existing behaviors works just fine with Xcode 26.0 and 26.1.1. I also had no trouble creating new custom behaviors and changing their names. I also had no issue deleting those custom behaviors. Though one note about editing a custom behavior's name. After entering the new name, you need to press the return key before clicking the Done button or the new name won't take. Perhaps that is the issue you are seeing. But I have not tested with Xcode 26.2.

@Etresoft The goal is to use older Asset Catalog based app icons for pre-26, and new Icon Composer based app icons for 26+. With Xcode 26.0, you could make it work using the --enable-icon-stack-fallback-generation=disabled setting. But as of Xcode 26.1, that setting is now being ignored and when the app is run, the Icon Composer based app icon is used for all versions, pre and post 26. While this thread is about macOS, it equally applies to iOS apps. I'm sticking with Xcode 26.0 because I want my old app icons for iOS 18 and older. Xcode 26.1 is now preventing this from being possible.

@KayleeSC I've been having the same issue for over a year, at least. Just today I got a reply to one of my bug reports. This time, instead of just clicking on the "Add More Information" button at the end of the report, I clicked on the "Reply to Apple Feedback" link at the bottom of the reply from Apple. After submitting the requested information, in this case confirming that the issue is now resolved, the report still had the purple dot next to it. But as soon as I closed the report (which was appropriate in this case), the purple dot disappeared and the feedback moved from the "Requests" folder back to my "Submitted" folder. So yes, this is a bug in Feedback Assistant. You really should file a bug report on this.

I've paid $99/year every year since 2008. Given inflation, the developer program is cheaper every year (so far any way).

You just have to use Xcode to put an updated version of the app on your iOS device once in a while. That's normal. Even as a paid app developer, development builds have a limited time before they expire. Just connect the device and run the app through Xcode again. The only way you can create an app that runs forever on an iOS device is to install the app through the App Store. But that requires you to be a paid developer and your app needs to be something usable by many people and reviewed and approved by Apple. Even apps loaded via Test Flight only last 90 days.

It's definitely iOS/iPadOS 26 bugs that have been there since 26.0 beta 1. It's really annoying. It makes it really difficult to know if it's your own code or not when the console fills up with constant errors coming from the OS and not your own code. The whole new look in iOS 26 is nice, but the constant bugs and junk like these extraneous error messages are making it harder and harder to enjoy working with Apple's tools and platforms.

I hadn't noticed this issue before but I just tested with my app running on an iPad with iPadOS 26.2 beta 1 and this problem still exists. It's fine with iPadOS 26.0. So it's a regression in iPadOS 26.1 that still exists in 26.2. What's strange about this issue is that it only seems to be the userInterfaceStyle (light/dark). My app has a custom trait that can be applied to the scene's main window. And I can change that trait while a popover is in view. If the custom trait is changed it happily propagates to all view controllers, including the popover.

There are various reports of this issue scattered about. Any time I start to hear the crackle I run the following command from a terminal window: sudo pkill coreaudiod That fixes the issue for a while. If you run that while playing music or other audio, the sound will stop for a couple of seconds as the process restarts and then the audio will come back without the crackle.

I found a work around for this issue. I'm annoyed I didn't think of this months ago. Instead of setting up the scope bar titles at the start, wait until the search controller is about to be activated the first time. In the code in my original post, remove these lines from setupSearch: let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] and add the line: search.delegate = self Then add the following extension to the view controller class: extension ViewController: UISearchControllerDelegate { func willPresentSearchController(_ searchController: UISearchController) { if searchController.searchBar.scopeButtonTitles == nil { searchController.searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] } } } This change works under iOS/iPadOS 26.0 and later. Now the scope buttons do not interfere with whatever content is immediately below the search bar.

All of these are still an issue with iPadOS 26.2 beta 1.