Please

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.

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?

Hey there, I redesigned my apps icons for Liquid Glass in the icon composer app. I have to say it's been a pleasure to use and my icons look stunning when rendered in the icon composer app, whatever rendering mode and context I've been testing. But once in a developer release on my device (iOS 26 beta 3), the rendering is very disappointing. They look blurry, very far from what icon composer is showing. I would like to know whether I have a design issue, or if the current state of the beta release is known to not render icon properly. I'm kind of panicking :)

In the clock app when making an alarm for myself to wake up, I found this bug where If you swipe left On an alarm without deleting it and then Swipe right it does a goofy visual glitch where it teleports to the top of your screen.

I downloaded iOS 26 beta 3. I was very happy with how it turned out, but when I activated Siri, I noticed the rainbow pulsing glow that bordered the phone was missing, and all that was left was the original Siri bubble. I was very disappointed, does anyone know how to get this back? I loved that design feature.

Development environment: Simulator: iOS 26 beta 3 iPhone 16 (for testing) Simulator 2: iPadOS 26 beta 3 iPad Air 13 inch (M3) (for testing) Connected Device: iPadOS 26 beta 3 iPad Pro 11 inch (M4) (for testing) Dev Device: macOS Tahoe 26 beta 3 Macbook Air When using the NavigationSplitView element, the sidebar has a built-in panel toggle button. However, when I click the toggle button to toggle the sidebar section in SwiftUI 26 on both simulator 2 and the connected device, it has a slight animation glitch before going back to normal. What's going on? This is my code for the specific view that has the NavigationSplitView (and all views are connected through TabViews): RecordsPage.swift Here are image references: When I clicked the toggle: After 1~2 seconds: These images are in the state of the panel being hidden.

Hi, I was trying to use macOS-Sequoia-Production-Templates in Sketch format and when I try to export png icon file of the document template, it always includes grey nontransparent background which I am unable to delete. In contrast, exporting png app icon file from another template has transparent background and exports well. Is it something wrong with the document icon production template? How can I export document png icon file with transparent background?? Thanks

We all know that the feature “Always On Display” is available only on pro models. I checked in iPhone 14 Plus, that feature became visible in “Search” menu under “Settings”. If a user types “Displa”, then the search results show “Always On Display” as a result. When I click on that, it navigates inside “Display and Brightness” and we found no toggle for “Always On Display”. So, displaying the same on search result is a big bug which needs immediate attention from Apple. Users are getting confused whether iPhone 14 plus has that feature or not.. **Possible reason: ** I believe Apple releases iPhone OS versions in a single release each time and must be applying any kind of feature flagging to enable / disable a feature in a version or for a model. The feature flagging might not be working with Settings menu’s Search service or the code is not properly modular.

In the past, we had a red badge without a number on the app icon. We want to bring it back. Please provide instructions.

Hi everyone, I’m testing our SwiftUI app on both Xcode simulator and a real iPhone. On the simulator, everything looks clean and aligned. But when I run it on an actual iPhone (same build, iOS 18), the layout looks broken—fonts overlap, spacing is off, and elements are misaligned. Both screenshots are from the exact same screen and time. First is simulator, second is iPhone. Any idea why this difference happens? Is there something I should check in terms of rendering or layout settings? Thanks in advance!

Hello, I have used CPPointOfInterestTemplate for displaying data and as user scrolls using the up/down arrow, I do not see any change in the map. Is there a way to highlight the POIs as the user scrolls through the list? I need to use the map controls and zoom to check the markers on the map. Is it possible to set the zoom level of the map in CarPlay? Pls suggest on the above queries

[Iphone11]

