I’m testing FinanceKit with Apple Cash and noticed that transfers don’t include any counterparty information. Here’s an example transaction I fetched: Transaction( id: 5A96EA49-B7C9-4481-949D-88247210C1D7, accountID: 28D7C0E2-DC2A-4138-B105-BCE5EE00B705, transactionAmount: 30 USD, creditDebitIndicator: .credit, transactionDescription: "Transfer", originalTransactionDescription: "", merchantCategoryCode: nil, merchantName: nil, transactionType: .transfer, status: .booked, transactionDate: 2025-08-19 21:57:54 +0000, postedDate: 2025-08-19 21:57:55 +0000 ) As you can see: transactionDescription is just "Transfer" originalTransactionDescription is empty merchantName is nil No counterparty details are exposed In contrast, the Wallet app clearly shows the other person’s name and avatar for Apple Cash transfers, making it easy to understand who the payment was with. In FinanceKit, there’s no way to distinguish between transfers with different people — every transfer looks identical. Questions Is there a hidden or planned field for Apple Cash counterparty information? Can FinanceKit provide at least minimal metadata (e.g., contact name, initials, or a privacy-preserving identifier)? Is there any workaround today to correlate Apple Cash transfers with contacts? Feature request: Please expose counterparty information for Apple Cash transfers. Even something as simple as a stable identifier or name string would enable developers to build Wallet-quality transaction detail screens. Thanks!

I’m trying to understand the expected behavior of TabView when using .tabViewStyle(.page) on iPadOS with a hardware keyboard. When I place a TabView in page mode, swipe gestures correctly move between pages. However, left and right arrow keys do nothing by default, even when the view is made focusable. This feels a bit surprising, since paging with arrow keys seems like a natural keyboard interaction when a keyboard is attached. Right now, to get arrow-key navigation working, I have to manually: Make the view focusable Listen for arrow key presses Update the selection state manually This works, but it feels a little tedious for something that seems like it could be built-in. import SwiftUI struct PageTabsExample: View { @State private var selection = 0 private let pageCount = 3 var body: some View { TabView(selection: $selection) { Color.red.tag(0) Color.blue.tag(1) Color.green.tag(2) } .tabViewStyle(.page) .indexViewStyle(.page) .focusable(true) .onKeyPress(.leftArrow) { guard selection > 0 else { return .ignored } selection -= 1 return .handled } .onKeyPress(.rightArrow) { guard selection < pageCount - 1 else { return .ignored } selection += 1 return .handled } } } My questions: Is this lack of default keyboard paging for page-style TabView intentional on iPadOS with a hardware keyboard? Is there a built-in way to enable arrow-key navigation for page-style TabView, or is manual handling the expected approach? Does my approach above look like the “SwiftUI-correct” way to do this, or is there a better pattern for integrating keyboard navigation with paging? For this kind of behavior, is it generally recommended to use .onKeyPress like I’m doing here, or would .keyboardShortcut be more appropriate (for example, wiring arrow keys to actions instead)? Any guidance or clarification would be greatly appreciated. I just want to make sure I’m not missing a simpler or more idiomatic solution. Thanks!

