Post

Replies

Boosts

Views

Activity

Differentiate whether NSPersistentStoreRemoteChange notification is coming from Cloud or a local change
How can we identify whether the remote change notification is triggered because some data was changed on a different device and it is downloaded from CloudKit, or it is triggered from the current device because new entity was saved into database. Because this notification is posted when both remote data is downloaded or local data is created. It would be great if there is a way to understand the origin of the notification.
0
0
702
May ’24
View Navigation Title Disappears on watchOS Target When Built With Xcode 26+
I have a SwiftUI view in a watch companion app, and when I build my app with Xcode 26.2 or 26.3, the navigation title on a presented screen disappears after the watch screen goes dark. So, the navigation title is only visible when the screen is first presented and not again after the watch screen goes dark, for example when the user lowers their arm. Please see the screenshots for a better understanding. Notice that the "Bench Press" text is not visible in the third image. Also, I’ve confirmed that this does not happen when the app is built with Xcode 16.4. First Image (initial presentation of the screen): Second Image (watch screen goes dark): Third Image (watch screen goes back on, title missing): Although I've confirmed that this is related to Xcode versioning, and it happens on multiple screens, here is the redacted version of this SwiftUI view that is shown in the screenshots, in case it helps: var body: some View { NavigationStack(path: $viewModel.pushedViews) { TabView(selection: $selectedTab) { ... ZStack { List { ForEach(Array(viewModel.setModels.enumerated()), id: \.element) { index, setModel in VStack(spacing: 8.0) { SetContentView() } } ... } .listStyle(.plain) .buttonStyle(.plain) VStack { WatchRestTimerView(viewModel: viewModel.restTimerViewModel) Spacer() } } .tag(WatchExerciseLoggingTab.logExercise) // HERE IS THE TITLE SET .navigationTitle(viewModel.name) NowPlayingView().tag(WatchExerciseLoggingTab.nowPlaying) } .tabViewStyle(PageTabViewStyle()) .navigationDestination(for: WatchWeightAndSetExerciseSummaryPushedView.self, destination: { _ in RedactedView() }) } } This prevents me from migrating to Xcode 26, I would also appreciate if anyone has a work around until there is a fix for this, I mean I can stop using navigation title and add a Text at the top but it is not quite the same UI experience we get from the navigation title in a watch app.
0
0
48
3w
Transaction.currentEntitlements is not consistent
I've recently published an app, and while developing it, I could always get consistent entitlements from Transaction.currentEntitlements. But now I see some inconsistent behaviour for a subscribed device in the AppStore version. It looks like sometimes the entitlements do not emit value for the subscriptions. It usually happens on the first couple tries when the device goes offline, or on the first couple tries when the device goes online. But it also happens randomly at other times as well. Can there be a problem with Transaction.currentEntitlements when the connectivity was just changed? Of course my implementation may also be broken. I will give you the details of my implementation below. I have a SubscriptionManager that is observable (irrelevant parts of the entity is omitted): final class SubscriptionManager: NSObject, ObservableObject { private let productIds = ["yearly", "monthly"] private(set) var purchasedProductIDs = Set<String>() var hasUnlockedPro: Bool { return !self.purchasedProductIDs.isEmpty } @MainActor func updatePurchasedProducts() async { var purchasedProductIDs = Set<String>() for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.revocationDate == nil { purchasedProductIDs.insert(transaction.productID) } else { purchasedProductIDs.remove(transaction.productID) } } // only update if changed to avoid unnecessary published triggers if purchasedProductIDs != self.purchasedProductIDs { self.purchasedProductIDs = purchasedProductIDs } } } And I call the updatePurchasedProducts() when the app first launches in AppDelegate, before returning true on didFinishLaunchingWithOptions as: Task(priority: .high) { await DependencyContainer.shared.subscriptionManager.updatePurchasedProducts() } You may be wondering maybe the request is not finished yet and I fail to refresh my UI, but it is not the case. Because later on, every time I do something related to a subscribed content, I check the hasUnlockedPro computed property of the subscription manager, which still returns false, meaning the purchasedProductIDs is empty. You may also be curious about the dependency container approach, but I ensured by testing multiple times that there is only one instance of the SubscriptionManager at all times in the app. Which makes me think maybe there is something wrong with Transaction.currentEntitlements I would appreciate any help regarding this problem, or would like to know if anyone else experienced similar problems.
6
7
3k
May ’25
ToolbarItemGroup With Palette Style Cannot Present a View Controller While the Context Menu Is Visible
When I set up a toolbar item group with multiple options and set the controlGroupStyle as .palette, and when one of the options are supposed to present a view controller, I get the following error Attempt to present <UINavigationController: 0x101813200> on <ProjectName.HomeTabBarViewController: 0x10701bc00> (from <UINavigationController: 0x107821000>) which is already presenting <_UIContextMenuActionsOnlyViewController: 0x1035c19d0>. So basically the context menu we see is under the hood a view controller that is being presented. Is there a right way of fixing it, or is it maybe something that will be fixed by Apple? This is how I set up the ToolbarItemGroup on SwiftUI and the view model ultimately presents another UINavigationController that has a UIHostingController as its view controller: .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Button("ft_commons_edit".localised, systemImage: "pencil") { viewModel.didTapEditAction() } Button("ft_commons_delete".localised, systemImage: "trash") { viewModel.didTapDeleteAction() } } label: { Image("edit-icon") .resizable() .frame(width: 24.0, height: 24.0) } } .controlGroupStyle(.palette) This is how the view looks like when presentation fails: As a workaround, I found two options that work well. I’d like to share them and ask for recommendations, just to make sure they won’t cause any unexpected issues later on: Option 1: Access the top most visible view controller and attempt presenting on it This requires the following extension: extension UIViewController { func topMostViewController() -> UIViewController { if let presentedViewController = self.presentedViewController { return presentedViewController.topMostViewController() } else if let navigationController = self as? UINavigationController, let topViewController = navigationController.topViewController { return topViewController.topMostViewController() } else if let tabBarController = self as? UITabBarController, let selectedViewController = tabBarController.selectedViewController { return selectedViewController.topMostViewController() } else { return self } } } Then called as: navigationController.topMostViewController().present(exerciseEditingNavController, animated: true) Option 2: Call dismiss before attempting to present anything This also works fine, even without any delay, the menu is first dismissed and presentation works fine afterwards, code example: navigationController.dismiss(animated: true) navigationController.present(exerciseEditingNavController, animated: true) I feel like Option 1 would be the better choice, because if this context menu is ever no longer treated as a view controller and direct presentation starts working, Option 1 would still behave correctly by presenting from the topmost visible view controller. Option 2, on the other hand, could introduce a bug by dismissing an unrelated view controller if the context menu is no longer represented as a view controller at that point. I would appreciate any advice from anyone who has experienced this, or from Apple developers. Thanks
6
0
305
4d
Differentiate whether NSPersistentStoreRemoteChange notification is coming from Cloud or a local change
How can we identify whether the remote change notification is triggered because some data was changed on a different device and it is downloaded from CloudKit, or it is triggered from the current device because new entity was saved into database. Because this notification is posted when both remote data is downloaded or local data is created. It would be great if there is a way to understand the origin of the notification.
Replies
0
Boosts
0
Views
702
Activity
May ’24
View Navigation Title Disappears on watchOS Target When Built With Xcode 26+
I have a SwiftUI view in a watch companion app, and when I build my app with Xcode 26.2 or 26.3, the navigation title on a presented screen disappears after the watch screen goes dark. So, the navigation title is only visible when the screen is first presented and not again after the watch screen goes dark, for example when the user lowers their arm. Please see the screenshots for a better understanding. Notice that the "Bench Press" text is not visible in the third image. Also, I’ve confirmed that this does not happen when the app is built with Xcode 16.4. First Image (initial presentation of the screen): Second Image (watch screen goes dark): Third Image (watch screen goes back on, title missing): Although I've confirmed that this is related to Xcode versioning, and it happens on multiple screens, here is the redacted version of this SwiftUI view that is shown in the screenshots, in case it helps: var body: some View { NavigationStack(path: $viewModel.pushedViews) { TabView(selection: $selectedTab) { ... ZStack { List { ForEach(Array(viewModel.setModels.enumerated()), id: \.element) { index, setModel in VStack(spacing: 8.0) { SetContentView() } } ... } .listStyle(.plain) .buttonStyle(.plain) VStack { WatchRestTimerView(viewModel: viewModel.restTimerViewModel) Spacer() } } .tag(WatchExerciseLoggingTab.logExercise) // HERE IS THE TITLE SET .navigationTitle(viewModel.name) NowPlayingView().tag(WatchExerciseLoggingTab.nowPlaying) } .tabViewStyle(PageTabViewStyle()) .navigationDestination(for: WatchWeightAndSetExerciseSummaryPushedView.self, destination: { _ in RedactedView() }) } } This prevents me from migrating to Xcode 26, I would also appreciate if anyone has a work around until there is a fix for this, I mean I can stop using navigation title and add a Text at the top but it is not quite the same UI experience we get from the navigation title in a watch app.
Replies
0
Boosts
0
Views
48
Activity
3w
Transaction.currentEntitlements is not consistent
I've recently published an app, and while developing it, I could always get consistent entitlements from Transaction.currentEntitlements. But now I see some inconsistent behaviour for a subscribed device in the AppStore version. It looks like sometimes the entitlements do not emit value for the subscriptions. It usually happens on the first couple tries when the device goes offline, or on the first couple tries when the device goes online. But it also happens randomly at other times as well. Can there be a problem with Transaction.currentEntitlements when the connectivity was just changed? Of course my implementation may also be broken. I will give you the details of my implementation below. I have a SubscriptionManager that is observable (irrelevant parts of the entity is omitted): final class SubscriptionManager: NSObject, ObservableObject { private let productIds = ["yearly", "monthly"] private(set) var purchasedProductIDs = Set<String>() var hasUnlockedPro: Bool { return !self.purchasedProductIDs.isEmpty } @MainActor func updatePurchasedProducts() async { var purchasedProductIDs = Set<String>() for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.revocationDate == nil { purchasedProductIDs.insert(transaction.productID) } else { purchasedProductIDs.remove(transaction.productID) } } // only update if changed to avoid unnecessary published triggers if purchasedProductIDs != self.purchasedProductIDs { self.purchasedProductIDs = purchasedProductIDs } } } And I call the updatePurchasedProducts() when the app first launches in AppDelegate, before returning true on didFinishLaunchingWithOptions as: Task(priority: .high) { await DependencyContainer.shared.subscriptionManager.updatePurchasedProducts() } You may be wondering maybe the request is not finished yet and I fail to refresh my UI, but it is not the case. Because later on, every time I do something related to a subscribed content, I check the hasUnlockedPro computed property of the subscription manager, which still returns false, meaning the purchasedProductIDs is empty. You may also be curious about the dependency container approach, but I ensured by testing multiple times that there is only one instance of the SubscriptionManager at all times in the app. Which makes me think maybe there is something wrong with Transaction.currentEntitlements I would appreciate any help regarding this problem, or would like to know if anyone else experienced similar problems.
Replies
6
Boosts
7
Views
3k
Activity
May ’25
ToolbarItemGroup With Palette Style Cannot Present a View Controller While the Context Menu Is Visible
When I set up a toolbar item group with multiple options and set the controlGroupStyle as .palette, and when one of the options are supposed to present a view controller, I get the following error Attempt to present <UINavigationController: 0x101813200> on <ProjectName.HomeTabBarViewController: 0x10701bc00> (from <UINavigationController: 0x107821000>) which is already presenting <_UIContextMenuActionsOnlyViewController: 0x1035c19d0>. So basically the context menu we see is under the hood a view controller that is being presented. Is there a right way of fixing it, or is it maybe something that will be fixed by Apple? This is how I set up the ToolbarItemGroup on SwiftUI and the view model ultimately presents another UINavigationController that has a UIHostingController as its view controller: .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Button("ft_commons_edit".localised, systemImage: "pencil") { viewModel.didTapEditAction() } Button("ft_commons_delete".localised, systemImage: "trash") { viewModel.didTapDeleteAction() } } label: { Image("edit-icon") .resizable() .frame(width: 24.0, height: 24.0) } } .controlGroupStyle(.palette) This is how the view looks like when presentation fails: As a workaround, I found two options that work well. I’d like to share them and ask for recommendations, just to make sure they won’t cause any unexpected issues later on: Option 1: Access the top most visible view controller and attempt presenting on it This requires the following extension: extension UIViewController { func topMostViewController() -> UIViewController { if let presentedViewController = self.presentedViewController { return presentedViewController.topMostViewController() } else if let navigationController = self as? UINavigationController, let topViewController = navigationController.topViewController { return topViewController.topMostViewController() } else if let tabBarController = self as? UITabBarController, let selectedViewController = tabBarController.selectedViewController { return selectedViewController.topMostViewController() } else { return self } } } Then called as: navigationController.topMostViewController().present(exerciseEditingNavController, animated: true) Option 2: Call dismiss before attempting to present anything This also works fine, even without any delay, the menu is first dismissed and presentation works fine afterwards, code example: navigationController.dismiss(animated: true) navigationController.present(exerciseEditingNavController, animated: true) I feel like Option 1 would be the better choice, because if this context menu is ever no longer treated as a view controller and direct presentation starts working, Option 1 would still behave correctly by presenting from the topmost visible view controller. Option 2, on the other hand, could introduce a bug by dismissing an unrelated view controller if the context menu is no longer represented as a view controller at that point. I would appreciate any advice from anyone who has experienced this, or from Apple developers. Thanks
Replies
6
Boosts
0
Views
305
Activity
4d