At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for Design. Can you expand on how Liquid Glass helps with navigation and focus in the UI? Liquid Glass clarifies the navigation layer by introducing a single, floating pane that acts as the primary navigation area. Buttons within this pane seamlessly morph as you move between sections, and controls can temporarily lift into the glass surface. While avoiding excessive use of glass (like layering glass on glass), this approach simplifies navigation and strengthens the connection between menus, alerts, and the elements that trigger them. What should I do with customized bars that I might have in my app? Reconsider the content and behavior of customized bars. Evaluate whether you need all the buttons and whether a menu might be a better solution. Instead of relying on background colors or styling, express hierarchy through layout and grouping. This is a good opportunity to adopt the new design language and simplify your interface. What are scroll edge effects, and what options do we have for them? Scroll edge effects enhance legibility in controls by lifting interactive elements and separating them from the background. There are two types: a soft edge effect (a subtle blur) and a hard edge effect (a more defined boundary for high-legibility areas like column sorting). Scroll edge effects are designed to work seamlessly with Liquid Glass, allowing content to feel expansive while ensuring controls and titles remain legible. How can we ensure or improve accessibility using Liquid Glass? Legibility is a priority, and refinements are ongoing throughout the betas. Liquid Glass adapts well to accessibility settings like Reduce Transparency, Increase Contrast, and Reduce Motion. There are two variants of glass: regular glass, designed to be legible by default, and clear glass, used in places like AVKit, which requires more care to ensure legibility. Use color contrast tools to ensure contrast ratios are met. The Human Interface Guidelines (HIG) are a living document offering best practices. The colors and materials pages are key resources. Do you have any recommendations for convincing designers concerned with consistency across Android and Web to use Liquid Glass? Start small and focus on high-utility controls that don't significantly impact brand experience. Native controls offer familiarity and predictability to users. Using the native controls makes sure your app feels at home on the device. Using native frameworks provides built-in accessibility support (dynamic type, reduce transparency, increase contrast). Native controls come with built-in behaviors and interactions. Can ScrollViews include Liquid Glass within them? You can technically put a glass layer inside a scroll view, but it can feel heavy and doesn't align with the system's intention for Liquid Glass to serve as a fixed layer. Think of the content layer as the scrolling layer, and the navigational layer as the one using Liquid Glass. If there is glass on the content layer it will collide into the navigational layer. What core design philosophy guided the direction of iOS 26, beyond the goal of unification? The core design philosophy involved blurring the line between hardware and software, separating UI and navigation elements from content, making apps adaptable across window sizes, and combining playfulness with sophistication. It was about making the UI feel at home on rounded screens. Can we layer Liquid Glass elements on top of each other? Avoid layering Liquid Glass elements directly on top of each other, as it creates unnecessary visual complexity. The system will automatically convert nested glass elements to a vibrant fill style. Use vibrant fills and labels to show control shapes and ensure legibility. Opaque grays should be avoided in favor of vibrant colors, which will multiply with the backgrounds correctly. What will happen to apps that use custom components? Should they be adapted to the new design within the next year? The more native components you use, the more things happen for free. Standard components will be upgraded automatically. Look out for any customizations that might clash. Think about what is the minimum viable change, where your app still feels and looks very similar to what it did. Prioritize changes in core workflows and navigational areas. There are a number of benefits to using native components including user familiarity, built-in accessibility support, and built-in behaviors and interactions. Will Apple be releasing Figma design templates? Sketch kits were published on Monday and can be referenced. The goal is to ensure the resources are well-organized, well-named, and easy to use. It's a high priority.

Deleted items can not be recovered. With thechanges in menu options, recover option for recently Deleted items is no longer available, or not discoverable. If anyone found it let me know.

