Post

Replies

Boosts

Views

Created

TestFlight builds for macOS stuck processing for days without finishing
Hello! I'm encountering a weird issue on TestFlight/AppStoreConnect. I've builds that are in the "Processing" state since the 19th (that's 5 days ago from the date of this post). I've tried to generate new builds to see if it was just a fluke during those days, but new builds generated today also get stuck at processing. It's starting to become an issue because everybody on our team that's not a developer can't test the latest changes... Is there any way that I can get them unstuck? Thanks!
2
1
182
2w
What's the best way to detect if the app was installed from TestFlight (iOS & macOS)?
For ages, we've been using appStoreReceiptUrl to detect if the app was installed from TestFlight or not, but now that's deprecated. Since we have a strict policy of no warnings on the project, we need to find a way to check if the app was installed from TestFlight or from the App Store. Does anyone know what's the new way to do so? I thought about using MarketplaceKit.AppDistributor.testFlight but to use MarketplaceKit you need to jump through hoops that our app really doesn't need to - we don't distribute outside of the App Store. Any ideas are much appreciated! 🙏
0
2
183
Sep ’25
WebView makes website content unaccessible on the top/bottom edges
I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up). Here's a demo of the issue: Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar): Code: struct ContentView: View { var body: some View { NavigationStack { WebView(url: URL(string: "https://apple.com")).toolbar { ToolbarItem(placement: .primaryAction) { Button("Top content covered, unaccessible.") {} } } } } } Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?
13
1
379
Aug ’25
SwiftUI's List backed by CoreData using @FetchRequest fails to update on iOS 26 when compiled with Xcode 26
Hey there! I've been tracking a really weird behavior with a List backed by @FetchRequest from CoreData. When I toggle a bool on the CoreData model, the first time it updates correctly, but if I do it a second time, the UI doesn't re-render as expected. This does not happen if I compile the app using Xcode 16 (targeting both iOS 18 and iOS 26), nor it happens when using Xcode 26 and targeting iOS 18. It only happens when building the app using Xcode 26 and running it on iOS 26. Here are two demos: the first one works as expected, when I toggle the state twice, both times updates. The second one, only on iOS 26, the second toggle fails to re-render. Demo (running from Xcode 16): Demo (running from Xcode 26): The code: import SwiftUI import CoreData @main struct CoreDataTestApp: App { let persistenceController = PersistenceController.shared var body: some Scene { WindowGroup { ContentView() .environment(\.managedObjectContext, persistenceController.container.viewContext) } } } struct ContentView: View { @Environment(\.managedObjectContext) private var viewContext @FetchRequest(sortDescriptors: [NSSortDescriptor(keyPath: \Item.timestamp, ascending: true)]) private var items: FetchedResults<Item> var body: some View { NavigationView { List { ForEach(items) { item in HStack { Text(item.timestamp!.formatted()) Image(systemName: item.isFavorite ? "heart.fill" : "heart").foregroundStyle(.red) }.swipeActions(edge: .leading, allowsFullSwipe: true) { Button(item.isFavorite ? "Unfavorite" : "Favorite", systemImage: item.isFavorite ? "heart" : "heart.fill") { toggleFavoriteStatus(item: item) } } } } .toolbar { ToolbarItem { Button(action: addItem) { Label("Add Item", systemImage: "plus") } } } } } private func addItem() { withAnimation { let newItem = Item(context: viewContext) newItem.timestamp = Date() newItem.isFavorite = Bool.random() try! viewContext.save() } } private func toggleFavoriteStatus(item: Item) { withAnimation { item.isFavorite.toggle() try! viewContext.save() } } } struct PersistenceController { static let shared = PersistenceController() let container: NSPersistentContainer init() { container = NSPersistentContainer(name: "CoreDataTest") container.loadPersistentStores(completionHandler: { _, _ in }) container.viewContext.automaticallyMergesChangesFromParent = true } }
5
1
232
Aug ’25
Ask Each Time on macOS doesn't not allow empty selection
Hello! I'm facing a strange behavior on macOS related to Ask Each Time, which works fine on iOS. I've an App Intent that declares a parameter like so: @Parameter( title: "Tags", description: "Tags to add to the link.", optionsProvider: TagsOptionsProvider() ) var tags: [String]? The TagsOptionProvider is like this: struct TagsOptionsProvider: DynamicOptionsProvider { @Dependency private var modelCoordinator: ModelCoordinator @MainActor func results() async throws -> [String] { return modelCoordinator.tags().compactMap { $0.name } } } Now, the issue comes if I create a shortcut where for the tags parameter the user selects the magic variable Ask Each Time. On iOS, when the user is presented with the selector, they can simply tap 'Done' without selecting any value (the user does not want to include any tag). The problem is that on macOS the 'Done' button is disabled if there's no selection. See both behaviors: iOS: macOS: Question: Is there a way to let macOS continue even if the user doesn't select any of the available options like on iOS? I've tried declaring the tags para meter as Optional (like on the screenshot) and non-optional, both cases show the same behavior. Environment: iOS 18.5 macOS 15.5
1
0
272
Jul ’25
SwiftData ModelConfigurations always sync to iCloud if one of them has iCloud enabled
I'm facing a weird issue with SwiftData. I want to have one database that's local to the device and one that syncs to iCloud. In this example, LTRLink should be synced via iCloud while LTRMetadata should stay on-device only. I've it configured like the following: let schema = Schema([LTRLink.self, LTRMetadata.self]) let cloudkitConfiguration = ModelConfiguration("Remote", schema: schema, url: FileManager.remoteDatabaseFolderURL.appending(path: "Remote.sqlite"), cloudKitDatabase: .private("iCloud.com.xavimoll.abyss3")) let localConfiguration = ModelConfiguration("Local", schema: schema, url: FileManager.localDatabaseFolderURL.appending(path: "Local.sqlite"), cloudKitDatabase: .none) return try ModelContainer(for: schema, configurations: [cloudkitConfiguration, localConfiguration]) For some reason, when I create the iCloud schema, both models end up appearing as records on iCloud. I create the schema like this: let schema = Schema([LTRLink.self, LTRMetadata.self]) let cloudkitConfiguration = ModelConfiguration("Remote", schema: schema, url: FileManager.remoteDatabaseFolderURL.appending(path: "Remote.sqlite"), cloudKitDatabase: .private("iCloud.com.xavimoll.abyss3")) #if DEBUG // Needed to create the schema on iCloud try autoreleasepool { let desc = NSPersistentStoreDescription(url: cloudkitConfiguration.url) let opts = NSPersistentCloudKitContainerOptions(containerIdentifier: cloudkitConfiguration.cloudKitContainerIdentifier!) desc.cloudKitContainerOptions = opts desc.shouldAddStoreAsynchronously = false if let mom = NSManagedObjectModel.makeManagedObjectModel(for: [LTRLink.self]) { let container = NSPersistentCloudKitContainer(name: "Remote", managedObjectModel: mom) container.persistentStoreDescriptions = [desc] container.loadPersistentStores {_, err in if let err { fatalError(err.localizedDescription) } } try container.initializeCloudKitSchema() if let store = container.persistentStoreCoordinator.persistentStores.first { try container.persistentStoreCoordinator.remove(store) } } } #endif let localConfiguration = ModelConfiguration("Local", schema: schema, url: FileManager.localDatabaseFolderURL.appending(path: "Local.sqlite"), cloudKitDatabase: .none) return try ModelContainer(for: schema, configurations: [cloudkitConfiguration, localConfiguration]) The logic to initialize the CloudKit schema follows the documentation found here: https://developer.apple.com/documentation/swiftdata/syncing-model-data-across-a-persons-devices#Initialize-the-CloudKit-development-schema It looks like setting cloudKitDatabase: .none on the init for the ModelConfiguration doesn't do anything, and ends up being synced with iCloud either way. When I go to the iCloud console, I see the following: Does anyone know if there's any workaround that would allow me to have two databases where only one of them syncs to iCloud when using SwiftData?
1
0
643
Oct ’24
Slow rendering List backed by SwiftData @Query
Hello, I've a question about performance when trying to render lots of items coming from SwiftData via a @Query on a SwiftUI List. Here's my setup: // Item.swift: @Model final class Item: Identifiable { var timestamp: Date var isOptionA: Bool init() { self.timestamp = Date() self.isOptionA = Bool.random() } } // Menu.swift enum Menu: String, CaseIterable, Hashable, Identifiable { var id: String { rawValue } case optionA case optionB case all var predicate: Predicate<Item> { switch self { case .optionA: return #Predicate { $0.isOptionA } case .optionB: return #Predicate { !$0.isOptionA } case .all: return #Predicate { _ in true } } } } // SlowData.swift @main struct SlowDataApp: App { var sharedModelContainer: ModelContainer = { let schema = Schema([Item.self]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) return try! ModelContainer(for: schema, configurations: [modelConfiguration]) }() var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) } } // ContentView.swift struct ContentView: View { @Environment(\.modelContext) private var modelContext @State var selection: Menu? = .optionA var body: some View { NavigationSplitView { List(Menu.allCases, selection: $selection) { menu in Text(menu.rawValue).tag(menu) } } detail: { DemoListView(selectedMenu: $selection) }.onAppear { // Do this just once // (0..<15_000).forEach { index in // let item = Item() // modelContext.insert(item) // } } } } // DemoListView.swift struct DemoListView: View { @Binding var selectedMenu: Menu? @Query private var items: [Item] init(selectedMenu: Binding<Menu?>) { self._selectedMenu = selectedMenu self._items = Query(filter: selectedMenu.wrappedValue?.predicate, sort: \.timestamp) } var body: some View { // Option 1: touching `items` = slow! List(items) { item in Text(item.timestamp.description) } // Option 2: Not touching `items` = fast! // List { // Text("Not accessing `items` here") // } .navigationTitle(selectedMenu?.rawValue ?? "N/A") } } When I use Option 1 on DemoListView, there's a noticeable delay on the navigation. If I use Option 2, there's none. This happens both on Debug builds and Release builds, just FYI because on Xcode 16 Debug builds seem to be slower than expected: https://indieweb.social/@curtclifton/113273571392595819 I've profiled it and the SwiftData fetches seem blazing fast, the Hang occurs when accessing the items property from the List. Is there anything I'm overlooking or it's just as fast as it can be right now?
4
4
1.2k
Oct ’24
Xcode 15.3 and iOS 17.4 generate a CPU spike when launching the app
I've just updated to Xcode 15.3 and iOS 17.4 (simulator). Every time I launch the app, I see a CPU spike keeping the CPU at 100% for about 30 seconds on a background thread. After those 30 seconds, there's a 'Thread Performance Checker' error posted on the console. This does not happen when using Xcode 15.2 and running on iOS 17.2. or iOS 16.4. Thread Performance Checker: Thread running at User-initiated quality-of-service class waiting on a thread without a QoS class specified (base priority 33). Investigate ways to avoid priority inversions PID: 70633, TID: 2132693 Backtrace ================================================================= 3 CFNetwork 0x000000018454094c estimatedPropertyListSize + 28648 4 CFNetwork 0x00000001843d7fc0 cfnTranslateCFError + 1864 5 libdispatch.dylib 0x000000010557173c _dispatch_client_callout + 16 6 libdispatch.dylib 0x0000000105573210 _dispatch_once_callout + 84 7 CFNetwork 0x00000001843d7f8c cfnTranslateCFError + 1812 8 CFNetwork 0x0000000184540814 estimatedPropertyListSize + 28336 9 libdispatch.dylib 0x000000010557173c _dispatch_client_callout + 16 10 libdispatch.dylib 0x0000000105573210 _dispatch_once_callout + 84 11 CFNetwork 0x0000000184540728 estimatedPropertyListSize + 28100 12 CFNetwork 0x0000000184540794 estimatedPropertyListSize + 28208 13 libdispatch.dylib 0x000000010557173c _dispatch_client_callout + 16 14 libdispatch.dylib 0x0000000105573210 _dispatch_once_callout + 84 15 CFNetwork 0x0000000184540780 estimatedPropertyListSize + 28188 16 CFNetwork 0x00000001844e8664 _CFNetworkHTTPConnectionCacheSetLimit + 191584 17 CFNetwork 0x00000001844e78dc _CFNetworkHTTPConnectionCacheSetLimit + 188120 18 CFNetwork 0x000000018439ce5c _CFURLCachePersistMemoryToDiskNow + 25460 19 CFNetwork 0x0000000184483068 _CFStreamErrorFromCFError + 609680 20 CFNetwork 0x000000018445105c _CFStreamErrorFromCFError + 404868 21 CFNetwork 0x000000018443a040 _CFStreamErrorFromCFError + 310632 22 CFNetwork 0x000000018453be14 estimatedPropertyListSize + 9392 23 CFNetwork 0x000000018440fa5c _CFStreamErrorFromCFError + 137092 26 CFNetwork 0x000000018445b398 _CFStreamErrorFromCFError + 446656 27 CFNetwork 0x0000000184459db8 _CFStreamErrorFromCFError + 441056 28 CFNetwork 0x000000018445cf60 _CFStreamErrorFromCFError + 453768 29 CFNetwork 0x0000000184541838 estimatedPropertyListSize + 32468 30 libdispatch.dylib 0x000000010556fec4 _dispatch_call_block_and_release + 24 31 libdispatch.dylib 0x000000010557173c _dispatch_client_callout + 16 32 libdispatch.dylib 0x0000000105579a30 _dispatch_lane_serial_drain + 916 33 libdispatch.dylib 0x000000010557a774 _dispatch_lane_invoke + 420 34 libdispatch.dylib 0x000000010557b6e4 _dispatch_workloop_invoke + 864 35 libdispatch.dylib 0x00000001055871a8 _dispatch_root_queue_drain_deferred_wlh + 324 36 libdispatch.dylib 0x0000000105586604 _dispatch_workloop_worker_thread + 488 37 libsystem_pthread.dylib 0x0000000106b87924 _pthread_wqthread + 284 38 libsystem_pthread.dylib 0x0000000106b866e4 start_wqthread + 8
12
6
9.9k
Mar ’24
Xcode Cloud should not use Release Candidates of Xcode if the App Store doesn't accept them
If you have configured your workflows to use 'Latest Release', and there's a Release Candidate available, Xcode Cloud decides to use it. The problem is that the App Store rejects builds submitted with Release Candidate builds, at least that's what I'm encountering with Xcode 15.3 on the 27th of February, 2024: This is the error: Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isn’t supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases. I'm not really sure if the issue is on Xcode Cloud or on the App Store, but something's up and they don't like each other right now!
3
8
2.5k
Feb ’24
Xcode Cloud is not showing new branches on the branch picker when starting a manual workflow
Recently Xcode Cloud has stopped showing new branches on the branch picker. For example, I still see our main branch on the list, but branches that I pushed recently do not appear when trying to generate a manual build. We have another app where none of the branches appear, and the same app (with a different bundle ID we use for Production, they all appear except for the new ones). The GitHub integration seems fine since when PRs are merged to main, all workflows that listen to changes to main work fine, and on the Settings I can see that the last access to the GitHub repository is from a few minutes ago when pushing new things. The same issue happens on the integration of Xcode Cloud inside Xcode, none of the new branches is listed there. Looks like the issue is on whatever lists the branches available. Has anyone noticed this?
4
2
3.2k
Feb ’24
Xcode Cloud failure without any project changes: Invalid Provisioning Profile
We've been running Xcode Cloud smoothly for the last few months, and everything's been great. Yesterday everything was fine, but builds triggered today, start failing. Since last night to today there's been no changes in the project, but we're getting this: Invalid Provisioning Profile. The provisioning profile included in the bundle fm.here.ios.dev [Payload/Here.app] is invalid. [Missing code-signing certificate]. A Distribution Provisioning profile should be used when submitting apps to the App Store. For more information, visit the iOS Developer Portal. Not sure why out of the blue the provisioning profile is missing the code-signing certificate. Everything's automatically managed by Xcode, so I'm not sure what has changed. We get it for our fm.here.ios.dev app and for the regular fm.here.ios one, so not isolated to a single one, seems to be happening to all of them. I can't see anything expired on the developer portal, has there been a deploy of Xcode Cloud / App Store Connect that could trigger this?
3
2
1.6k
Jun ’23
ITMS-90382: Upload limit reached
We've started hitting this limitation when submitting builds using Xcode Cloud. ITMS-90382: Upload limit reached - The upload limit for your application has been reached. Please wait 1 day and try again. We generate TestFlight builds for every PR (builds from PR get sent to QA & devs) & for every merge (builds get sent to everybody in the team). Is there any way to know what's the limit so we can try to work around it? Edit: I've just checked, and TestFlight only reports 19 builds that are expiring in 90 days (aka were uploaded within the last 24h). Is the limit that low?
3
3
3.0k
Mar ’23