I'm currently in the WWDC26 Group Lab for Icon Composer and they will not allow questions about the newest features in Icon Composer and visionOS app icons. Why are visionOS app icons not supported? Why are they so different that this isn't possible? Are there any plans to include them? In an age where Apple is increasingly encouraging developers to create apps across multiple platforms (resizability), this becomes an even more reasonable question to ask. Why is this one platform not getting the love??

I just updated to tvOS 27 and I saw... nothing. It still uses the tvOS 26 icons and none of the Liquid Glass design changes the other platforms received are there (like the new outlines and depth of buttons). Even the highlights angle on the icons is still 45 degrees. Is this to be expected? Why is tvOS 27 the only platform that does not get these refinements? Not even updating the icons is sad...

For those who've spent some time with Icon Composer, what's the single feature, technique, or workflow trick that made the biggest difference in your icon design process? I'd love to hear real-world examples and lessons learned. Thanks!

Now that we are to move away from designing apps for specific devices and fixed orientations, and to instead target “a dynamic range of sizes and aspect ratios”, what does that mean for Apple Pay and CoreNFC flows? For layouts that show users where to tap the NFC tag device to the phone (approximate location where the NFC hardware is located in the phone), how should placement instructions be updated? For reference to all, here's Apple's design, that contains a dot cloud, showing the general tap area: https://www.apple.com/business/tap-to-pay-on-iphone/ Wondering if Apple could provide any updated examples (especially for CoreNFC)? Thanks for the help!

Hello Elon, Your WWDC26 Group Lab is almost here. Please review the details below to make sure you have a great experience. Accessibility Technologies Group Lab Tuesday, June 9, 2026 5:00 p.m. (Pacific Daylight Time) 60 minutes Conducted in English https://developer.apple.com/go/?id=wwdc26-accessibility-technologies-group-lab Learn more about Group Labs > If you’re unable to attend, please cancel your registration. If you have questions about your Group Lab, please contact us. We’re glad you’re spending part of WWDC26 with us. The Apple Developer Relations Team Copyright © 2026 Apple Inc. One Apple Park Way, MS 923-4DEV, Cupertino, CA 95014 All Rights Reserved | Privacy Policy | Account This is a service notification related to your Apple Developer account.

True mobile innovation isn't about doing more on your screen; it's about doing less to get the exact same result. I can justify the statement which i have written as a Headline by implementing these points. There are 5 interesting features that need to be added into the operating system by which all the apple users are benefited. These five features together are coined as a term "PEDDI". Personalization/Passion Easy of Access Gestures Duplication Optimization Deletion Instant Voice-Overs These five features enhances the user experience with the operating system. There is a lot that apple can provide by integrating these features into the system. Feel free to contact me for the detailed explanation regarding these features. Thanks, Young Aspirant.

This new battery icon in iOS 27 is discouraging and ugly. I wish the battery icon from iOS 26 and earlier would come back.

I’m building a Wallet pass that stores a customer’s proof of product ownership and digital receipts — used for circular-economy actions (recycling, returning, reselling, or gifting a product). There is no payment functionality involved; it’s purely a record/receipt store with an earned points balance. I’d like the pass to have the look and feel of a payment/bank card. My questions: 1. Is it possible to present a pass with a payment-card-style appearance through standard PassKit, without being a bank or Apple Pay payment issuer? 2. If that exact card surface is reserved for Apple Pay payment cards, is storeCard the closest supported style for a card that displays an earned balance? Are there any restrictions on using storeCard this way (i.e. a balance not tied to payments)? 3. Any policy or review considerations when a single pass represents both product ownership and a rewards balance? I want to build on the correct, supported pass style from the start rather than discover a constraint later. Thanks for any guidance.

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

I’m delighted with the introduction of new color folders. Although, I can’t help but wonder why we still need both color folders and tags. Aren’t the color folders sufficient for our needs?

It has been 6 days since we submitted our app for review, and the status is still showing “Waiting for Review,” even though the guidelines mention reviews are usually completed within 48 hours. We also contacted support but have not received any response yet. Has anyone else experienced similar delays recently? Any advice would be appreciated.