We build apps at Appther, and our sleep and anxiety app DeepRest had a stubborn onboarding problem. Users installed, opened it once, and a big chunk never reached the core experience. We rewrote the flow three times before it clicked. Sharing what actually moved the needle, in case it saves someone else the loops. What did not work first: We front-loaded everything. Account creation, notification permission, and a long value-pitch carousel all before the user touched anything real. Every gate was a place to quit, and people quit. What finally worked: We let people reach value before asking for anything. No sign-in wall on launch. They could try a core session first, then create an account only when they wanted to save progress. Drop-off fell sharply at that one change alone. We primed permissions instead of demanding them. Before the system notification prompt, we showed a plain screen explaining why reminders help sleep consistency. The soft ask before the hard ask lifted our opt-in rate a lot. We cut steps and measured each screen separately. Instead of a funnel-wide number, we tracked drop-off per screen. That exposed exactly which two screens were bleeding users, which we would never have seen from the overall rate. We deferred everything non-essential. Profile setup, preferences, and personalisation moved to after first value, not before it. The lesson for us was simple. Onboarding is not where you explain your app. It is where you get the user to one real win as fast as possible, then earn the right to ask for more. Happy to go deeper on the SwiftUI side of any of this if useful. appther.com/contact-us

I would like to see the old design of the battery indicator panel (top right) that was in ios 18-26. Right now, this one, which is currently available in iOS 27, looks too boring. I also mean the Home panel (bottom bar). It could be switched. So that you can keep it on all the time. (In iOS 26, it disappears after a couple of seconds) In my opinion, it betrays its sophistication, and I liked it when constantly displayed. Fight overheating when performing simple tasks, it also eats up your phone, which is not a good thing.

On iPhone SE (3rd generation), several system UI elements use corner radii that appear much more rounded than the physical display corners. This creates an inconsistent visual appearance across the system. Examples include: Markup menu Home Screen context menu Customize sheet Apple Maps bottom sheet Find My interface Safari address bar Suggestion: Please adjust the corner radius for devices with displays such as iPhone SE (3rd generation), so that system UI better matches the physical display shape and provides a more consistent visual design.

I would like to suggest adding a third Home Screen app icon size option that separates icon size from the option to remove app names. After using the current Home Screen customization options, I noticed that removing app names creates a much cleaner and more minimal look, but it also automatically increases the size of the app icons. While some users may prefer the larger icons, I personally prefer the regular icon size because it feels more balanced and organized. I discussed this idea with my friends and family, and we all agreed that we like the clean look of having no app names while still wanting to keep the original regular app icon size and compensating for the space of the name's of these apps being gone. My suggestion is to add a third option: Regular icons with app names (current default) Regular icons without app names (new option) Large icons without app names (current option) This would allow users to create a cleaner, more customizable Home Screen without forcing the app icons to become larger when removing app names. To help visualize this idea, I have also created some design mockups of what this option could look like. I hope these concepts help demonstrate how this feature could fit naturally into the existing Home Screen customization options. Adding this option would give users more control over their Home Screen design while maintaining the simplicity and attention to detail that Apple is known for. A small change like this could make the experience feel more personalized for many users.

Hi everyone, I'm developing a simple iOS app that solves quadratic equations using SwiftUI. I've attached a screenshot of the current interface. I'd appreciate feedback on the UI and user experience, especially from the perspective of Apple's Human Interface Guidelines. Thanks!

"I need an iOS meditation timer where the screen dims naturally but bells play at scheduled intervals when the screen is locked. AVAudioSession .playback prevents dimming. Without it, bells don't play when locked. How do apps like Plum Village achieve both simultaneously?"

I have submitted my in app subscription several times. It keeps getting rejected. The rejection is: “Issue Description The In-App Purchase products in the app exhibited one or more bugs which create a poor user experience. Specifically, We received an error message upon trying to load subscription. Review the details and resources below to troubleshoot this issue. Review device details: Device type: iPad Air 11-inch (M3) OS version: iPadOS 26.5.2 Next Steps Apple reviews In-App Purchase products in the sandbox and the In-App Purchase products do not need prior approval to function in review. Review the product configurations, complete any missing information, and test them in the sandbox. To offer In-App Purchases in the app, implement the StoreKit framework and the Account Holder must also accept the Paid Apps Agreement in the Business section of App Store Connect. Confirm you have a Paid Apps Agreement in effect. If you still need assistance after completing the steps and reviewing the resources, visit the Apple Developer Forums. If you can’t find an answer from an existing thread, start a new thread with your question to get guidance from Apple engineers and other developers.” app purchases work in my sandbox. will someone help me with a detailed step by step process to add in app purchases and subscriptions? I feel like the fix is beyond the code or app submission information.

