Hello everyone, I’m looking for some advice or shared experiences regarding an app rejection under App Store Review Guideline 4.3(b) – Design – Spam. Our app was rejected and, after an appeal to the App Review Board, Apple maintained that the app “duplicates the content and functionality of similar apps in a saturated category.” We strongly disagree with this classification and are struggling to understand how Guideline 4.3(b) has been applied in our case. The app was developed as an original product: Custom-designed content (including original cards and interactions) A unique visual style and UI A distinct interaction flow focused on encouraging social interaction between users This was not a template-based or reskinned app, nor is it part of a series of similar submissions. We fully respect the App Store Review Guidelines and are open to making adjustments to better align with them. However, what we find difficult is the lack of specific, actionable feedback. We have not received clear guidance on which exact elements are considered duplicative or what changes would meaningfully address the concern. Some of the questions we are hoping the community can help with: In your experience, what typically triggers a 4.3(b) rejection in cases like this? Are there specific mechanics, terminology, or presentation choices that reviewers often interpret as problematic? Have others successfully resolved a 4.3(b) rejection without completely abandoning their app concept? We have already invested significant time and resources into this project, and being advised to create an entirely new app is not financially feasible for us. We are genuinely trying to understand how to proceed in a way that is constructive and compliant. Any insights, experiences, or advice would be greatly appreciated. Thank you in advance. — Lars

Your app still contains features that mimic the iOS interface or behavior. I have a simple app that uses a NavigationSplitView 3 panels I have a section for Filters and User created Categories in Panel 1 A list of "Requests" from the selected Filters/Categories in Panel 2 and details of a request in Panel 3 It's designed to be simple and easy to use. How can it NOT "mimic the iOS interface" if I am using their own APIs? What should I do to get around this

I've designed a new UI for phones.. I'd like Apple to look at it and see what they think https://docs.google.com/presentation/d/10QSQvAdRRkL-eA9WRsSEbsL62XIayJ75Mbi93tx92DI/edit?usp=drive_link

Hello Apple Engineering Team and Fellow Developers, I’ve been using iOS 26 beta from day one and closely following all its improvements. One feature that significantly enhances the user experience is the automatic hiding of the Home Bar (the bottom navigation indicator) after a few seconds of inactivity in menus and apps. This subtle but powerful UI behavior not only increases immersion but also reduces distractions, making navigation smoother and visually cleaner. I strongly urge the Apple team to integrate this feature into the upcoming iOS 18.6 update. Bringing this polished interaction to iOS 18 users would greatly improve usability and keep the interface modern and elegant. Thank you for your continuous efforts in refining iOS. Looking forward to seeing this improvement officially adopted soon! Best regards, [ERFANEX]

So…I am hitting a wall here and could use some guidance towards best practice. I’ve developed an app in Xcode/SwiftUI that renders just fine on the iPhone - text, images, buttons, frames…everything is nicely centered on the screen or scrolls where and when I want. The iPad though…not so much. I’m having issues with tops and bottoms being cut off in scrollviews. These are just straight up text screens too - the ones with other elements/controls…they’re rendering fine. I’ve tried a mix of geometry, vstack, scrollview, padding, spacers…the lot of it. Nothing I seem to do works - the views do not want to fill and fit properly. And, of course, the issue becomes worse the moment you flip the iPad into landscape view. Or use the 13” models. I’d imagine others are battling these issues as well and found solutions, so I decided to hit up the brain trust.

I'm trying to display CPButtons (CPContactCallButton, CPContactMessageButton) in CPContactTemplate. They are displayed using device with iOS16, but with iOS26 device CPContactTemplate only displays contact image and contact name. No buttons. Is it a bug? I don't have iOS17/18 devices to try.

I have really examined the swipe left Camera function mode and sincerely believe it is no more important especially when there no option in the settings to turn it on or off. I will highly recommend a total scrap in the iOS 26 or if possible a function to activate and deactivate it.

Hi community my name is Adam Robles. I have a question. I recently downloaded the beta on my iPad Pro 13 inch and I noticed where are the iPad wallpapers I only get one wallpaper, but where what happened to the wallpaper that was released with iPad last year

