In the most recent tvOS 27 betas, the icons for Apple’s apps on tvOS gained Liquid Glass refraction effects that change as you move your finger over the remote’s touch surface. This can be most clearly seen in the icons for Photos and Podcasts. How can our third-party apps make use of these effects on tvOS, which isn’t supported by Icon Composer? Is the intention for third party apps to continue using flat design while Apple’s own apps use Liquid Glass?

Hi guys, I've exported the images with transparency for a Vision OS icon but I still keep getting a weird shadow on the top of the icon when I focus on it. Do you guys had this issue before?

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.

Dear Apple, I am trying good to find things that can be upgraded, and trust me here, the MagSafe 4 (or keep its name MagSafe 3 if you want) will be truly amazing. Adding a yellow to mimic macOS window controls will be amazing, and exactly how apple want things to be, they want it to feel like 1 ecosystem, where everything is in sync together. I gave the code in the other post, and here it is again, please really take this in for macOS 27. I tried installing the beta on a separate APFS volume on my Mac, but since I have no other backup device, I decided to stop. I would love to send feedback through feedback assistant, but since im not running beta, I shouldn't really use it, so here I am. Here is some code to help with this: (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. ( can be edited in the future for the leaked MacBook ultra) 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. This will also be very useful if there is a slider to customize what range should be amber, yellow and green. Why? Turning MagSafe into a real dashboard that is more useful than charging or charged, will make it amazing, covering a bit of the price hikes the world is facing. Other than that, apple always wanted things to be as useful as possible. If MagSafe now has what I mentioned, from a glance from afar, people will know their SoC. Please take this in consideration, and I already appreciate the work done on it if it's being tested. I am pretty sure there will be high interest in the topic. Thanks to whoever is working to it, and hope it come alongside macOS 27. Another person suggested MagSafe turned green when reached charging limit, and it happened in macOS 26. May mine be considered too? Trust me, it will be worth it, making MagSafe from just a wire to a smart dashboard. I know apple care about this, and let MagSafe be an upgrade, covering the price hikes and shortages. Thank you very much, and im sure you will do it to make MagSafe the best charger ever. Many thanks, Alyaman

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 really appreciate the improved layout in the Clock app in Beta 5. The app now makes better use of the available screen space, allowing more information to be displayed without making the interface feel crowded. I would love to see this approach applied more consistently across iOS. Many system apps and UI elements still leave unnecessary empty space or show less information than the screen could comfortably accommodate. My suggestion is to optimize spacing, margins, and element sizes across the entire system so that iOS can make better use of the available display area while maintaining readability and accessibility. This would be especially beneficial on smaller-screen iPhones such as the iPhone SE and iPhone 12 mini and 13 mini, where every bit of available space matters. Feedback ID:24257909

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.

In the Pride wallpaper, the colors overlap with the scrolling points due to the small screen size of the iPhone SE 3 in iOS 26.6

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.

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

iOS 27 Beta 4: Native Liquid Glass UITabBar renders with opaque milky/frosted background while identical code renders correctly on iOS 26.5 Environment Xcode 27 Beta 4 iOS 27 Beta 4 UIKit UITabBarController Storyboard based application Native UITabBar (no custom tab bar implementation) Device: iPhone 17 Pro Simulator (also reproducible on other iPhone simulators) Problem After upgrading to iOS 27 Beta 4, the native Liquid Glass tab bar appears significantly more opaque (milky/frosted gray) than on iOS 26.5. The exact same application binary and configuration render correctly on iOS 26.5. No custom blur or visual effect is being applied. Current Configuration let appearance = UITabBarAppearance() appearance.configureWithDefaultBackground() appearance.backgroundColor = nil appearance.backgroundEffect = nil appearance.shadowColor = .clear tabBar.standardAppearance = appearance tabBar.scrollEdgeAppearance = appearance tabBar.isTranslucent = true tabBar.backgroundColor = nil tabBar.barTintColor = nil tabBar.backgroundImage = nil tabBar.shadowImage = nil Runtime Verification Verified at runtime: tabBar.backgroundColor == nil tabBar.barTintColor == nil tabBar.isTranslucent == true standardAppearance.backgroundColor == nil standardAppearance.backgroundEffect == nil scrollEdgeAppearance.backgroundColor == nil scrollEdgeAppearance.backgroundEffect == nil View Hierarchy The runtime hierarchy contains Apple's native Liquid Glass implementation: UITabBar _UIBarItemPlatterView _UILiquidLensView BackdropView ClearGlassView _UIPortalView _UITabSelectionView Therefore UIKit is using the Liquid Glass implementation rather than falling back to a legacy blur. Investigation Performed The following were tested without changing behavior: Removed all custom blur views Removed custom overlays Removed refresh/recomposition code Removed layout invalidation Removed transform hacks Removed PageMenu Replaced entire first tab with a plain UITableViewController Replaced DiscoverVC completely Replaced nested collection views Rebuilt a minimal demo project using identical UITabBarAppearance code The minimal demo renders correctly. The production application renders with a much more opaque gray background. Question Has anything changed in the Liquid Glass compositor or backdrop sampling behavior in iOS 27 Beta 4? Is there any new API or recommended configuration required to achieve the same transparency level as iOS 26.5? If this is expected behavior, is there any supported way to control the opacity of the system Liquid Glass material? Screenshots Attach: iOS 26.5 screenshot iOS 27 Beta 4 screenshot

Please add two appearance modes for Control Center: More Tinted: Stronger color tint with a vibrant look. More Glass: Increased transparency and a more pronounced Liquid Glass effect. This would give users more control over the visual style of Control Center while keeping the default appearance unchanged.

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.

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.