When fetching Apple Savings transactions via FinanceKit, the data is missing key context about where the deposit originated from. Here’s an example transaction I retrieved: Transaction( id: 77371A0C-7122-42C7-BEBC-85BDF654AD2B, accountID: 68D9FE9D-6DA6-4A27-BB9D-19209CD29A56, transactionAmount: 1.46 USD, creditDebitIndicator: .credit, transactionDescription: "Deposit", originalTransactionDescription: "", merchantCategoryCode: nil, merchantName: nil, transactionType: .deposit, status: .booked, transactionDate: 2025-08-20 13:44:26 +0000, postedDate: 2025-08-20 13:44:26 +0000 ) As shown: transactionDescription is just "Deposit" merchantName is nil No indication of the source account In contrast, the Wallet app clearly shows context for Apple Savings account deposits, such as: "Apple Card" (daily cash) "Bank of America" (external transfer) "Interest Paid" (we do see "Interest" come through correctly) Without this metadata, third-party apps cannot replicate Wallet’s clarity about where a deposit came from. Every deposit simply appears as "Deposit", which is ambiguous. Request: Please expose additional metadata for Apple Savings account transactions, for example: sourceAccountName (e.g. “Apple Card” or “Bank of America”) transactionOriginType (cashback, external bank transfer, interest) institutionIdentifier or similar for external banks This would allow developers to show clear, Wallet-quality transaction details and avoid confusing users. Impact: The lack of source info makes Savings deposits nearly indistinguishable from one another, even though Wallet provides this context. For apps leveraging FinanceKit, this results in a poorer experience compared to Apple’s own Wallet. Thanks!

Hi all — I’m building a Wallet-style transaction details view using FinanceKit and I’m running into a gap around merchant location. What I’m seeing FinanceKit gives me great core fields (amount, currency, status, dates, MCC, merchantName, transactionDescription), but I’m not seeing any address or place/location metadata on a Transaction. For example, a small/local merchant where I can plausibly infer a single place: Fetched transaction: Transaction( id: 8D142B16-3E0E-40B8-945A-2E7C0CF65F1D, accountID: 14939CF4-DBC3-4A9D-8292-5FEA495B8461, transactionAmount: 47.24 USD, creditDebitIndicator: .debit, transactionDescription: "Local Dental Care", originalTransactionDescription: "Local Dental Care", merchantCategoryCode: 8021, merchantName: "Local Dental Care", transactionType: .pointOfSale, status: .booked, transactionDate: 2025-08-20 22:27:50 +0000, postedDate: 2025-08-21 11:22:06 +0000 ) Because this appears to be a single-location practice, I can usually resolve it to a place using MapKit search heuristics. But for big-box chains, I don’t get enough signal to determine which store: Fetched transaction: Transaction( id: 3F8E9F74-7565-4D24-9038-8FD709184799, accountID: 14939CF4-DBC3-4A9D-8292-5FEA495B8461, transactionAmount: 441.77 USD, creditDebitIndicator: .debit, transactionDescription: "The Home Depot", originalTransactionDescription: "The Home Depot", merchantCategoryCode: 5200, merchantName: "The Home Depot", transactionType: .pointOfSale, status: .booked, transactionDate: 2023-12-27 23:07:02 +0000, postedDate: 2023-12-29 03:09:41 +0000 ) There’s no store number, address, phone, or any stable identifier. With hundreds of locations, I can’t deterministically choose a map pin or fetch the right brand assets. What I’m trying to achieve I’d like to replicate the Apple Wallet experience: show a small map snapshot and merchant visuals (logo/name that match Apple Maps / the Place Card) on the transaction detail screen. Without a location hint, I have to either: Ask users to pick a store manually, or Make a guess based on a coarse, app-defined region …neither of which feels great. Questions Is there any way in FinanceKit today to access merchant location or a resolvable identifier (e.g., address, city/state, store number, Apple Maps place identifier, network merchant ID/MID, terminal ID, etc.)? If not, can FinanceKit expose additional merchant metadata (even opt-in / privacy-preserving) to enable Wallet-like enrichment? A few examples that would unblock this: merchantAddress (or components: street/city/region/postalCode/country) merchantPhone (often unique per store) merchantIdentifier (stable per physical location, e.g., network merchant ID / store number) mapsPlaceURL or mapsPlaceIdentifier (linkage to the Apple Maps Place Card) brandAssetURL (logo/brand reference similar to what Wallet shows) With even one of the above, I could reliably: Render an accurate map snapshot, Fetch the correct brand assets, and Avoid prompting the user or inferring via fuzzy search. Context / constraints I do not want to (and shouldn’t need to) request or monitor the user’s device location to resolve a merchant’s store location. For small merchants, MapKit text search is often enough. For large chains, I need a store-level identifier. If there’s an existing field or recommended approach I’m missing, I’d love pointers. If not, please consider this a feature request for richer merchant metadata in FinanceKit so developers can build Wallet-quality transaction details. Thanks!

