UITextView crash when setting attributed text that contains substring ffi and attributedText contains NSFontAttributeName, NSForegroundColorAttributeName
Reproducible case:
UITextView *textView = [[UITextView alloc] init];
textView.attributedText = [[NSAttributedString alloc] initWithString:@"ffi" attributes:@{
NSParagraphStyleAttributeName: [self createParagraphOfLineHeight:20],
NSFontAttributeName: [UIFont systemFontOfSize:fontSize weight:UIFontWeightRegular],
NSForegroundColorAttributeName: UIColor.black
}];
Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
After two types of objects correctly inserted as nodes in an augmented reality setting, I replicated exactly the same procedure with a third kind of objects that unfortunately refuse to show up. I checked the flow and it is the same as the other objects as well the content of the LocationAnnotation, but there is surely something that escapes me. Could someone help with some ideas?
This is the common code, apart of the class:
func appendInAR(ghostElement: Ghost){
let ghostElementAnnotationLocation=GhostLocationAnnotationNode(ghost: ghostElement)
ghostElementAnnotationLocation.scaleRelativeToDistance = true
sceneLocationView.addLocationNodeWithConfirmedLocation(locationNode: ghostElementAnnotationLocation)
shownGhostsAnnotations.append(ghostElementAnnotationLocation)
}
The following code only ever causes shouldDrawInsertionPoint to be printed (no drawInsertionPoint), but even if that method returns false, the blinking insertion point is still drawn. On the other hand, with TextKit 1 it works as expected.
Is there a way to hide the default insertion point in TextKit 2? My app draws its own.
I've filed FB13684251.
class TextView: NSTextView {
override var shouldDrawInsertionPoint: Bool {
print("shouldDrawInsertionPoint")
return false
}
override func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool) {
print("drawInsertionPoint", flag)
}
}
``
Following on from this thread: https://developer.apple.com/forums/thread/805037 my list of items is now correctly maintaining state (no more disappearing rows), but I'm now hitting a really annoying issue: Every time something changes - even just changing the dark mode of the device - the entire list of items is refreshed, and the list jumps back to the top.
A simple representation:
// modelData.filteredItems is either all items or some items, depending on whether the user is searching
List {
ForEach(modelData.filteredItems) { item in
ItemRow(item: item)
}
}
When the user isn't searching, filteredItems has everything in it. When they turn on search, I filter and sort the data in place:
// Called when the user turns on search, or when the searchString or searchType changes
func sortAndFilterItemsInModelData() {
modelData.filteredItems.removeAll() // Remove all items from the filtered array
modelData.filteredItems.append(contentsOf: modelData.allItems) // Add all items back in
let searchString: String = modelData.searchString.lowercased()
switch(modelData.searchType) {
case 1:
// Remove all items from the filtered array that don't match the search string
modelData.filteredItems.removeAll(where: { !$0.name.lowercased().contains(searchString) })
...
}
// Sorting
switch(modelData.sortKey) {
case sortKeyDate:
modelData.sortAscending ? modelData.filteredItems.sort { $0.date < $1.date } : modelData.filteredItems.sort { $0.date > $1.date } // Sorts in place
...
}
}
The method doesn't return anything because all the actions are done in place on the data, and the view should display the contents of modelData.filteredItems.
If you're searching and there are, say 10 items in the list and you're at the bottom of the list, then you change the search so there are now 11 items, it jumps back to the top rather than just adding the extra ItemRow to the bottom. Yes, the data is different, but it hasn't been replaced; it has been altered in place.
The biggest issue here is that you can simply change the device to/from Dark Mode - which can happen automatically at a certain time of day - and you're thrown back to the top of the list. The array of data hasn't changed, but SwiftUI treats it as though it has.
There's also a section in the List that can be expanded and contracted. It shows or hides items of a certain type. When I expand it, I expect the list to stay in the same place and just show the extra rows, but again, it jumps to the top. It's a really poor user experience.
Am I doing something wrong (probably, yes), or is there some other way to retain the scroll position in a List? The internet suggests switching to a LazyVStack, but I lose left/right swipe buttons and the platform-specific styling.
Thanks.
I'm running into a persistent problem with the iOS 18.5 simulator in Xcode 26 beta 2. I have built a very simple test app with a storyboard that includes only a toolbar added to the ViewController scene in the storyboard. The test app runs fine in iOS 26 simulators.When I try to run it in the iOS 18.5 simulator for iPhone Pro or iPad (16), it fails while unarchiving the storyboard (as far as I can tell) with this error message in the Xcode console:
*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)'
terminating due to uncaught exception of type NSException
CoreSimulator 1043 - Device: iPad (A16) (3E70E25F-8434-4541-960D-1B58EB4037F3) - Runtime: iOS 18.5 (22F77) - DeviceType: iPad (A16)
I'd love a simple workaround for this.
I have noticed that in iOS 14 the UIPickerView has by default a light grey background on the selected Row like shown here.
https://developer.apple.com/design/human-interface-guidelines/ios/controls/pickers/
I noticed also that pickerView.showsSelectionIndicator is deprecated on iOS 14.
Is there a way to change the background color to white and add separators to achieve a pre iOS 14 UIPickerView style?
Thank you
We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive.
We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18.
Here's our Objective-C code which presents the picker:
NSArray* contentTypeArray = @[UTTypeAppleArchive];
UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES];
docPickerVC.delegate = self;
docPickerVC.allowsMultipleSelection = NO;
docPickerVC.shouldShowFileExtensions = YES;
docPickerVC.modalPresentationStyle = UIModalPresentationPopover;
docPickerVC.popoverPresentationController.sourceView = self.view;
[self presentViewController:docPickerVC animated:YES completion:nil];
The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file.
When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data.
Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details).
Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?
In beta 2 using layer.cornerRadius on a UIEffectView with the UIGlassEffect allowed you to change the corner radius of the view. In beta 3, this no longer works. WWDC videos indicate the right way to do this is to set the cornerConfiguration on the UIEffectView, but that API doesn't seem to be available yet. At this time it doesn't seem like theres a way to have a glass view that isn't pill shaped.
Ok… I'm baffled here… this is very strange.
Here is a SwiftUI app:
import SwiftUI
@main struct StepperDemoApp: App {
func onIncrement() {
print(#function)
}
func onDecrement() {
print(#function)
}
var body: some Scene {
WindowGroup {
Stepper {
Text("Stepper")
} onIncrement: {
self.onIncrement()
} onDecrement: {
self.onDecrement()
}
}
}
}
When I run in the app in macOS (Xcode 16.0 (16A242) and macOS 14.6.1 (23G93)), I see some weird behavior from these buttons. My experiment is tapping + + + - - -. Here is what I see printed:
onIncrement()
onIncrement()
onIncrement()
onIncrement()
onDecrement()
What I expected was:
onIncrement()
onIncrement()
onIncrement()
onDecrement()
onDecrement()
onDecrement()
Why is an extra onIncrement being called? And why is one onDecrement dropping on the floor?
Deploying the app to iPhone Simulator does not repro this behavior (I see the six "correct" logs from iPhone Simulator).
Is the Cancel button intentionally removed from UISearchBar (right side)?
Even when using searchController with navigationItem also.
showsCancelButton = true
doesn’t display the cancel button.
Also:
When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search).
If the search text is empty and I tap outside the search bar, the search is canceled.
Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening.
In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled.
Are these behaviors intentional changes, beta issues, or are we missing something in implementation?
I have added a UICollectionViewCell to my storyboard, and I added a UILabel to my UICollectionViewCell in storyboard. I have created a cell registration using UICollectionView.CellRegistration and have implemented the cellProvider closure for the datasource which dequeue a collection view cell of type TapLabelCollectionViewCell(I have subclassed the cell in my storyboard to this class).
In my TapLabelCollectionViewCell, I am trying to set the tap gesture recogniser on the label, but the label appears nil, which I've connected using an @IBOutlet. Why is this and how can I fix it?
My code :
// UI View Controller:
class TapGridViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
tapGridCollectionView.collectionViewLayout = createLayout()
configureDataSource()
applySnapshot()
}
func configureDataSource() {
let cellRegistration = UICollectionView.CellRegistration<TapLabelCollectionViewCell, CellItem>(handler: {
(cell: TapLabelCollectionViewCell, indexPath: IndexPath, item: CellItem) in
cell.taplabel.text = String(item.labelCount)
})
dataSource = UICollectionViewDiffableDataSource(collectionView: tapGridCollectionView, cellProvider: { (collectionView: UICollectionView, indexPath: IndexPath, item: CellItem) in
let cell = collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: item)
cell.delegate = self
cell.index = indexPath.row
return cell
})
}
}
// UI Collection View Cell:
protocol TapLabelCollectionViewCellDelegate: AnyObject {
func incrementNumberOfTaps(index: Int)
}
class TapLabelCollectionViewCell: UICollectionViewCell {
@IBOutlet var taplabel: UILabel!
var delegate: TapLabelCollectionViewCellDelegate?
var index: Int!
static let identifier = "tapLabelCellIdentifier"
override init(frame: CGRect) {
super.init(frame: frame)
setUpTapGestureRecognizer()
}
required init?(coder: NSCoder) {
super.init(coder: coder)
}
func setUpTapGestureRecognizer() {
let tapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(incrementNumberOfTaps))
print("tap Label,", taplabel)
taplabel.addGestureRecognizer(tapGestureRecognizer)
}
@objc func incrementNumberOfTaps() {
delegate?.incrementNumberOfTaps(index: index)
}
}
Navigation Title no longer showing for first Tab in iOS/iPadOS 26 (Directives) in my app Starship SE Corps when running is Xcode 26 simulator and on iPad device itself running iPadOS 26 beta.
Launch app
Notice Navigation Title “Directives” is missing from top tab in Sidebar and Floating Tab View (iPad) and TabView (iOS).
Navigate to other tabs and Navigation Titles appear as expected.
Worked fine (as expected) in iOS/iPadOS 18.5, but broken in iOS/iPadOS 26.
Reference Feedback: FB17987650
Hi,
I’m seeing a crash when running my app on iOS 18 simulators or devices using Xcode 26 beta 3.
My app’s minimum deployment target is iOS 17, and the crash does not happen when running from Xcode 16.4.
The crash occurs specifically at this line:
return UIStoryboard(name: storyboard.rawValue, bundle: nil)
.instantiateViewController(withIdentifier: view.rawValue)
Crash Details:
** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ because no class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)'
*** First throw call stack:
(0x191c3321c 0x18f0cdabc 0x191c91ea0 0x19d740774 0x19d740a18 0x19d740cac 0x194626680 0x194dbc784 0x19d740890 0x19d740cac 0x1949aadd8 0x19d740890 0x19d740a18 0x19d740cac 0x194802e24 0x1945f008c 0x194ed1808 0x107a8bfa0 0x107a8c05c 0x1945ec128 0x19d740890 0x19d740cac 0x1945eba60 0x19d740890 0x19d740a18 0x19d740cac 0x1945f07dc 0x1945eaea4 0x19492ee80 0x10763de00 0x1076e56fc 0x1076e5674 0x1076e5e04 0x19496108c 0x194f9b9a0 0x1949072c4 0x194f998cc 0x194f9af04 0x19445139c 0x19445ac28 0x194467508 0x1079afaec 0x1079aff5c 0x1944189a0 0x194417be4 0x1944114e4 0x194411404 0x194410ab4 0x19440c1e4 0x191b28a8c 0x191b288a4 0x191b28700 0x191b29080 0x191b2ac3c 0x1ded09454 0x19453d274 0x194508a28 0x1073564f4 0x1b89fff08)
terminating due to uncaught exception of type NSException
The crash occurs immediately at app launch, when attempting to load a storyboard-based UITabBarController.
Works as expected on:
Xcode 16.4 + iOS 18 (simulator/device)
Xcode 26 beta 3 + iOS 26 (simulator/device)
Running from Xcode 26 beta 3 onto iOS 18 simulators or devices and it immediate crash from the particular storyboard
Setup:
Xcode: 26 beta 3
macOS: 15.5
iOS Simulators: iOS 18.5
Minimum deployment target: iOS 17
UIKit-based app (not using SwiftUI)
No custom toolbars or host views in use explicitly
Is this a known compatibility issue when building with the iOS 26 SDK and running on iOS 18?
Are there any workarounds or recommendations for running apps targeting iOS 17+ on iOS 18 simulators when using Xcode 26?
We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController.
Anyone else seeing this?
4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30
5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396
6 libobjc.A.dylib 0xac50 objc_storeWeak + 472
7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24
8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160
9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112
10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36
Hi all,
After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18.
Context:
I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers:
Horizontal drag for swipe-to-reply (and other actions: pin, delete)
Long press for showing popover/actions
Vertical scroll for normal chat scrolling
This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below).
Minimal Repro Sample
MessageListView.swift
swift
Copy
Edit
ScrollViewReader { proxy in
ScrollView(.vertical, showsIndicators: false) {
LazyVStack(spacing: 0) {
// ... grouped messages
ForEach(...) { ...
MessageBubble(...) // see below
}
Color.clear.frame(height: 8).id("BOTTOM_ANCHOR")
}
.padding(.horizontal, 4)
.rotationEffect(.degrees(180))
}
.rotationEffect(.degrees(180))
}
MessageBubble.swift
struct MessageBubble: View {
// ...
var body: some View {
// horizontal swipe-to-reply gesture
let dragGesture = DragGesture(minimumDistance: 10)
// ...
ZStack {
// ...
HStack { ... }
// ...
.simultaneousGesture(
DragGesture(minimumDistance: 0) // for long press
// ...
)
.simultaneousGesture(dragGesture) // for horizontal swipe
}
// ...
}
}
We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App).
TabView(selection: $viewModel.selectedTab) {
// Tabs here
}
.tabViewBottomAccessory {
if viewModel.showAudioMiniPlayer {
MiniPlayerView()
}
}
The Problem
This code works perfectly on iOS 26.0. When viewModel.showAudioMiniPlayer is false, the accessory is completely hidden.
However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' becomes false, the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar.
Is this a known Bug in iOS 26.1 and are there any effective workarounds?
Topic:
UI Frameworks
SubTopic:
SwiftUI
Running up Xcode 16.2 Beta 1, a lot of my code that used onPreferenceChange in Views to change @State properties of those views, such as some notion of a measured width is now complaining about mutating the @MainActor-isolated properties from Sendable closures.
Now I've got to hoop-jump to change @State properties from onPreferenceChange? OK, but seems a bit of extra churn.
My app has the following UI layout:
NSSplitViewController as the windows contentViewController
NSPageController in the content (right) split item
NSTabViewController as the root items of the NSPageController
NSViewController with a collection view in the first tab of that NSTabViewController
The collection view is using a NSCollectionViewCompositionalLayout in which the sections are set up to have a header using NSCollectionLayoutBoundarySupplementaryItem with pinToVisibleBounds=true and alignment=top
With macOS 26, the pinned supplementary item automatically gets a blurred/semi-transparent background that seamlessly integrates with the toolbar. When the window's title bar has a NSTitlebarAccessoryViewController added, the said semi-transparent background gets a bottom hard edge and a hairline to provide more visual separation from the main content.
During runtime, my NSPageController transitions from the NSTabViewController to another view controller. When transitioning back, the semi-transparent blur bleeds into the entire section. This happens no matter if there's a NSTitlebarAccessoryViewController added or not.
It doesn't happen 100% of the cases, it seems to depend on section size, header visibility and/or scroll position. But it happens more often than not.
Most of the time, a second or so after the back transition - shortly after pageControllerDidEndLiveTransition: of the NSPageControllerDelegate is called - the view updates and the supplementary views are back to normal.
Sometimes, the issue also appears not when transitioning using NSPageController, but simply by scrolling through the collection view.
Anyone has an idea what is happening here? Below are two screenshots of both the "ok" and "not ok" state
I'm on macOS 26.0.1 and I'm using XCode 26.0.1
I’m relatively new to SwiftUI, so I’ve got a pretty basic question here. In my watchOS app, I’m using ShareLink to share a string of text to the Mail and Messages apps. Mail shows up in the ShareLink sheet just fine, but Messages doesn’t appear.
What’s odd is that when I run the app in Xcode’s preview or in the Simulator, Messages does show up as a sharing option… So now I’m wondering if this is just a quirk with my device or if Apple doesn’t actually support sharing text to Messages from third-party watchOS apps yet? I know some Apple Watch apps (like Contacts) do support sending text/files to Messages, so I’m curious if anyone’s had a similar experience or knows more about this.
Any insights would be super helpful!
In one of my apps, i am using .glassEffect(_:In) to add glass effect on various elements. The app always crushes when a UI element with glassEffect(_in:) modifier is being rendered. This only happens on device running iOS 26 public beta. I know this for certain because I connected the particular device to xcode and run the app on the device. When i comment out the glassEffect modifier, app doesn't crush.
Is it possible to check particular realeases with #available? If not, how should something like this be handled. Also how do i handle such os level erros without the app crushing. Thanks.