The first screenshot you have pasted says Apple Developer Program License Agreement has been updated. And the last screen suggests that you have a link to the said agreement. So if you click on the link and then scroll down to the bottom, what do you see? By the way, you are showing your name and your company name at the top-right corner of two screenshots. You shouldn't. There are bad people here and there. You never know who intends to impersonate you and your company.

returned from songs from the user library How!? Unless you explain how, I'm afraid the song variable that you refer to means nothing to the rest of the world. If you access this URL ( https://itunes.apple.com/search?term=classical+music&entity=song ), in the meantime, with URLSession, it will return two objects: resultCount and results. And you can easily return a dataset in the form of a JSON object. The results returns an array of dictionaries including a property named 'releaseDate.' Additionally, provided that you got your dataset with MPMediaQuery.songs, I would search for the 'MPMediaItem' class. Other than that, you probably want to explain how you get your data.

They are known to use an iPad to test the iOS app you submit regardless of the intended platform. I would ask them to send me a screen-capture video. But I don't know if they comply. I don't remember if they have ever sent me a screen-capture video. It's true that they sometimes go terribly wrong. Back in July, they claimed that nothing had happened in making an in-app purchase. It has turned out he or she failed to scroll down further and tapped an image, not a button. The same reviewer also claimed that a user would not be able to request customer support at our web site when in fact it was just the matter of scrolling down further, again, to find a comment box. I would send them a screenshot after circling the button they are supposed to tap to make sure he or she is not off the track. It's true that I sometimes make a mistake and deserve to get my software submissions rejected. But reviewers collectively make more mistakes than I do. I say they are wrong 2/3 of the times.

Since the minimum of deployment version that Xcode 26 supports is iOS 15.0, according to Gemini, I suppose, it should recognize your phone. And you are not able to run the iPhone 7 Simulator?

Depending on your minimum deployment version, isn't it just the matter of a elimination game with UIDevice.current.name? import SwiftUI struct ContentView: View { var body: some View { VStack { ... } .onAppear(perform: { let device = UIDevice.current print("1 \(device.name)") // iPhone 16 Pro print("2 \(device.systemName)") // iOS print("3 \(device.model)") // iPhone print("4 \(NSUserName())") // mobile print("5 \(device.description)") // <UIDevice: 0x28048dd70> //print("6 \(device.model)") // iPhone }) .padding() } }

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.