Post

Replies

Boosts

Views

Activity

Reply to Why @Bindable and not @Binding in SwiftUI for iOS 17
I didn't find a difference between defining an @Observable class object with and without @State property wrapper. In the video, in order to fully adopt the new Observation framework, they emphasize to use only 3 property wrappers (although we can still use other wrappers as they are not deprecated at least today): @State, @Bindable and @Environment, so we can live (somehow) without @Binding, and YES, @State can be used with value and reference types although the docs say: Use state as the single source of truth for a given value type that you store in a view hierarchy, which's misleading. Now if I want to live without @Binding and to create bindings to my struct data model's properties, I have to convert my struct data model to @Observable class, I don't know if this is the best available approach to fully adopt Observation
Feb ’24
Reply to How should I access @AppStorage and @SceneStorage values outside of views?
I'm facing the same issue with a custom property wrapper I created to manage in-app settings (like user's preferred color scheme regardless the system's scheme), the struct im having is this: import SwiftUI class SettingKeys: ObservableObject { @AppStorage("colorScheme") var colorScheme: AppColorScheme? } @propertyWrapper struct AppSetting<T>: DynamicProperty { @StateObject private var keys = SettingKeys() private let key: ReferenceWritableKeyPath<SettingKeys, T> var wrappedValue: T { get { keys[keyPath: key] } nonmutating set { keys[keyPath: key] = newValue } } var projectedValue: Binding<T> { .init ( get: { wrappedValue }, set: { wrappedValue = $0 } ) } init(_ key: ReferenceWritableKeyPath<SettingKeys, T>) { self.key = key } } enum AppColorScheme: String { case light case dark var value: ColorScheme { switch self { case .light: return .light case .dark: return .dark } } } When I try to access any settings value from outside a View (like in an extension or helper function) like this: func someFunc() { @AppSetting(\.colorScheme) var colorScheme //do something with colorScheme var } i get this runtime error at the getter line: keys[keyPath: key]: Accessing StateObject's object without being installed on a View. This will create a new instance each time. I understand what does this mean, but my use-case requires to access this setting outside of a view, and at the same time I need to use this setting as a wrapper to manager reading and writing its value in a SwiftUI view, something like this: @AppSetting(\.colorScheme) private var colorScheme if anybody comes with a best practice it would be appreciated.
Nov ’23
Reply to New iOS String Initializer can't get correct localized String for specific locale
Did you find a solution for how to force return a string localized for a specific language regardless to the system language when you use String Catalog ? check out my question here: https://stackoverflow.com/questions/77544177/xcode-15s-string-catalog-always-return-system-language-translations?noredirect=1#comment136706101_77544177 somebody in this thread is asking for the case in which we need to ignore system language and localize strings for a specific language, we offer the user to choose a language from a list of languages in the app's settings page while their own iPhone's system language is English.
Nov ’23
Reply to xcodebuild[56491:10396296] [MT] DVTAssertions: Warning in Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
I am getting tens of entries for this same warning in the build logs of a Microsoft Azure Pipeline run, for a native SwiftUI XCode 15.0 project, running on Mac OS Sonoma on Mac Book Pro M1 Max machine, this machine is set as the self hosted agent to run the pipeline locally, the weird thing is that xcodebuild command succeeds when I run it in Terminal for the same project on the same machine but fails when it runs through Microsoft Azure's Pipeline. Here's one entry for the warning i'm getting: xcodebuild[26662:5421727] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22267/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103 Details: createItemModels creation requirements should not create capability item model for a capability item model that already exists. Function: createItemModels(for:itemModelSource:) Thread: <_NSMainThread: 0x6000039383c0>{number = 1, name = main} Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide. Any solutions for this issue will be highly appreciated.
Nov ’23