The MagSafe 3 cable is an amazing piece of engineering, showing charged as green and charging as amber. Please consider that "carging," being amber and "full" or "reached charging limit," is green, but for a high end company, you need to make the MagSafe wire more useful. A software MagSafe update, like macOS 26.5 was very noticeable for me, as i have the charging limit set on 80%. A new MagSafe 4 would be a simple MagSafe 3 update, creating MagSafe 4, introducing a yellow colour, to mimic macOS window controls. It is very simple, as both red and green diodes are already in MagSafe 3, light physics tells us that red+green=yellow. All we have to do is turn on both of those LED diodes, and we have yellow. MagSafe 4 should have the following: Amber:0%-50% Yellow:50%-90% Green: 90% + or reached charging limit Pulsing Amber: overheating or critical issue with power cut off Pulsing yellow: slow charger, under 30w for macbook air and under 70w for macbook pro. This should be very simple as its a few lines of code.

I’m building a visionOS app that starts with a regular 2D SwiftUI window. From that 2D window, the user can enter a volumetric mode, where I want to open a large volumetric WindowGroup and have it appear centered around the same spatial position as the original 2D window. The volumetric window is physically large, roughly over 1m × 1m × 30cm. Because of that, placement behavior is very noticeable. My intended behavior is: User is interacting with a regular 2D window. User taps a button. A large volumetric window opens. The volumetric window appears in front of the user, ideally centered on or near the original 2D window’s position. The original 2D window is dismissed or replaced. My current workaround is to call openWindow(id:) for the volumetric window, then dismiss the original 2D window. This works in the sense that the volume is created, but its initial position is noticeably offset from the original 2D window. I also tried using defaultWindowPlacement to control the placement of the volumetric window relative to the existing 2D window. I tested placements such as .below, .trailing, and other relative positions. However, because the volumetric window is large, the result is worse: when I open the volume from the 2D window, the volumetric window appears to move instantly far away from the user’s view, almost as if it flies out of the visible workspace. After that, I can no longer see or interact with the volume. Interestingly, if I then go back to the system Home View and tap the app icon again, the volumetric window appears normally in front of the user. Here is a simplified version of my setup: @main struct MyApp: App { var body: some Scene { WindowGroup(id: "main") { MainWindowView() } WindowGroup(id: "volume") { VolumeView() } .windowStyle(.volumetric) .defaultSize(width: 1.0, height: 1.0, depth: 0.3, in: .meters) // I also tried defaultWindowPlacement here, // using placements such as .below, .trailing, etc. } } struct MainWindowView: View { @Environment(.openWindow) private var openWindow @Environment(.dismissWindow) private var dismissWindow var body: some View { Button("Open Volume") { openWindow(id: "volume") dismissWindow(id: "main") } } } What I would like to know: Is there a supported way to open a large volumetric window from a 2D window while preserving or approximating the 2D window’s spatial center? Is defaultWindowPlacement expected to work reliably for large volumetric windows, or can relative placements such as .below or .trailing cause the volume to be placed outside the user’s comfortable visible area? Is there any API that exposes the current 2D window’s spatial position or center so I can place the volumetric window more precisely? Can pushWindow(id:) be used to replace a 2D window with a volumetric window while preserving placement, or is this transition not currently supported? Why would the same volumetric window appear far away when opened from the 2D window, but appear normally in front of the user when the app is reopened from the system Home View? What is the recommended UX or technical pattern for transitioning from a regular 2D window into a large volumetric window without the volume jumping or appearing outside the user’s view? I’m testing this on: visionOS version: [26.5] Xcode version: [26.4.1] Device or Simulator: [vision pro m2 & m5] SwiftUI app lifecycle Source scene: regular WindowGroup Destination scene: WindowGroup with .windowStyle(.volumetric) Approximate volume size: over 1m × 1m × 30cm Any guidance on the recommended placement strategy for large volumetric windows would be appreciated.

Hello everyone, My name is Keita Tomizu. I'm a university student in Japan, currently developing a personal app. I am facing a tricky SwiftUI layout issue that I have spent hours trying to solve, and I would really appreciate your insights. Context & Goal: I have an overlay UI layer (zIndex(4)) consisting of a VStack that contains top and bottom HStacks. • In the top-left, there is a back button (<). • In the top-right and bottom-right, there are action buttons. • When a user taps the bottom-right button, a state isShowingAddView becomes true. This brings up a keyboard and a custom view in the background. • My Goal: When isShowingAddView is true, the right-side buttons should scale up and fade out (opacity to 0) in place. The top-left < button should remain completely static and anchored in its exact position. The Issue: When the state toggles, the < button unexpectedly shifts horizontally (along the X-axis) and sometimes behaves erratically, moving off-screen or losing its static position. Also, the animations on the other buttons sometimes break or cancel abruptly. What I've tried: 1. I stopped using if !isShowingAddView to remove views, as I learned it causes the Spacer() to instantly expand and push the < button away. I am now using .opacity, .scaleEffect, and .allowsHitTesting instead. 2. I added .ignoresSafeArea(.keyboard) to the parent VStack to prevent the keyboard from pushing the UI up. Despite these changes, the < button still shifts horizontally during the state transition. Code Snippet: Here is the simplified structure of my overlay layer. (I have omitted the background layers for simplicity). Code: import SwiftUI struct ContentView: View { @State private var isShowingAddView: Bool = false var body: some View { ZStack { // Background layers and other views are here... // Overlay UI Layer VStack { HStack(alignment: .center) { // 1. The Back Button (<) - I want this to stay COMPLETELY fixed. Button(action: { if isShowingAddView { withAnimation(.spring(response: 0.4, dampingFraction: 0.8)) { isShowingAddView = false } } }) { Image(systemName: "chevron.left") .font(.system(size: 21, weight: .semibold)) .foregroundColor(.black) .frame(width: 44, height: 44) } .background(Color.white.opacity(0.5)) // Simplified glass effect .clipShape(Circle()) Spacer() // The spacer that might be causing the X-axis shift? // 2. The Right Buttons - These fade out and scale up. HStack(spacing: 0) { Image(systemName: "circle.hexagongrid.fill").frame(width: 44, height: 44) Spacer().frame(width: 13) Image(systemName: "magnifyingglass").frame(width: 44, height: 44) Spacer().frame(width: 10) Image(systemName: "ellipsis").frame(width: 44, height: 44) } .foregroundColor(.black) .padding(.horizontal, 2) .frame(height: 44) .background(Color.white.opacity(0.5)) .clipShape(Capsule()) // Animation modifiers .scaleEffect(isShowingAddView ? 1.15 : 1.0) .opacity(isShowingAddView ? 0.0 : 1.0) .allowsHitTesting(!isShowingAddView) .animation(.spring(response: 0.45, dampingFraction: 0.8), value: isShowingAddView) } .padding(.horizontal, 16) Spacer() // 3. The Bottom Right Button (Plus) HStack { Spacer() Button(action: { withAnimation(.spring(response: 0.45, dampingFraction: 0.8)) { isShowingAddView = true } }) { Image(systemName: "plus") .font(.system(size: 23, weight: .regular)) .foregroundColor(.black) .frame(width: 48, height: 48) } .background(Color.white.opacity(0.5)) .clipShape(Circle()) // Animation modifiers .scaleEffect(isShowingAddView ? 1.15 : 1.0) .opacity(isShowingAddView ? 0.0 : 1.0) .allowsHitTesting(!isShowingAddView) .animation(.spring(response: 0.45, dampingFraction: 0.8), value: isShowingAddView) } .padding(.horizontal, 28) .padding(.bottom, 16) } .zIndex(4) .ignoresSafeArea(.keyboard) } } } My Question: How can I completely anchor the < button so it is immune to layout shifts when its sibling views animate (scale/opacity) and when the keyboard appears? Is there a better layout strategy or a concept I am missing to isolate this button's position? Any advice, concepts, or solutions would be deeply appreciated. Thank you!

Some SF Symbols (wifi for example) render fine with the variable. But many, mostly ones with the circle being variable, do not seem to work. The SF Symbols app shows them rendering with a variable fine. But in code it doesn't work. Am I missing something or is there a reason? var body: some View { HStack { Image(systemName: "01.circle", variableValue: 0.5) Image(systemName: "figure.wave.circle", variableValue: 0.5) Image(systemName: "wifi", variableValue: 0.5) }.font(.largeTitle) } }

Hi there. I am a graphic designer and stuck with a stupid built in iOS problem. I enjoy creating background images for my lock screen and started to use typography in the designs, like quotes. I made the images in the exact pixel size my iPhone 16ProMax needs for full screen. In the photo app i can swipe through the images and they all fit precisely onto my screen. Now I want iOS to display those designs randomly on my lock screen. I create a new lock screen, choose „random“ and select the album in my camera roll. But as soon as those images are used as lock screens, they are randomly scaled and cropped without any visible logic behind it. Fun fact: When the images only show symmetrical shapes. they fit perfectly. As soon as type is on the JPG (or PNG) the scaling and repositioning starts. Any thoughts of how to get rid of this bug? The should be a simple button to deactivate random scaling. Or at least a „fit to screen“, as it won’t change anything if the images are made for the precise pixel size. Looking forward hearing your thoughts. Daniel

I upload one of my app on app store connect then I get Rejection there it gave me this message that guideline 4.8 design login services. how to solve this issue on app store Can you please guide me about it. This the message i receive from app store: The app uses a third-party login service, but does not appear to offer an equivalent login option with the following features: The login option limits data collection to the user’s name and email address. The login option allows users to keep their email address private as part of setting up their account. The login option does not collect interactions with the app for advertising purposes without consent. Next Steps Revise the app to offer an equivalent login option that meets all of the above requirements. If the app already includes a login option that meets the above requirements, reply to App Review in App Store Connect, identify which login option meets the requirements, and explain why it meets the requirements. Additionally, it would be appropriate to update the screenshots in the app's metadata to accurately reflect the revised app once another login service has been implemented.

The MagSafe 3 cable is an amazing piece of engineering, showing charged as green and charging as amber. Please consider that "carging," and "full" or "reached charging limit," is green, but in case you are far away, you need an estimate of battery percentage. A software magsafe update, like macOS 26.5 was very noticeable for me, as i have the charging limit set on 80%. A new MagSafe 4 would be a simple MagSafe 3 update, adding a yellow colour. it should be simple, here is the code: // 1. CRITICAL SAFETY CUT-OFF // If the system detects a hardware/thermal failure, // it cuts power and pulses RED. if (criticalError) { setLED(PULSING_RED); return; } // 2. SLOW CHARGER DETECTION // Logic: Air < 30W OR Pro < 70W triggers Pulsing Yellow. if ((isAir() && wattage < 30) || (isPro() && wattage < 70)) { setLED(PULSING_YELLOW); return; } // 3. CAPACITY GRADIENT // Simple, clear visual feedback based on your percentages. if (soc < 50) { setLED(COLOR_AMBER); // 0-50% } else if (soc >= 50 && soc < 90) { setLED(COLOR_YELLOW); // 50-90% } else if (soc >= 90) { setLED(COLOR_GREEN); // 90-100% }

In the video ”Create Icons with Icon Composer”, the presenter mentions that Apple has created a layer-to-SVG script for Illustrator that‘s available for download: Once the artwork is in a good place, next we want to export the layers as SVGs. For every tool, this can look a bit different. For those using Illustrator, we've created a layer to SVG script that will automate this for you, which you can download. Exporting out the canvas size ensures everything drops right into position in Icon Composer. Here‘s the link to the mention: https://developer.apple.com/videos/play/wwdc2025/361/?time=377 I can’t find any place to get this script, and my designer is very interested in using it to import our Illustrator icon into Icon Composer. Can someone point me to it?

Hey guys, I made a app that features push notificaions, and I keep having problems setting them up. It asks permissions, and then it says that it cannot get the APN token after 10 seconds, and I am positive that I have enabled Push Notificaions in the provisioning profile in Xcode. Can anyone help me fix this issue?