There appears to be a visual bug when using .searchable in a child view that’s pushed via NavigationLink inside a NavigationStack. Specifically, the search bar appears briefly in the wrong position (or animates in an unexpected way) during the transition to the child view. This issue does not occur when using NavigationView instead of NavigationStack. Steps to Reproduce: Create a TabView with a single tab containing a NavigationStack. Push from a ContentView to a DetailsView using NavigationLink. Add a .searchable modifier to both the ContentView and DetailsView. Run the app and tap a row to navigate to the details view. Expected Behavior The search bar in the DetailsView should appear smoothly and in the correct position as the view transitions in, just like it does under NavigationView. Actual Behavior When the DetailsView appears, the search bar briefly animates or appears in the wrong location before settling into place. This results in a jarring or buggy visual experience. Feedback: FB17031212 Here is a reddit thread discussing the issue as well https://www.reddit.com/r/SwiftUI/comments/137epji/navigation_stack_with_search_bar_has_a_bug_and_a/ I hope that an Apple engineer can get this fixed soon. It's frustrating to have new APIs come out with the old deprecated yet there are still obvious bugs two years later. import SwiftUI public enum Tab { case main } struct AppTabNavigation: View { @State private var tabSelection = Tab.main var body: some View { TabView(selection: $tabSelection) { NavigationStack { ContentView() } .tag(Tab.main) .tabItem { Label("Main", systemImage: "star") } } } } struct ContentView: View { @State private var searchText = "" var body: some View { List(0..<100) { i in NavigationLink("Select \(i)", value: i) } .navigationTitle("Main") .searchable(text: $searchText) .navigationDestination(for: Int.self) { i in DetailsView(i: i) } } } struct DetailsView: View { @State private var searchText = "" let i: Int // MARK: - Body var body: some View { List { ForEach(0..<10, id: \.self) { i in Text("Hello \(i)") } } .navigationTitle(i.formatted()) .searchable(text: $searchText) } }

