The brother app went through the review process two days ago. The new app in question went through the review process successfully an hour ago. So why the toolbar item images from Assets.xcassets were miniaturized into 4-by-by tiny images possibly under iOS 26? I have no clue. As a possible remedy, I have created 3 scale versions for each toolbarItem image at the exact sizes (84 px, 56 px, 28 px) as opposed to just one image having the app resize it. I was pretty much prepared to abandon this new app. I'm kind of surprised that it has gone through the review process without a hitch

If you use an M1 MacBook Air with 8 GB of memory, you may not be able to open multiple Xcode projects. I had one 2 and a half years ago at work. It often hung up. Also, depending on how much you write code, Xcode projects can quickly fill up your SSD. My M2 Mac mini has 512 GB space with an external HD taken from an old iMac machine. Each week, I create a few dozen Xcode projects in SwiftUI and lose several GB to them. So I end up deleting old data folders in DrivedData. As you probably, you cannot increase memory or swap SDDs with machines with Apple-made chips.

I have reluctantly upgraded my iPhone 14 to iOS 26 to run the new app that has been rejected. I don't see the 4-by-4 toolbar item image glitch. Meanwhile, I've sent a software update of the brother app with each image having three separate scale versions (@1x, @2x, @3x). So the image of each toolbar button is no longer resized as follows. Button { } label: { Image("ToolbarImage1") } Hopefully, I'll find out if a reviewer reports the same 4-by-4 toolbar item image glitch in a few days.

I think what they say is that you are advised to use TabView (in SwiftUI) if you are going to switch the entire content of the view. The Phone app seems to use a segmented control. (But who knows!?) Yet, it's used to filter the list content. Whatever it is isn't changing the entire content of the view.

Mr. Gemini who works for Google, Inc. says the following about 'iOS 26 image shrunken to 4 x 4.' Reports of images being "shrunken to 4x4" in iOS 26 refer to a visual glitch that some users experienced, which was caused by new features like CarPlay's Smart Display Zoom. This was not an intended feature of the new software, and Apple quickly addressed the issue. Here's an explanation of what happened: A new OS feature caused a visual glitch. With the release of iOS 26 in September 2025, some users reported that photos would be displayed as extremely small, 4x4 pixel images. The bug was tied to CarPlay. This issue appeared when using CarPlay and was related to a new setting called "Smart Display Zoom". Disabling this feature could resolve the problem for some users. Apple fixed it in a software update. The visual bug was never widespread and was resolved by Apple in the early 26.0.1 update, which was released just a few days after the initial public launch. The problem was a bug, not a feature. Unlike the "Liquid Glass" design or new Apple Intelligence features, the 4x4 image display was not an intended part of the iOS 26 experience.

in the last package we submitted for review, it was confirmed... That's never going to help, unfortunately. One reviewer accepts something, and another rejects it. That's because their guidelines can change. Also, it's possible that the first reviewer has simply made a mistake accepting your app. If you take it to the appeals board, I guarantee that they will reject your claim with a simple, flat rubber stamp without giving you a reason. And that will be the end of your app. You have to convince the reviewer somehow. But I wouldn't waste my time and would rather move on with my life. Just for your information, I've been in this business for 14.5 years.

As long as you give a new name like Example 2 as opposed to Example as the initial one with a new bundle ID, you can submit a new version. But you have to remove the old one. Some reviewers don't mind your leaving the old at the store. Most do mind and will reject your new submission. I have gone so far to Version 6 in this manner.

I'm sorry for the bad advice. I got mixed up. You get the said permission error for .fileImporter, not .fileExporter.

I'm trying to write to a file How!? By way of fileExporter(isPresented:document:contentType:defaultFilename:onCompletion:) ? If you use fileExporter and gets a permission error, that's most likely because you are not using the security-scoped bookmark.

Finally, ... They've made me wait for 1 hour and 35+ minutes.

You can customize the title text color and the background color of the navigation bar like the following for a workaround. import SwiftUI struct ContentView: View { @Environment(\.colorScheme) var colorScheme var body: some View { NavigationStack { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) } /* .navigationBarItems( trailing: Text("Trailing").foregroundStyle(.yellow) ) */ .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .principal) { Text("GGGGGGG GGGGGGG") .font(.title) .bold() .foregroundColor(colorScheme == .light ? .white : .black) } } .toolbarBackground(colorScheme == .light ? .black: .white, for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) } } }

You can customize the title text color and the background color of the navigation bar like the following for a workaround. import SwiftUI struct ContentView: View { @Environment(\.colorScheme) var colorScheme var body: some View { NavigationStack { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) } /* .navigationBarItems( trailing: Text("Trailing").foregroundStyle(.yellow) ) */ .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .principal) { Text("GGGGGGG") .font(.title) .bold() .foregroundColor(colorScheme == .light ? .white : .black) } } .toolbarBackground(colorScheme == .light ? .black: .white, for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) } } }

I think Error Code 1004 suggests that you have entered your domain incorrectly somewhere. What is your associated domain, and what's the domain that you give to ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: )? And what's the domain stated in your apple-app-site-association file? The domain has to be consistent in all these places.

Apple, Inc. has their own reviewers go over their OS releases since they introduced MacOS Lion to the public in the summer of 2011. I suppose they have a long list of apps to catch up with since they released iOS 26 and macOS 25 on top Xcode 26 last Monday. So it may take a little while they reach your app.

Oops... I've found the cause of the transfer issue. I've reported that my application's bundle identifier as something like com.example.HelloReady3. And my Xcode project has it as something like com.example.HelloReady-3. I'm sorry for blaming you, Apple, Inc. In fact, it was all my fault.