Post

Replies

Boosts

Views

Activity

`Text` (Label) text color issue during app resuming from suspended (changes from black to light or vice versa, depending on current appearance mode).
Its important to note that this same app did not have this issue in iOS 17. Ever since iOS 18 I have noticed that when application written in SwiftUI uses Label with the default color (which auto changes between light and dark appearance), from time to time when resuming an application that has been in the background, the color of those labels (only the Label elements) switches from the opposite to the correct one. Here is an example: Steps to reproduce Phone is in dark appearance Open app Labels text color is white and labels background is black Go to home so that app is on background Wait random time (does not happen all the time), some times 1 min some times 10 Reopen the application. During the opening transition the Label text color was changed while the app was in suspended mode to the light appearance variant (black) Once the app opening transition finishes the Label text color switches back to the correct color for dark appearance (white) Same issue happens if you start from light appearance. I cannot reproduce this on Xcode simulators, I have tried to force memory warning to check if that has anything to do with it but that also does not cause the issue to appear on simulators. For now I can only reproduce this on real device. Screenshots Here is screenshots of the above example: During transition After transition
Topic: UI Frameworks SubTopic: SwiftUI
4
0
389
Feb ’25
Incorrect results from `isSuperset` when used with specific emoji symbols and prefix.
Hi, It seams that the public func isSuperset(of other: CharacterSet) -> Bool API gives inconsistent results for some emoji symbols when uses with and without prefix text. Here is a playground example: import Foundation let input1 = "🥀" let input11 = "a🥀" let input2 = "😀" let input22 = "a😀" let letters = CharacterSet.letters print("'\(input1)' is part of 'CharacterSet.letters': \(letters.isSuperset(of: CharacterSet(charactersIn: input1)))") // Gives false print("'\(input11)' is part of 'CharacterSet.letters': \(letters.isSuperset(of: CharacterSet(charactersIn: input11)))") // INCORRECT: Should give false, but it gives true print("'\(input2)' is part of 'CharacterSet.letters': \(letters.isSuperset(of: CharacterSet(charactersIn: input2)))") // Gives false print("'\(input22)' is part of 'CharacterSet.letters': \(letters.isSuperset(of: CharacterSet(charactersIn: input22)))") // Gives false Output: '🥀' is part of 'CharacterSet.letters': false 'a🥀' is part of 'CharacterSet.letters': true '😀' is part of 'CharacterSet.letters': false 'a😀' is part of 'CharacterSet.letters': false Has anyone observed this?
5
0
764
Jan ’24
In SwiftUI in iOS 18.1, `SectionedFetchRequest` is not refreshed when changes are done to the fetched entity's attributes.
Hi, This issue started with iOS 18, in iOS 17 it worked correctly. I think there was a change in SectionedFetchRequest so maybe I missed it but it did work in iOS 17. I have a List that uses SectionedFetchRequest to show entries from CoreData. The setup is like this: struct ManageBooksView: View { @SectionedFetchRequest<Int16, MyBooks>( sectionIdentifier: \.groupType, sortDescriptors: [SortDescriptor(\.groupType), SortDescriptor(\.name)] ) private var books: SectionedFetchResults<Int16, MyBooks> var body: some View { NavigationStack { List { ForEach(books) { section in Section(header: Text(section.id)) { ForEach(section) { book in NavigationLink { EditView(book: book) } label: { Text(book.name) } } } } } .listStyle(.insetGrouped) } } } struct EditView: View { private var book: MyBooks init(book: MyBooks) { print("Init hit") self.book = book } } Test 1: So now when I change name of the Book entity inside the EditView and do save on the view context and go back, the custom EditView is correctly hit again. Test 2: If I do the same changes on a different attribute of the Book entity the custom init of EditView is not hit and it is stuck with the initial result from SectionedFetchResults. I also noticed that if I remove SortDescriptor(\.name) from the sortDescriptors and do Test 1, it not longer works even for name, so it looks like the only "observed" change is on the attributes inside sortDescriptors. Any suggestions will be helpful, thank you.
6
0
1.4k
Jan ’25
Xcode 15: Core Data : No NSValueTransformer with class name XXX was found for attribute YYY on entity ZZZ for custom `NSSecureUnarchiveFromDataTransformer`
Hi, I am creating a custom NSSecureUnarchiveFromDataTransformer in order to handle attributes of entities of type NSDateComponents. It all works and I did not see any warnings in the "Issue navigator" inside Xcode but with Xcode 15 I started seeing this warning: /Users/.../CustomNSSecureUnarchiveFromDataTransformer/CoreData:1:1 no NSValueTransformer with class name 'CustomSecureUnarchiveFromDataTransformer' was found for attribute 'testDate' on entity 'Item' My use case is very simple, I have this custom transformer: @objc(CustomSecureUnarchiveFromDataTransformer) final class CustomSecureUnarchiveFromDataTransformer: NSSecureUnarchiveFromDataTransformer { override class var allowedTopLevelClasses: [AnyClass] { return [NSDateComponents.self] } static let name = NSValueTransformerName(rawValue: String(describing: CustomSecureUnarchiveFromDataTransformer.self)) public static func register() { let transformer = CustomSecureUnarchiveFromDataTransformer() ValueTransformer.setValueTransformer(transformer, forName: name) } } which is set to the Core data entity's "Transformer": which leads to the warning in Xcode 15. App works just fine and there are no problems during run time, but this warning is shown and I want to fix it. Here is a simple test project https://github.com/VladimirAmiorkov/CustomNSSecureUnarchiveFromDataTransformer
13
11
4.0k
Oct ’24