I've encountered an issue where using @Observable in SwiftUI causes extra initializations and deinitializations when a reference type is included as a property inside a struct. Specifically, when I include a reference type (a simple class Empty {}) inside a struct (Test), DetailsViewModel is initialized and deinitialized twice instead of once. If I remove the reference type, the behavior is correct. This issue does not occur when using @StateObject instead of @Observable. Additionally, I've submitted a feedback report: FB16631081. Steps to Reproduce Run the provided SwiftUI sample code (tested on iOS 18.2 & iOS 18.3 using Xcode 16.2). Observe the console logs when navigating to DetailsView. Comment out var empty = Empty() in the Test struct. Run again and compare console logs. Change @Observable in DetailsViewModel to @StateObject and observe that the issue no longer occurs. Expected Behavior The DetailsViewModel should initialize once and deinitialize once, regardless of whether Test contains a reference type. Actual Behavior With var empty = Empty() present, DetailsViewModel initializes and deinitializes twice. However, if the reference type is removed, or when using @StateObject, the behavior is correct (one initialization, one deinitialization). Code Sample import SwiftUI enum Route { case details } @MainActor @Observable final class NavigationManager { var path = NavigationPath() } struct ContentView: View { @State private var navigationManager = NavigationManager() var body: some View { NavigationStack(path: $navigationManager.path) { HomeView() .environment(navigationManager) } } } final class Empty { } struct Test { var empty = Empty() // Comment this out to make it work } struct HomeView: View { private let test = Test() @Environment(NavigationManager.self) private var navigationManager var body: some View { Form { Button("Go To Details View") { navigationManager.path.append(Route.details) } } .navigationTitle("Home View") .navigationDestination(for: Route.self) { route in switch route { case .details: DetailsView() .environment(navigationManager) } } } } @MainActor @Observable final class DetailsViewModel { var fullScreenItem: Item? init() { print("DetailsViewModel Init") } deinit { print("DetailsViewModel Deinit") } } struct Item: Identifiable { let id = UUID() let value: Int } struct DetailsView: View { @State private var viewModel = DetailsViewModel() @Environment(NavigationManager.self) private var navigationManager var body: some View { ZStack { Color.green Button("Show Full Screen Cover") { viewModel.fullScreenItem = .init(value: 4) } } .navigationTitle("Details View") .fullScreenCover(item: $viewModel.fullScreenItem) { item in NavigationStack { FullScreenView(item: item) .navigationTitle("Full Screen Item: \(item.value)") .toolbar { ToolbarItem(placement: .cancellationAction) { Button("Cancel") { withAnimation(completionCriteria: .logicallyComplete) { viewModel.fullScreenItem = nil } completion: { var transaction = Transaction() transaction.disablesAnimations = true withTransaction(transaction) { navigationManager.path.removeLast() } } } } } } } } } struct FullScreenView: View { @Environment(\.dismiss) var dismiss let item: Item var body: some View { ZStack { Color.red Text("Full Screen View \(item.value)") .navigationTitle("Full Screen View") } } } Console Output With var empty = Empty() in Test DetailsViewModel Init DetailsViewModel Init DetailsViewModel Deinit DetailsViewModel Deinit Without var empty = Empty() in Test DetailsViewModel Init DetailsViewModel Deinit Using @StateObject Instead of @Observable DetailsViewModel Init DetailsViewModel Deinit Additional Notes This issue occurs only when using @Observable. Switching to @StateObject prevents it. This behavior suggests a possible issue with how SwiftUI handles reference-type properties inside structs when using @Observable. Using a struct-only approach (removing Empty class) avoids the issue, but that’s not always a practical solution. Questions for Discussion Is this expected behavior with @Observable? Could this be an unintended side effect of SwiftUI’s state management? Are there any recommended workarounds apart from switching to @StateObject? Would love to hear if anyone else has run into this or if Apple has provided any guidance!

I would like to report a memory leak issue in watchOS 11.2 that occurs when using .navigationTitle() inside a sheet. This behavior is reproducible both on the simulator and on a real device, but not on iOS. While this does not register as a leak in Instruments, the deinit of the DetailsViewModel is never called, and multiple instances of the view model accumulate in the Memory Graph Debugger. Commenting out .navigationTitle("Sheet View") resolves the issue, and deinit prints as expected. Using @MainActor on the DetailsViewModel does not fix the issue. Nor does switching to @StateObject and using ObservableObject resolve the memory retention. This issue seems related to other SwiftUI memory leaks that have been reported: https://developer.apple.com/forums/thread/738840 https://developer.apple.com/forums/thread/736110?login=true&page=1#769898022 https://developer.apple.com/forums/thread/737967?answerId=767599022#767599022 Feedback Number: FB16442048 struct MainView: View { var body: some View { NavigationStack { NavigationLink("Details", value: 1) .navigationDestination(for: Int.self) { _ in DetailsView() } } } } struct SheetObject: Identifiable { let id = UUID() let date: Date let value: Int } @Observable @MainActor final class DetailsViewModel { var sheetObject: SheetObject? init() { print("Init") } deinit { print("Deinit") } func onAppear() async { try? await Task.sleep(for: .seconds(2)) sheetObject = .init(date: .now, value: 1) } } struct DetailsView: View { @State private var viewModel = DetailsViewModel() @Environment(\.dismiss) var dismiss var body: some View { Text("Detail View. Going to sheet, please wait...") .task { await viewModel.onAppear() } .sheet(item: $viewModel.sheetObject) { sheetObject in SheetView(sheetObject: sheetObject) .onDisappear { dismiss() } } } } struct SheetView: View { let sheetObject: SheetObject @Environment(\.dismiss) var dismiss var body: some View { NavigationStack { VStack { Text(sheetObject.date.formatted()) Text(sheetObject.value.formatted()) Button("Dismiss") { dismiss() } } .navigationTitle("Sheet View") // This line causes a memory leak. Commenting out, you will see "Deinit" be printed. } } }

I’m getting a 0xdead10cc crash in a basic CoreData/CloudKit application. I only have one CoreData save call and its made when the app is in the foreground and it's minor so I don't think its being caused by that. My best guess is that it's related to background syncing of CloudKit. Does anyone know how to fix it? I've been advised that adding the following code around any saves will fix it, but it seems weird that this is the solution. I would expect the inner CoreData/CloudKit engine to handle this. ProcessInfo().performActivity(reason: "Persisting to context") { // Save to context here } Here is the crashing thread Thread 7: 0 libsystem_kernel.dylib 0x00000001edc086f4 guarded_pwrite_np + 8 (:-1) 1 libsqlite3.dylib 0x00000001ca71b6e4 seekAndWrite + 456 (sqlite3.c:44287) 2 libsqlite3.dylib 0x00000001ca6d5df4 unixWrite + 180 (sqlite3.c:44365) 3 libsqlite3.dylib 0x00000001ca723b90 pagerWalFrames + 872 (sqlite3.c:67093) 4 libsqlite3.dylib 0x00000001ca6d5b14 sqlite3PagerCommitPhaseOne + 316 (sqlite3.c:70409) 5 libsqlite3.dylib 0x00000001ca6c6494 sqlite3BtreeCommitPhaseOne + 172 (sqlite3.c:81106) 6 libsqlite3.dylib 0x00000001ca6c605c vdbeCommit + 1136 (sqlite3.c:94124) 7 libsqlite3.dylib 0x00000001ca69f778 sqlite3VdbeHalt + 1340 (sqlite3.c:94534) 8 libsqlite3.dylib 0x00000001ca6c0618 sqlite3VdbeExec + 42648 (sqlite3.c:103922) 9 libsqlite3.dylib 0x00000001ca6b56c0 sqlite3_step + 960 (sqlite3.c:97886) 10 CoreData 0x00000001a459ab38 _execute + 128 (NSSQLiteConnection.m:4614) 11 CoreData 0x00000001a45fe004 -[NSSQLiteConnection commitTransaction] + 728 (NSSQLiteConnection.m:3278) 12 CoreData 0x00000001a469888c _executeGenerateObjectIDRequest + 388 (NSSQLCore_Functions.m:6021) 13 CoreData 0x00000001a46986a4 -[NSSQLGenerateObjectIDRequestContext executeRequestCore:] + 28 (NSSQLObjectIDRequestContext.m:42) 14 CoreData 0x00000001a45fb380 -[NSSQLStoreRequestContext executeRequestUsingConnection:] + 240 (NSSQLStoreRequestContext.m:183) 15 CoreData 0x00000001a45fb0a8 __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke + 60 (NSSQLConnectionManager.m:307) 16 CoreData 0x00000001a45fafe0 __37-[NSSQLiteConnection performAndWait:]_block_invoke + 48 (NSSQLiteConnection.m:755) 17 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 18 libdispatch.dylib 0x00000001a43677fc _dispatch_lane_barrier_sync_invoke_and_complete + 56 (queue.c:1104) 19 CoreData 0x00000001a45b5ba4 -[NSSQLiteConnection performAndWait:] + 176 (NSSQLiteConnection.m:752) 20 CoreData 0x00000001a45b5a68 -[NSSQLDefaultConnectionManager handleStoreRequest:] + 248 (NSSQLConnectionManager.m:302) 21 CoreData 0x00000001a45b5938 -[NSSQLCoreDispatchManager routeStoreRequest:] + 228 (NSSQLCoreDispatchManager.m:60) 22 CoreData 0x00000001a45b573c -[NSSQLCore dispatchRequest:withRetries:] + 172 (NSSQLCore.m:4044) 23 CoreData 0x00000001a46737b4 -[NSSQLCore _obtainPermanentIDsForObjects:withNotification:error:] + 1324 (NSSQLCore.m:2830) 24 CoreData 0x00000001a460ba98 -[NSSQLCore _prepareForExecuteRequest:withContext:error:] + 272 (NSSQLCore.m:2946) 25 CoreData 0x00000001a460a0f8 __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke.547 + 8988 (NSPersistentStoreCoordinator.m:2995) 26 CoreData 0x00000001a45d6660 -[NSPersistentStoreCoordinator _routeHeavyweightBlock:] + 264 (NSPersistentStoreCoordinator.m:668) 27 CoreData 0x00000001a45ded28 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1200 (NSPersistentStoreCoordinator.m:2810) 28 CoreData 0x00000001a4655988 -[NSManagedObjectContext save:] + 984 (NSManagedObjectContext.m:1593) 29 CoreData 0x00000001a46f47dc __52+[NSCKEvent beginEventForRequest:withMonitor:error:]_block_invoke_2 + 352 (NSCKEvent.m:76) 30 CoreData 0x00000001a45c28f0 developerSubmittedBlockToNSManagedObjectContextPerform + 476 (NSManagedObjectContext.m:3984) 31 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 32 libdispatch.dylib 0x00000001a43677fc _dispatch_lane_barrier_sync_invoke_and_complete + 56 (queue.c:1104) 33 CoreData 0x00000001a4615c34 -[NSManagedObjectContext performBlockAndWait:] + 308 (NSManagedObjectContext.m:4108) 34 CoreData 0x00000001a46f45ac __52+[NSCKEvent beginEventForRequest:withMonitor:error:]_block_invoke + 192 (NSCKEvent.m:66) 35 CoreData 0x00000001a4825e68 -[PFCloudKitStoreMonitor performBlock:] + 92 (PFCloudKitStoreMonitor.m:148) 36 CoreData 0x00000001a46f4394 +[NSCKEvent beginEventForRequest:withMonitor:error:] + 256 (NSCKEvent.m:61) 37 CoreData 0x00000001a47cc6ec __57-[NSCloudKitMirroringDelegate _performExportWithRequest:]_block_invoke + 260 (NSCloudKitMirroringDelegate.m:1433) 38 CoreData 0x00000001a47c9970 __92-[NSCloudKitMirroringDelegate _openTransactionWithLabel:assertionLabel:andExecuteWorkBlock:]_block_invoke + 72 (NSCloudKitMirroringDelegate.m:957) 39 libdispatch.dylib 0x00000001a4356248 _dispatch_call_block_and_release + 32 (init.c:1549) 40 libdispatch.dylib 0x00000001a4357fa8 _dispatch_client_callout + 20 (object.m:576) 41 libdispatch.dylib 0x00000001a435f5cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 42 libdispatch.dylib 0x00000001a4360158 _dispatch_lane_invoke + 432 (queue.c:4025) 43 libdispatch.dylib 0x00000001a436b38c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 44 libdispatch.dylib 0x00000001a436abd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 45 libsystem_pthread.dylib 0x0000000227213680 _pthread_wqthread + 288 (pthread.c:2696) 46 libsystem_pthread.dylib 0x0000000227211474 start_wqthread + 8 (:-1)

I have integrated CloudKit into a CoreData application and am ready to deploy the schema to production but keep getting an "internal error" when trying to deploy to production or reset my CloudKit environment. I have attached images of what I am seeing including one of the console error. Is there any way to resolve this?

I'm displaying a GKGameCenterViewController after successfully authenticating and on iOS 18.0 and 18.1, I get a black screen. As a sanity check GKLocalPlayer.local.isAuthenticated is also returning true. The same code works just fine on iOS 17. Is there something that needs to be done on iOS 18 and above?

MPMusicPlayerControllers nowPlayingItem no longer seems to be able to change a song. The code use to work but seems to be broken on iOS 16, 17 and now the iOS 18 beta. When newSong is triggered, the song restarts but it does not change songs. Instead I get the following error: Failed to set now playing item error=<MPMusicPlayerControllerErrorDomain.5 "Unable to play item <MPConcreteMediaItem: 0x9e9f0ef70> 206357861099970620" {}>. The documentation seems to indicate I’m doing things correctly. class MusicPlayer { var songTwo: MPMediaItem? let player = MPMusicPlayerController.applicationMusicPlayer func start() async { await MPMediaLibrary.requestAuthorization() let myPlaylistsQuery = MPMediaQuery.playlists() let playlists = myPlaylistsQuery.collections!.filter { $0.items.count > 2} let playlist = playlists.first! let songOne = playlist.items.first! songTwo = playlist.items[1] player.setQueue(with: playlist) play(songOne) } func newSong() { guard let songTwo else { return } play(songTwo) } private func play(_ song: MPMediaItem) { player.stop() player.nowPlayingItem = song player.prepareToPlay() player.play() } }

I have a full screen list and want to use the new keyboardLayoutGuide constraint, but by default it uses the safe area inset. How can I disable this so my list goes all the way to the bottom of the screen when the keyboard is not shown? NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.bottomAnchor.constraint(equalTo: view.keyboardLayoutGuide.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo:  view.trailingAnchor) ])