Hello dear friends, I created the application from scratch, but Apple writes to me to do it as a mistake, please tell me 😭😭😭 Guideline 4.3(a) - Design - Spam We noticed your app shares a similar binary, metadata, and/or concept as apps previously submitted by a terminated Apple Developer Program account. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review your app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in App Review Guideline 4.3(a).

What is the recommended architecture for a native iPadOS application that automatically creates an interactive external workspace on a connected display while preserving pointer interaction and allowing custom layouts?

Feedback for iOS 27 Public Beta First of all, thank you for the incredible work on iOS 27. The new design, animations, and overall performance are excellent. On my iPhone, the first Public Beta has been very stable, and I truly appreciate the direction Apple is taking. I would like to share two suggestions that I believe would improve the user experience. 1. Please bring back "Slide to Answer" on the Lock Screen The classic "Slide to Answer" interface has been an iconic part of the iPhone experience for many years. It is instantly recognizable, helps prevent accidental call acceptance, and makes the iPhone feel unique compared to other smartphones. The new Accept and Decline buttons work well, but they make the incoming call screen feel less distinctive. Please consider either: Bringing back the classic "Slide to Answer" interface, or Adding a setting that allows users to choose between Slide to Answer and the new Accept/Decline buttons. Giving users the freedom to choose would satisfy both longtime iPhone users and those who prefer the new design. 2. More customization for the new iOS 27 wallpapers The new iOS 27 wallpapers look beautiful, especially the new visual effects. However, I noticed that when using the new iOS 27 wallpapers, the four Lock Screen shortcuts can only be placed at the bottom of the screen. On previous wallpapers, these shortcuts could also be positioned near the top, offering much greater flexibility. In addition, the beautiful Glass effect is currently available for the clock but cannot be applied to the date and calendar information above it. It would create a much more consistent and elegant appearance if the Glass effect could also be applied to these elements. I would love to see: Full placement flexibility for Lock Screen shortcuts with the new wallpapers. The ability to apply the Glass effect to the date, widgets, and calendar information, not just the clock. Thank you for listening to user feedback and for continuously improving iOS. I am looking forward to seeing how iOS 27 evolves throughout the beta program.

Hello Everyone, I am a student from India who is passionate about technology, coding, and design. I would like to propose a precise hardware and software design enhancement regarding the "LED Flash for Alerts" feature on the iPhone. Current Limitation: The existing feature utilizes the main camera flash/torch. While functional, it is incredibly bright and harsh, causing visual discomfort in dark rooms, study spaces, or classrooms. My Specific Idea: Instead of using the blinding main flash, Apple could integrate a subtle, soft white LED indicator directly inside or underneath the small black circle element located on the camera module (the sensor/microphone area). When a notification or call arrives, this exact black circle should softly pulse or glow with a clean, ambient white light. Benefits: Precision & Aesthetics: It utilizes an existing design element to create a beautiful, minimalist, and non-disruptive visual alert. User Experience: It provides a soft indicator that doesn't blind the user or disturb others in low-light environments. Power Efficiency: Illuminating a tiny dedicated ring/circle consumes significantly less battery than firing the main camera torch. As a student, I believe this subtle refinement would make the iPhone experience feel even more premium and thought-out. I would love to hear what Apple engineers and the developer community think about this!

