Post

Replies

Boosts

Views

Activity

Reply to Icon Composer icons together with iOS 18 icons
As posted in the other thread Steve4442 linked to: The way to go is the following (as John Siracusa) noted on Mastodon: Name your Tahoe .icon file the same as the name of your existing .appiconset in the Assets catalog. Set the ASSETCATALOG_OTHER_FLAGS build setting to: --enable-icon-stack-fallback-generation=disabled I can confirm that the Asset Catalog Other Flags still works with Xcode 26 RC! I’ve submitted two apps with that flag and both got approved by Apple. The App Store even displays the old icon in the iOS/macOS 18 App Store and the new icon in the iOS/macOS 26 App Store. You can see an example here in one of my apps.
Sep ’25
Reply to Icon Composer: Any way to add icons to the app bundle for older macOS versions?
Just want to confirm that the Asset Catalog Other Flags still works with Xcode 26 RC! I’ve submitted two apps with that flag and both got approved by Apple. The App Store even displays the old icon in the iOS/macOS 18 App Store and the new icon in the iOS/macOS 26 App Store. You can see an example here in one of my apps. So, to summarize in John Siracusa’s words again: Name your Tahoe .icon file the same as the name of your existing .appiconset in the Assets catalog. Set the ASSETCATALOG_OTHER_FLAGS build setting to: --enable-icon-stack-fallback-generation=disabled
Sep ’25
Reply to What can trigger "App uses the itms-services URL scheme to install an app" rejection?
I had the same issue recently. The problem was that my project readme.md had an example URL that started with itms-services:// (used from the Testing promoted In-App Purchases guide). I never used or initialized any of this in the actual code, though! It must have been an automatic check by Apple that triggered that. So, to solve that issue I just had to make sure that the readme was not included in the actual build files (by removing all target memberships) – which is probably a good idea anyway. 😅 Not it’s working for me. Tl;dr: Search for itms in all project files and see if you can hunt down the place where it’s mentioned.
Apr ’25
Reply to Migrate Core Data to SwiftData in an App Group (& CloudKit)
I’ve finally managed to get the migration working. What I did was basically: Using FileManager to check whether the .sqlite file exists at the old application directory. If that’s the case I can assume in my case that the migration wasn’t done, because after the migration this file will be deleted. The migration itself loads the old NSPersistentContainer and migrates it to the app group with the coordinators replacePersistentStore(at: appGroupURL, withPersistentStoreFrom: legacyDataURL, type: .sqlite) function. Remove all the old .sqlite files with the FileManagers .removeItem(at: legacyDataURL) function. That whole migration check and actual location-migration is run before initializing the SwiftData ModelContainer, which then points to the app group url via ModelConfiguration(url: appGroupURL). SwiftData will then automatically perform the SchemaMigrationPlan. IMPORTANT: Please note that you need to keep the old .xcdatamodel file in your project, otherwise it will fail to create the Core Data container! My Code Following the Adopting SwiftData for a Core Data app example code from Apple, I’ve now moved my ModelContainer to an actor that shares the container via a singleton with the app and widget. @main struct MyAppName: App { // App SwiftData Model Container let sharedModelContainer = DataModel.shared.modelContainer var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) } } actor DataModel { /// Singleton for entire app to use. static let shared = DataModel() /// Legacy location of the Core Data file. private let legacyDataURL = URL.applicationSupportDirectory.appending(path: "MyApp.sqlite") /// Location of the SwiftData file, saved in SQLite format. private let appGroupURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.domain.myapp")!.appendingPathComponent("MyApp.sqlite") private init() { // Checks for old Core Data migration before loading SwiftData. checkCoreDataMigration() } nonisolated lazy var modelContainer: ModelContainer = { let configuration = ModelConfiguration(url: appGroupURL) do { return try ModelContainer( for: Foo.self, Bar.self, migrationPlan: MigrationPlan.self, configurations: configuration) } catch { fatalError("Could not create SwiftData ModelContainer: \(error)") } }() nonisolated private func checkCoreDataMigration() { // If old store does exist perform the migration to App Group! // We can expect that the old store only exists if not yet migrated, because the migration deletes all old files. if FileManager.default.fileExists(atPath: legacyDataURL.path(percentEncoded: false)) { migrateCoreDataToAppGroup() } } nonisolated private func migrateCoreDataToAppGroup() { let container = NSPersistentContainer(name: "MyApp") let coordinator = container.persistentStoreCoordinator // 1. Migrate old Store do { // Replaces Application Support store with the one in the App Group. try coordinator.replacePersistentStore(at: appGroupURL, withPersistentStoreFrom: legacyDataURL, type: .sqlite) } catch { print("Error replacing persistent store in App Group: \(error)") } // 2. Delete old Store files NSFileCoordinator(filePresenter: nil).coordinate(writingItemAt: legacyDataURL, options: .forDeleting, error: nil) { url in do { try FileManager.default.removeItem(at: legacyDataURL) try FileManager.default.removeItem(at: legacyDataURL.deletingLastPathComponent().appendingPathComponent("MyApp.sqlite-shm")) try FileManager.default.removeItem(at: legacyDataURL.deletingLastPathComponent().appendingPathComponent("MyApp.sqlite-wal")) } catch { print("Error deleting persistent store at Application Support directory: \(error)") } } } } NOTE: Widget extensions may create an App Group store before the migration could happen by opening the app. Therefore I'm replacing the persistent store at the App Group location. Please note that this code doesn’t migrate to CloudKit yet!
Dec ’24
Reply to Use of 64pt and 68pt iOS App Icon Sizes
I finally figured it out by using the asset catalog to color the different sizes. Would be great if the HIG would clarify that in the first place! So as of Xcode 16.0 beta 5 the sizes are used the following way: 64pt Size Home Screen of iPhone Pro Max iOS 18’s small size only 68pt Size Home Screen of iPad Pro 13-inch iOS 18’s small size only Overview of all sizes iOS 18’s Sizing
Aug ’24
Reply to Use of 64pt and 68pt iOS App Icon Sizes
Even after the WWDC 24 announcements, I can’t find the sizes in the HIG specifications or anywhere else for that matter. As of iOS 18 beta 1 and Xcode 16 beta 1 my measurements show that the new small and large icon modes use the following icon sizes: iPhone 15 Pro Normal/Small: 60pt Large: 71pt iPad Pro 11-inch Normal/Small: 60pt Large: 76pt iPad Pro 13-inch Normal/Small: 68pt Large: 83.5pt (The sizes are all in @1x size and apply for their respecting device size categories) Interestingly the previous iPad icon sizes are now used for the large icon mode. The large mode on iPhone uses a totally new size, that we can’t even define directly. At least that shows what the 68pt icon is used for (iPad Pro 13-inch small mode)! Which makes sense, because we can’t define a @3x size which is only available on iPhone.
Jun ’24
Reply to What’s New with Apple Developer Forums
[quote='756215021, Forums Product Manager, /thread/756215'] Apple Developer Relations and Apple engineering are joining forces to field your questions and work to solve your technical issues. [/quote] This is super exciting to hear! I (and I think many other fellow devs) highly appreciate your efforts to make this happen. Getting more direct help from Apple engineers will be such a great thing. I’m looking forward to it. Thanks a ton for all those news and updates. Keep it coming! 🙌
Jun ’24
Reply to Access Core Data ModelContainer with SwiftData
After tons of experimenting (and help from Stack Overflow) I found the solution a few months ago. This basically matches CryptoKoa’s answer above, so I’m accepting theirs. Just wanted to provide the slightly different code I’ve used regarding the different naming of the old Core Data model. @main struct MyApp: App { let container: ModelContainer init() { // Legacy placement of the Core Data file. let dataUrl = URL.applicationSupportDirectory.appending(path: "Model.sqlite") do { // Create SwiftData container with migration and custom URL pointing to legacy Core Data file. container = try ModelContainer( for: Foo.self, Bar.self, migrationPlan: AppMigrationPlan.self, configurations: ModelConfiguration(url: dataUrl)) } catch { fatalError("Failed to initialize model container.") } } var body: some Scene { WindowGroup { ContentView() } .modelContainer(container) } }
May ’24