Posts

Post not yet marked as solved
0 Replies
759 Views
Hi I tried adding the new .backgroundTask modifier to my project but it still requires calling func register(forTaskWithIdentifier identifier: String, using queue: DispatchQueue?, launchHandler: @escaping (BGTask) -> Void) -> Bool without it I get the error No launch handler registered for task with identifier... but providing a launchHandler doesn't make any sense as it's handled in the .backgroundTask closure. Am I missing something here? also can it be used for BGProcessingTasks as well, the WWDC session didn't mention that Radar/Feedback Number: FB10249217
Posted Last updated
.
Post not yet marked as solved
1 Replies
1.1k Views
My app uses the new API for in-app purchase rather than the original API as listed here: https://developer.apple.com/documentation/storekit/choosing_a_storekit_api_for_in-app_purchase But in App Store connect I'm getting this error/warning: These in-app purchases can’t be promoted on the App Store because your latest approved binary doesn’t include the SKPaymentTransactionObserver method. SKPaymentTransactionObserver is a part of the old API and I believe I shouldn't need to implement it anymore. Anyone know what I should do here?
Posted Last updated
.
Post not yet marked as solved
1 Replies
1.3k Views
In Xcode 12 the core data setup looks something along these lines https://developer.apple.com/forums/thread/650173, passing the context to the environment and then using the @FetchRequest property wrapper in your views, my questions about this are: What's the best approach if you need to use a dynamic predicate with your @FetchRequest, should I use @FetchRequest at all? What's the best approach if you use core data in a view model? Should the core data stack just be a shared instance that can be called from anywhere, including the view model (guessing probably not)? Should I try to pass the context taking it from the environment in the view and passing it to the model somehow? Should I have one model with the context that is added to the environment from the App Struct and not pass the view context on it's own (Probably not a great idea as it would need to handle everything in one file)? I'd love to see some sample code around this of some best practices or some advice about the approach? Also loving the new WWDC format this year and everything that has been released 😀
Posted Last updated
.