Hello, I'm building an app that is designed to largely mimick Apple's own audio auto-switch behavior when switching between different audio output devices like MacBook Pro speakers and AirPods. The purpose is to "lend a hand" to certain apps, like CrossOver (wine) ran x68-64 apps that don't seem to respond well to CoreAudio changing the audio output after the x68-64 program has already init its audio after startup. Thus, I don't actually need much of a GUI except for a few specific features, and perhaps later some ehancements I'd like to add that can make use of a proper GUI. I've decided to implement the MacOS Tahoe Apple Liquid Glass UI to keep the user experience as streamlined and intuitive as possible. I've largely been successful: The GitHub page goes into greater detail showing the greater context of the AppKit API's I'm using to achieve this UI design. There is just one issue I haven't been able to solve, how to get the sidebar tab(s) to blur when scrolled underneath the Window Controls (Traffic Light) buttons. These tabs are part of a NSScrollView underneath the NSToolbar aligned from the top-most left and right window edges, but split from the right-hand content side via NSSplitViewController > NSSplitViewItem (again exact topology is at the page "link" below). On the content side (right side), I used NSSplitViewItemAccessoryViewController to create the blur zone so that when its own NSScrollView content is scrolled upwards, past the toolbar NSToolbar, it would apply a progressive tint+blur effect, just as Apple has implemented in their own apps. This wasn't really automatic since I did have to elect to use it as part of a MacOS 26.1+ specific class (NSScrollEdgeEffectStyle), but it's working on the content side nonetheless: Now I am trying to get the same effect working on the sidebar side and am having issues with this. Please see the page below as it summarizes our test attempts with greater detail. I've only gotten this far by reading "obscure" comments in the SDK's so I'm really hoping this is just a ID10T error in that I've missed something. Note: even though I only have 3 tabs currently in the sidebar NSScrollView, I will eventually populate this further, especially with some user configurable stuff on my roadmap. That said, the sidebar is only "scrollable" right now because I've left the "vertical scroll elasticity" enabled, intentionally. (.verticalScrollElasticity [IS NOT] .none! Therefore, I can still "scroll" the enumerated tabs inside the sidebar's NSScrollView upward behind the Traffic Light buttons, to validate if the blur+tint effect is being rendered. I say all of that to ask if, perhaps, the reason that the blur+tint effect is not rendering in the Window could be because there's not enough content to render in the sidebar to produce a scrollbar, and simply leaving .verticalScrollElasticity "enabled" is not sufficient to produce this effect? I don't know that for sure, but it's the only thing I can think of at this point. Its not obvious to me though. This app is written entirely in Swift (v6.3.3) and will require a minimum of MacOS Tahoe 26.1.X due to the AppKit API's I'm using (namely NSScrollEdgeEffectStyle). GitHub Page documenting issue in greater detail (remove the spaces): HT TP S:// gitdev.brianbutts.me /sidebar-scroll-edge-blur. html

Hello Apple Developer Community, I’ve got a question. I would like to design my web app with the website for my project. I’m currently developing my iOS App and I would like to make a web version too. I would love to use the Apple SF Symbols for my Design as they’re clean and would have the same design as in my iOS App. Am I allowed to integrate them into my website or is it against the ToS of the Apple Developer Program? Have a nice weekend and a happy 4. July 😁 PS: Sorry if I selected the wrong category

Apple is currently missing a some Unicode writing systems not displaying on iOS, Apple needs to add new unicode scripts and extensions iOS 28 and iOS 29 Requested New Writing Systems Vithkuqi Todhri Sidetic Garay Old Sogdian Sogdian Old Uyghur Chorasmian Elymaic Tulu-Tigalari Dogra Dives Akuru Nandinagari Zanabazar Square Soyombo Sunuwar Tolong Siki Makasar Kawi Cypro-Minoan Anatolian Hieroglyphs Gurung Khema Tangsa Kirat Rai Medefaidrin Beria Erfe Nushu Toto Ol Onal Tai Yo Requested Extended Noto Scripts Balinese (Unicode 14.0 and 16.0) Kharosthi (Unicode 11.0) Kaithi (Unicode 11.0 and 14.0) Chakma (Unicode 13.0) Sharada (Unicode 13.0 and 17.0) Khojki (Unicode 15.0) Newa (Unicode 13.0) Takri (Unicode 14.0) Ahom (Unicode 14.0) Lisu (Unicode 13.0) Requested Extended Non-Noto Scripts Armenian (Unicode 11.0) Hebrew (Unicode 13.0) Arabic (Some Characters) Telugu (Unicode 17.0) Kannada (Unicode 15.0 and Unicode 17.0) Sinhala (Unicode 7.0 and 13.0) Lao (Unicode 6.1, 12.0 and 15.0) Devanagari (Unicode 5.2, 8.0 and 15.0) Requested Unicode Symbols Dingbats (Unicode 6.0) Miscellaneous Symbols and Arrows (Rest Encoded) Symbols for Legacy Computing Supplement (macOS only for now for Unicode 16.0) Miscellaneous Symbols and Pictographs (7.0 Dingbat Circles) (Webdings Icons macOS only) Ornamental Dingbats (All) Transport and Map Symbols (Webdings macOS only) Alchemical Symbols (Unicode 15.0) Geometric Shapes Extended (Unicode 7.0, 11.0 and 15.0) Chess Symbols (Normal and Rotated Chess Symbols Only from Unicode 12.0) Symbols for Legacy Computing (macOS only for now)