Using the App Store Connect API how can you get the release date for an app? I've been able to use this endpoint to list a bunch of information, however the release date is not included. As you can see in the JSON response posted below, it does have a "createdDate" but this corresponds to when the version was made in App Store Connect (Prepare for Submission), not when it was released to the store. This can be verified by looking in App Store connect. JSON Response: https://api.appstoreconnect.apple.com/v1/apps/395389919/appStoreVersions?limit=1 { "data": [ { "type": "appStoreVersions", "id": "a75acc6e-9429-4539-a282-eadef235169e", "attributes": { "platform": "IOS", "versionString": "5.9.0", "appStoreState": "READY_FOR_SALE", "copyright": "InterPro Solutions, LLC", "releaseType": "MANUAL", "earliestReleaseDate": null, "usesIdfa": null, "downloadable": true, "createdDate": "2021-10-11T08:37:22-07:00" }, "relationships": { "ageRatingDeclaration": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/ageRatingDeclaration", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/ageRatingDeclaration" } }, "appStoreVersionLocalizations": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/appStoreVersionLocalizations", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/appStoreVersionLocalizations" } }, "build": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/build", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/build" } }, "appStoreVersionPhasedRelease": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/appStoreVersionPhasedRelease", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/appStoreVersionPhasedRelease" } }, "routingAppCoverage": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/routingAppCoverage", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/routingAppCoverage" } }, "appStoreReviewDetail": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/appStoreReviewDetail", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/appStoreReviewDetail" } }, "appStoreVersionSubmission": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/appStoreVersionSubmission", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/appStoreVersionSubmission" } }, "idfaDeclaration": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/idfaDeclaration", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/idfaDeclaration" } }, "appClipDefaultExperience": { "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/relationships/appClipDefaultExperience", "related": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e/appClipDefaultExperience" } } }, "links": { "self": "https://api.appstoreconnect.apple.com/v1/appStoreVersions/a75acc6e-9429-4539-a282-eadef235169e" } } ], "links": { "self": "https://api.appstoreconnect.apple.com/v1/apps/395389919/appStoreVersions?limit=1", "next": "https://api.appstoreconnect.apple.com/v1/apps/395389919/appStoreVersions?cursor=AQ.ANZyDDk&limit=1" }, "meta": { "paging": { "total": 68, "limit": 1 } } }