We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App). TabView(selection: $viewModel.selectedTab) { // Tabs here } .tabViewBottomAccessory { if viewModel.showAudioMiniPlayer { MiniPlayerView() } } The Problem This code works perfectly on iOS 26.0. When 'viewModel.showAudioMiniPlayer' is 'false', the accessory is completely hidden. However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' is 'false', the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar. Is this a known Bug in iOS 26.1 and are there any effective workarounds or should I just wait until Apple fixed it?

I've been beating my head against the wall over a scrollview issue where the top and bottom are cut off in landscape mode. Portrait mode - everything runs swimmingly. The moment I flip the iPad on its side, though, I lose about a quarter of the view on the top and bottom. I thought this was something to do with framing or such; I ran through a myriad of frame, padding, spacer, geometry...I set it static, I set it to dynamically grow, I even created algorithms to try to figure out how to set things to the individual device. Eventually, I separated the tablet and phone views as was suggested here and on the Apple dev forums. That's when I started playing around with the background image. Right now I have.... ZStack { Image("background") .resizable() .scaledToFill() .ignoresSafeArea() ScrollView { VStack(spacing: 24) {.... The problem is the "scaledToFill". In essence, whenever THAT is in the code, the vertical scrollview goes wonky in landscape mode. It, in essence, thinks that it has much more room at the top and the bottom because the background image has been extended at top and bottom to fill the wider screen of the iPad in landscape orientation. Is there any way to get around this issue? The desired behavior is pretty straightforward - the background image fills the entire background, no white bars or such, and the view scrolls against it.

I'm looking for a way to display a notification badge without showing a number—essentially, just an empty badge to indicate the presence of notifications. From my research, it seems like this functionality isn't available . Is there any workaround or method to achieve this?

I’m not a developer - I’m just trying to find out where to post a question I have that might relate to iOS 26.

With the new ios 26 beta 3 helps some stabillty and performance issues but most of the liquid glass has been removed or made very frosty look; and it defeats the whole purpose of a big redesign, and even thought the changes are because of readability and contrast complaints it should not take away liquid glass design. I think apple should consider adding a toggle or choice to choose if they would want a more frosted look or a more liquid glass look the the original plan.

Yesterday on Explore the biggest updates from WWDC Curt Clifton shared .background(.tint, in: .rect(corner: .containerConcentric)). XCode26 beta 3 don‘t recognize it. how when we can use it??

Please

The bane of my existence has been designing interfaces where the whole view needs to scroll, but a portion is a List and the other portion is static. I run into this problem time and again so I was hoping someone has a good solution because we all know that embedding a List view inside ScrollView is a no-go within SwiftUI. It simply doesn't work. So what is a best practice when you need the whole screen to scroll, but a portion is a List? Use a navigation stack instead of a ScrollView? What if it's a child view of a navigation stack already?

Ever since Xcode Version 26.0.1 I cannot for the life of me make my buttons rectangular. They are all capsule (or oval) shaped. My interface was designed for square buttons but no matter what I do the issue stays the same. This is what I have (it's fairly barebones but would have worked before I believe): @IBOutlet weak var PagesInterface: UIButton! override func viewDidLoad() { super.viewDidLoad() PagesInterface.layer.cornerRadius = 0 PagesInterface.layer.masksToBounds = true }

I’m developing an app that includes a navigation bar with a centered title and a single right bar button item. I’ve noticed that when both the navigation bar title and the right bar button item’s title are relatively long, the navigation bar title becomes hidden. This issue only occurs on iOS 26. When running the same code on iOS 18, the layout behaves as expected, with both elements visible. Has anyone else experienced this behavior on iOS 26? Is this a known layout change or a possible bug?

I would like to propose a design enhancement for future iPhone models: using the existing bottom-right antenna line (next to the power button area) as a capacitive “volume control zone” that supports swipe gestures. Today this line is a structural antenna break, but it is also located exactly where the thumb naturally rests when holding the phone in one hand. With a small embedded capacitive/force sensor, the user could slide their finger along this zone to control volume without reaching for the physical buttons. Why this makes sense: • Perfect ergonomic thumb position in both portrait and landscape • One-handed volume adjustment becomes easier for large-screen devices • Silent and frictionless vs. clicking buttons (useful in meetings / night mode) • Consistent with Apple’s recent move toward contextual hardware input (Action Button, Capture Button, Vision Pro gestures) The interaction model would be: • Swipe up → increase volume • Swipe down → decrease volume • (Optional) long-press haptic = mute toggle This could also enhance accessibility, especially for users with reduced hand mobility who struggle to press mechanical buttons on tall devices. Technically, this would be similar to the Capture Button (capacitive + pressure layers), but linear instead of pressure-based. It does not replace physical buttons, it complements them as a silent gesture-based alternative. Thank you for considering this as a future interaction refinement for iPhone hardware design.

I’m currently using the iOS 26 Developer Beta and noticed the new icon design for the Camera app. Personally, I preferred the previous icon it looked cleaner, more elegant, and felt more in line with Apple’s signature iOS design language. The new icon feels more like something you’d expect from Android. It lacks the minimalist, refined style that usually defines iOS icons. I understand UI evolves over time, but this change feels like a step away from what makes Apple’s design philosophy unique. Just wanted to share this honest feedback as a long-time user and developer. Thanks for considering!