What is the best way to represent (in-app) or via App Store screenshots integration with native apps like Notes, Files, Photos? From a design perspective is it better to just use the app icon and say "integrated with... " subtitle or is there specific guidance from Apple on how to do this. A use case within my app is during onboarding I'd like to show that my app can be accessed via Control Center from any app like Notes, Photos, or Action Button. Thank you.

Emoji are very convenient to be used instead of image, directly as String. In some cases, a variation to show them rotated (but still as String, not converted as image) would be useful. Examples may be arrows or flags if you need to show them floating from the top and not from the side of the pole. And I would declare: flag = "🇺🇸" or So the question; is it possible to generate new emoji as rotated initial emojis ? Or better, do such extensions already exist.

Hello Everyone, I am a student from India who is passionate about technology, coding, and design. I would like to propose a precise hardware and software design enhancement regarding the "LED Flash for Alerts" feature on the iPhone. Current Limitation: The existing feature utilizes the main camera flash/torch. While functional, it is incredibly bright and harsh, causing visual discomfort in dark rooms, study spaces, or classrooms. My Specific Idea: Instead of using the blinding main flash, Apple could integrate a subtle, soft white LED indicator directly inside or underneath the small black circle element located on the camera module (the sensor/microphone area). When a notification or call arrives, this exact black circle should softly pulse or glow with a clean, ambient white light. Benefits: Precision & Aesthetics: It utilizes an existing design element to create a beautiful, minimalist, and non-disruptive visual alert. User Experience: It provides a soft indicator that doesn't blind the user or disturb others in low-light environments. Power Efficiency: Illuminating a tiny dedicated ring/circle consumes significantly less battery than firing the main camera torch. As a student, I believe this subtle refinement would make the iPhone experience feel even more premium and thought-out. I would love to hear what Apple engineers and the developer community think about this!

I noticed in the PNG export of my icon in icon composer that there is a border around a layer of my icon. This doesn’t show up in the in app preview, but only when exported. My icon composer file is here: https://github.com/user-attachments/files/28973433/rootshell.27.zip This is the 1024@2x exported image https://private-user-images.githubusercontent.com/65378120/608158382-7b2a8e59-9822-465b-95d0-1dc624d6a617.png