I have a simple UIKit application that has a UITextView in a UICollectionViewCell. The app is designed for iOS/iPadOS and works just fine on those platforms. However, when run on Mac (Designed for iPad) as soon as I start scrolling the collectionview, the cpu usage spikes to ~85% and stays there indefinitely. The only way to lower the cpu is to click outside of the application window, but once it comes to the foreground again, the cpu usage jumps right back up. I've tried running on Mac in Catalyst mode too, but the same problem occurs with slightly less cpu usage (~45%). Additionally the debugger constantly spits out [API] cannot add handler to 3 from 3 - dropping while scrolling. Does anyone have an explanation or solutions for this? I’m using Xcode Version 14.1 (14B47b) on macOS Ventura 13.0 (22A380). class ViewController: UIViewController { var dataSource: UICollectionViewDiffableDataSource<Section, String>! = nil var collectionView: UICollectionView! = nil var items = Array(0...100).map{"Item \($0)"} enum Section: String { case main } override func viewDidLoad() { super.viewDidLoad() navigationItem.title = "List" configureCollectionView() configureDataSource() applyInitialSnapshot() } private func createLayout() -> UICollectionViewLayout { return UICollectionViewCompositionalLayout { sectionIndex, layoutEnvironment in let size = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(100)) let item = NSCollectionLayoutItem(layoutSize: size) let group = NSCollectionLayoutGroup.horizontal(layoutSize: size, subitems: [item]) return NSCollectionLayoutSection(group: group) } } private func configureCollectionView() { collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: createLayout()) collectionView.autoresizingMask = [.flexibleWidth, .flexibleHeight] collectionView.backgroundColor = .systemBackground view.addSubview(collectionView) } private func configureDataSource() { let cellRegistration = UICollectionView.CellRegistration<TestCell, String> { (cell, indexPath, item) in cell.configure(title: item, row: indexPath.item) } dataSource = UICollectionViewDiffableDataSource<Section, String>(collectionView: collectionView) { (collectionView, indexPath, identifier) -> UICollectionViewCell? in return collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: identifier) } } private func applyInitialSnapshot() { var snapshot = NSDiffableDataSourceSnapshot<Section, String>() snapshot.appendSections([.main]) snapshot.appendItems(items) dataSource.apply(snapshot, animatingDifferences: false) } } class TestCell: UICollectionViewCell { private let annotationsTextView = UITextView() override init(frame: CGRect) { super.init(frame: frame) addViews() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func configure(title: String, row: Int) { annotationsTextView.attributedText = .init(string: "Row: \(row) Item: \(title)", attributes: [.font: UIFont.preferredFont(forTextStyle: .title1)]) } private func addViews() { annotationsTextView.isScrollEnabled = false annotationsTextView.isEditable = false annotationsTextView.translatesAutoresizingMaskIntoConstraints = false contentView.addSubview(annotationsTextView) NSLayoutConstraint.activate([ annotationsTextView.topAnchor.constraint(equalTo: contentView.topAnchor), annotationsTextView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), annotationsTextView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), annotationsTextView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), ]) } }

When using .accessibilityElement(children: .contain) on a SwiftUI Button, the children do not show up in the accessibility inspector. Instead, the Button is the only element shown and its identifier is a combination of all the children. How can I make only the children identifiers show? Button { } label: {     VStack {         Image(systemName: "star")             .accessibilityIdentifier("logo_image")         Text("Subtitle")              .accessibilityIdentifier("subtitle_text")         } } .accessibilityElement(children: .contain) If I remove the button and only use the VStack the elements appear individually. This is what I am trying to achieve while using the Button. VStack {     Image(systemName: "star")           .accessibilityIdentifier("logo_image")      Text("Subtitle")            .accessibilityIdentifier("subtitle_text") }