Hi everyone 👋 I’ve been using the Apple Pencil Pro with my iPad Pro M4 and absolutely love it — the squeeze gesture, rotation, and haptics are amazing for creative work. But I’ve run into a little roadblock… Right now, only one Pencil Pro can be paired at a time. So while one is charging, you can’t use another as a backup without unpairing and re-pairing, which interrupts the workflow. I’d really love to see one of two things: The ability to use one Pencil while another charges or An official external charger (or support for third-party ones) Personally, I’d happily buy both a second Pencil and a charger if this became possible. I’ve even chatted with other creatives who feel the same — it would make a huge difference for long projects or working on the go. Just wanted to share this idea and see if anyone else here would like this too. Thanks for reading!

We're using StoreKit for in-app purchases on iOS, and our backend has the server notification URL configured. However, during subscription renewals, Apple's server doesn't send any requests to our endpoint. What could be causing this?

When we are going to have a real analog clock option on the lock screen. If an apple watch can do it surely its not that difficult. For someone who uses a clock to tell what time it isn't as opposed to what time it is, i’m constantly having to convert a digital image where the image of hands on a dial is so much easier. Surely this isnt because someone has forgotten how to read a clock

Hi community, I have a question regarding MusicKit, is it necessary to follow a design guideline to integrate this framework into my App? Also, when no music is reproducing in MusicKit which placeholder we should show, do you provide the resource? Or can we create our own placeholder? Thanks for all, David.

I couldn't help noticing that the Maps and Find My apps make extensive use of "sheets stacked on top of each other" to represent its navigation hierarchy, with a "new content comes in from the bottom" orientation instead of a navigation stack with "new content comes in from the right side" oriented transitions. I'm interested in this topic because I have a similar navigation-hierarchy-over-a-map case in my app (with a custom map view though) and I'm torn back and forth between the approach of replicating the "stacked sheets" vs. putting a navigation stack in a sheet, esp. with the navstack approach being way more attainable with the iOS 26 glass design. I couldn't find any guidance for this kind of UI in the Human Interface Guidelines; I'm leaning towards the navstack-approach for my app; but in terms of the behavior of the SwiftUI container views in this scenario it seems a little bit of an uphill path. Any thoughts on what pattern should be preferred for presenting a deep navigational hierarchy on top of a map-like view?

I recently submitted a new app for review, but it has been rejected multiple times for vague reasons. The most recent rejection reason I received was unclear, leaving me unsure of what improvements are needed to get the app approved for the App Store. Does anyone have any advice on how to address this? Additionally, to Apple reviewers: Could you please provide more detailed feedback to help developers improve their apps? The repeated review process takes a significant amount of time, and guessing what needs to be fixed without clear guidance makes it even more challenging. ################################# The latest rejection reason I got is: Guideline 4.0 - Design We noticed an issue in your app that contributes to a lower-quality user experience than App Store users expect: Your app included hard to read type or typography. Since App Store users expect apps to be simple, refined, and easy to use, we want to call your attention to this design issue so you can make the appropriate changes. Next Steps Please revise your app to address all instances of the issue identified above.

Feedback for iPhone and iPad – Display Technology Dear Apple Team, Currently, the mainstream display technology used in iPhone and iPad is OLED. However, OLED panels produce significant PWM flickering, which strongly irritates the human eye. Many users, especially in China, experience eye strain, tearing, and discomfort after using OLED devices for a period of time. There is a large group of users here who are highly sensitive to screen flicker and therefore cannot use OLED-based devices at all. What they truly need is an eye-friendly device with either LCD or flicker-free Mini-LED display technology. I sincerely recommend that Apple consider offering iPhone and iPad models with LCD or Mini-LED panels. Such displays could provide better eye comfort, no flicker, and a healthier experience. Currently, almost no smartphone manufacturers in China provide such options, and even if they do, their devices often come with outdated chipsets and cannot be used as a reliable daily driver. This presents a valuable opportunity for Apple: by addressing this demand, Apple could attract a unique customer base, increase sales, and even justify a slightly higher price, as many customers would be willing to pay more for the sake of their eye health. In the Chinese market, a truly flicker-free iPhone or iPad would be incredibly rare and highly desired. Thank you for considering this suggestion. I truly hope Apple will take this into account.