Dear Apple, It looks likes Apple like my new idea, and a lot. I know this as Apple always want their things to be easily understandable, and for MagSafe to be understandable it has to mimic macOS. I got an unreliable reply for the first post, just a person telling me I’m in the wrong place for this. The MagSafe is amazing, but everything needs to be upgraded in some way or the other, DTS engineers are saying that developer forums are for developing, not feedback. So here I am, developing the MagSafe wire, as I would by now rather get a third-party MagSafe wire if mine possibly breaks. $49. This is the price tag for an official MagSafe wire. If it can’t show anything but charging and charged, it’s something that must be reproduced. We have the hardware, we have the red and green diodes in the MagSafe, we just need to turn both of them on to make yellow. We have the hardware, and physics is helping us by saying: “Red + green light = yellow light.” This isn’t as complicated as π, so please implement it and let over 100 million users feel that MagSafe is finally worth the price. It is extremely simple, no new tests, no new safety certifications, just a new code you can forget about once released. To make things as easy as possible, here is the code, you can inspect it and test it, it should be OK. (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) #include <stdbool.h> #include <stdint.h> typedef enum { MODEL_AIR, MODEL_PRO } MacModel; typedef enum { LED_OFF, LED_SOLID_AMBER, LED_SOLID_YELLOW, LED_SOLID_GREEN, LED_PULSING_AMBER, LED_PULSING_YELLOW } LEDState; uint32_t current_cycle_seconds = 0; MacModel get_mac_model(void); uint8_t get_battery_soc(void); uint8_t get_charge_limit(void); uint32_t get_charger_wattage(void); bool check_hardware_faults(void); void apply_led_hardware_state(LEDState state, bool pin_high); void update_magsafe_led(void) { MacModel model = get_mac_model(); uint8_t soc = get_battery_soc(); uint8_t limit = get_charge_limit(); uint32_t wattage = get_charger_wattage(); bool overcharge_fault = (soc > (limit + 2)); bool critical_error = check_hardware_faults() || overcharge_fault; bool slow_charger = false; if (model == MODEL_AIR && wattage < 30) { slow_charger = true; } else if (model == MODEL_PRO && wattage < 70) { slow_charger = true; } LEDState normal_state; if (soc >= 90 || soc >= limit) { normal_state = LED_SOLID_GREEN; } else if (soc >= 50) { normal_state = LED_SOLID_YELLOW; } else { normal_state = LED_SOLID_AMBER; } LEDState active_state = normal_state; bool should_pulse = false; if (current_cycle_seconds < 10) { if (critical_error) { active_state = LED_PULSING_AMBER; should_pulse = true; } else if (slow_charger) { active_state = LED_PULSING_YELLOW; should_pulse = true; } } bool led_pin_high = true; if (should_pulse) { if (current_cycle_seconds % 2 != 0) { led_pin_high = false; } } apply_led_hardware_state(active_state, led_pin_high); current_cycle_seconds++; if (current_cycle_seconds >= 20) { current_cycle_seconds = 0; } } (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) This should show: Pulsing Amber for critical issues Pulsing yellow for slow chargers, under 30w for Macbook air and if under 70w for Macbook pro. Pulses for 10 seconds, and shows the light of the battery percentage for 10 seconds. Amber: 0-50% battery Yellow: 50-90% battery Green: 90%+ battery or reached charging limit. Please consider this code, I prefer a reply if possible to keep track of the new MagSafe update. macOS is amazing, but there are always final touches to be added, and if the hardware can be as similar as possible to the software, this is what brings understanding the battery alive, and apple has always wanted macOS to be as understandable as possible, why not the wire as well? If you need any extra information for the MagSafe, feel free to reply to me on the forum, I will try replying as soon as possible. Let the MagSafe glow. Let it show a yellow. It’s WWDC, and here I am right here. Let 2026 be the year where MagSafe is the most understandable yet, and let the yellow color come alive to MagSafe. Please consider it another chance to get a fresh, serious and realistic start to this. I am more than ready to mark the other post as answered if I get a realistic, understandable and useful reply to this. I apologize if my previous responses weren't very useful; I am not a formally trained engineer, but I wanted to show my idea the best way I could. May I please get a proper reply? Im extremely sorry for my previous replies that lost me reputation, but I promise I won’t reply to other posts from now on. May I please get a proper reply? May my idea get supported? May MagSafe feel as good as the magnetic “snap”? Please keep in mind that im in developer forums to develop the MagSafe wire, and as the DTS engineer stated in their reply: “ These forums are for questions about developing software and accessories for Apple platforms. If this is the case then feel free to provide more information,” In this thread here. There I am. Developing an accessory. MagSafe. I have been using macOS for about a year now, I noticed this flaw since a long time, and here I am, getting it out and loud to Apple in WWDC. Please do not count this as spam, or a repost of my original idea, I am conscious of what im currently doing, so please give this a good read and a caring, useful reply. I really hope you consider this and make MagSafe stand out, alongside the MacBook Neo. It was amazing. Unstoppable. But why not the MagSafe be as well? All the best, Alyaman