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 created a data structure based on a dictionary of words. The purpose is to link each word to all other words made up of the same letters plus one. Example: table -> ablate, cablet, tabled, gablet, albeit, albite, etc. For this I built a data model made of three entities: Word, Draw, Link. A Draw is a set of letters corresponding to a Word and sorted in alphabetic order, like : HOUSE -> EHOSU. A Link is a letter that you add to a Draw to get another Draw. So my data model looks like this: And here is how I implemented it in Xcode: Entity Word (let's forget the attribute optComp that plays no role here) Entity Draw Entity Link I am populating the data in two steps: first I read a list of words from a .txt source and I populate the Word entity and at the same time the Draw entity with the corresponding relationship (function loadDic()) This first step apparently works fine. I can easily find all anagrams of any word with something like word.sort.word.spelling I read through the Draw entity. For each draw I seek all existing +1 draws considering each letter of the alphabet. If there are, I create a Link and add the relationships (function createLinks()) Here is where something goes wrong. If the Link's and the relationship Draw.plus seem to be correctly created, the other relationship Link.gives is only partially populated, say 50%. Moreover, I tried to apply an additional routine (updateLinks()) , focusing only on Link's with an empty Link.gives relationship and updating them. But again, only 50% of the nil relationships appear to be populated. I could not find out why those relationships are not properly populated. If someone can help me out I would be grateful. Here is the code: LoadDic() function (OK) : func loadDic() { print("Loading dictionary...") dataAlreadyLoaded.toggle() guard let url = Bundle.main.url(forResource: INPUT_FILE, withExtension: "txt") else { fatalError("\(INPUT_FILE).txt not found") } if let dico = try? String(contentsOf: url, encoding: String.Encoding.utf8 ) { let lines = dico.split(separator: "\r\n") for line in lines { let lineArray = line.split(separator: " ") print("\(lineArray[0])") // word let wordSorted = String(lineArray[0].sorted()) let draw = getDraw(drawLetters: wordSorted) ?? addDraw(drawLetters: wordSorted) // look if draw already exists, otherwise create new one. let wordItem = Word(context: viewContext) // create word entry with to-one-relationship to draw wordItem.spelling = String(lineArray[0]) wordItem.optComp = (Int(String(lineArray[1])) == 1) wordItem.sort = draw do { try viewContext.save() } catch { print("Errort saving ods9: \(error)") } } } print("Ods Chargé") } func addDraw(drawLetters: String) -> Draw { let newDraw = Draw(context: viewContext) newDraw.draw = drawLetters return(newDraw) } func getDraw(drawLetters: String) -> Draw? { let request: NSFetchRequest<Draw> = Draw.fetchRequest() request.entity = Draw.entity() request.predicate = NSPredicate(format: "draw == %@", drawLetters) do { let drw = try viewContext.fetch(request) return drw.isEmpty ? nil : drw[0] } catch { print("Erreur recherche Tirage") return nil } } createLinks() function (NOK): func createLinks() { var erreur = " fetch request <Draw>" let request: NSFetchRequest<Draw> = Draw.fetchRequest() request.entity = Draw.entity() request.predicate = NSPredicate(value: true) print("Building relationships...") do { let draws = try viewContext.fetch(request) count = draws.count for draw in draws { print("\(count) - \(draw.draw!)") linkTable.removeAll() for letter in ALPHABET { print(letter) let drawLettersPlus = String((draw.draw! + String(letter)).sorted()) // draw with one more letter if let drawPlus = draws.first(where: { $0.draw == drawLettersPlus }) { // look for Draw entity that matches augmented draw let linkItem = Link(context: viewContext) // if found, create new link based on letter with relationship to augmented draw linkItem.letter = String(letter) linkItem.gives = drawPlus erreur = " saving \(draw.draw!) + \(letter)" try viewContext.save() linkTable.append(linkItem) // saves link to populate the one-to-many relationship of the initial draw, once the alphabet is through } } let drawUpdate = draw as NSManagedObject // populate the one-to-many relationship of the initial draw let linkSet = Set(linkTable) as NSSet drawUpdate.setValue(linkSet, forKey: "plus") erreur = " saving \(draw.draw!) links plus" try viewContext.save() count -= 1 // next draw } } catch { print("Error " + erreur) } print("Graph completed") } updateLinks function (NOK): func updateLinks() { var erreur = "fetch request <Link>" let request: NSFetchRequest<Link> = Link.fetchRequest() request.entity = Link.entity() print("Running patch...") do { request.predicate = NSPredicate(format: "gives == nil") let links = try viewContext.fetch(request) for link in links { let baseDraw = link.back!.draw! print("\(baseDraw) \(link.letter!)") let augmDrawLetters = String((baseDraw + link.letter!).sorted()) if let augmDraw = getDraw(drawLetters: augmDrawLetters) { viewContext.perform { let updateLink = link as NSManagedObject updateLink.setValue(augmDraw, forKey: "gives") erreur = " saving \(augmDraw.draw!) \(link.letter!)" do { try viewContext.save() } catch { print("Erreur mise à jour lien") } } } } } catch { print("Error " + erreur) } } RESULT And this is the output showing the content of the Draw entity with relationships after createLinks() is applied: And here after updateLinks() is applied :

Hello Apple Team, I’d like to request a feature that allows users to close all background apps at once on iPhones. Currently, closing each app individually can be time-consuming, especially when many are running. A “Close All” button would greatly improve user experience and efficiency. Thank you for considering this suggestion!

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.

Please

Hi, App Image: What is the best format - jpg, tiff, giff, psd or ai? What is the maximum and minimum number of items the app can contain? Please advise. Thanks

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?

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??

With iOS 26 the CPListSection header has a transparent background, and when the list scrolls under the header it doesn't look good at all. We expected to see a glass fading effect maybe, like the one on the top of the screen. Is it a known bug?

Hello Apple… used to love my phone and your company… not so much with this God awful new emoji update… Just why? They are giant, we can see them from Alaska, the whole Keyboard is not user friendly at all. It takes me (and reading the feedback from other people - Im not the only one with this problem) ages to find the one I want to use, even with the group icons on the bottom… no, they don’t help. I always ether miss type or just don’t use at all. It takes extra time to use emoji now so I completely stopped using it which sucks. It’s 2025 where time is precious and no one wants to spend extra seconds looking for emojis on this awful new layout you created. Apple developers used to be good about listing to users feedback, I hope you do it in this case, because this is just absolutely terrible and no, you can’t get used to it. I never write reviews anywhere and thought it would take a bit to get used to it… no no and no. This update is awful, please bring it back to normal size so we don’t waste our time and nerves. Thanks.

The most recent update included coloured icons for grouping of emails anybody previously needing to group emails we’re able to achieve this alphabetically by simply searching for what you were looking for. These icons clutter the page with totally unnecessary screen pollution. if you want to persist with this folly can you please provide a classic display option for those of us who have happily survived using email for 30 years without this fluff.

While the activityBackgroundTint modifier is intended to set the background color of a Live Activity, it often fails to dynamically update, leaving the activity with an incorrect background. Replacing it with ZStack { Color(.background) .... } solves the problem, but this is a workaround. The activityBackgroundTint modifier is still needed, at a minimum, so that the "Allow Live Activity for the app" extension does not have the default color.

As a very exclusive Apple only I want to share my thoughts on the new iOS 26 update, which I recently installed on my iPhone 16. While I genuinely appreciate Apple’s drive for innovation and personalization, this update introduces visual and stylistic changes that, in my opinion, compromise what has made iOS feel uniquely Apple for so long. Liquid Glass & Home Screen Aesthetics: When I first saw previews of the “Liquid Glass” design, I was excited. I assumed it would add more flexibility to things like the home screen customization — something like an optional effect that builds on the popular app tinting feature introduced in the previous iOS version. But instead, it appears that the Liquid Glass look is now the default and, more concerningly, unavoidable. The result is a visual experience that feels dramatically more bubbly and less refined. App icons appear more rounded and inflated in a way that — and I say this as constructively as I can — reminds me more of Android or Samsung’s One UI than of Apple’s signature design language. For someone who’s chosen Apple specifically because of its clean, crisp, and elegant UI, this shift is disappointing. iOS has always felt visually mature and thoughtfully minimal. With this update, it starts to feel overly stylized and visually heavy, which I don’t associate with Apple’s identity. Camera App – Icon Design: While I don’t have major concerns with the layout of the Camera app itself, the new Camera app icon is something I feel very strongly about. The previous design was balanced, clear, and professional — instantly recognizable. The new icon, is completely different, and it has more the camera that look like the actual iPhone camera, which I can respect the want to identify the app the iPhone. But this is not the effect I felt it has, I feel like it is less professional than before, which again makes me think a little bit about androids. This minor change feels bit because icons are what we see every day, and this one doesn’t feel quite right for Apple. Along with the new camera icon, the other new icons like the notes app, and the slight change in the message app icon, these small shifts aren’t ones I was overly pleased with, kind of felt like something that wasn’t broke and didn’t need fixed Messages App: The Messages app is where I felt the biggest disconnect. The updated keyboard with the “keys” looking more bubbly which again, makes me think android. And with the new monogram icons (initials in thick fonts with purple backgrounds), make the app feel — again — much more like an Android UI. While that might sound superficial, it doesn’t make me feel like it’s an iPhone. As someone who’s always preferred the Apple system, I’ve come to expect a particular standard of visual design — one that’s distinct from other platforms. This new look blurs that line. The once refined look of Messages is not as clean and simple as it used to be. I also preferred the gray background for monogram icons. The new colors and heavy fonts draw attention in ways that don’t feel as clean and simplistic which I have loved Apple for in the past. Control Center: Another area where I noticed a slight change is the Control Center. It’s not a big difference to the previous one, which I liked. The main difference I noticed was the brightness and sounds “bar” seems more elongated. Not a major difference but I would rather see the older design if I were to be honest. What I Did Like: There are some positives: I think the new lock screen notification styling works well, and the Liquid Glass effect looks great in that specific context. I actually really like the looks that it has with the notifications on the lock screen, having it be that transparent gives a clean and simple look. Lots of the new things that can be done in this update are very nice and convent, the more customization is great. Final Thoughts: To be clear, I offer this feedback not because I’m resisting change, but because I value what makes iOS feel like iOS. This update, while visually bold, feels like a departure from Apple’s strengths — the clean and simplistic look. If there’s one big takeaway I hope you’ll consider, some of the new looks that have been put in place give a feeling that’s not Apple, and more Android. it’s that many of these new visual styles would be better received as optional customizations, not system-wide defaults. I would love to see an update to help fix some of this. I don’t believe there is a way to “un-update” my phone but if I could I would, even though some of these new things do look and feel good.

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

I use swiftui to build apps on iPhone and iPad. There is no problem with the iPhone app. The game display is fully shown on iPhone. However, for the iPad, the game display is not shown and the screen goes black. I had to tap the button on the upper left side.(looks like a side view button) After that, the game display is only shown in the left side in a very small size. How can I make the game display fully shown in the iPad?

i am struggling to get my tab view to work, when i call views in the action part of my tab view, my background creates issue? does anyone know how to fix this? struct ContentView: View { @Environment(.colorScheme) var colorMode let Color1: Color = .cyan var Color2: Color { colorMode == .dark ? .black : .white } var TextColor: Color{ colorMode == .dark ? .black : .black } let tax: Double = 0.0875 var OptionTypes: [String] = ["Breakfeast", "Lunch", "Dinner", "Dessert", "Drinks"] var BreakfeastFoods: [Food] = [ Food(Name: "Eggs Benedict", Price: 9.50), Food(Name: "Avocado Toast", Price: 5.75), Food(Name: "French Toast", Price: 12.50), Food(Name: "Waffles", Price: 7.25), Food(Name: "Pancakes", Price: 8.60) ] var LunchFoods: [Food] = [ Food(Name: "Tuna Salad", Price: 11.25), Food(Name: "Pizza", Price: 22.50), Food(Name: "Chicken Sandwitch", Price: 8.95), Food(Name: "French Fries", Price: 5.15), Food(Name: "Macaroni and Cheese", Price: 7.50) ] var DinnerFoods: [Food] = [ Food(Name: "Ribeye Steak", Price: 18.99), Food(Name: "Pork Ribs", Price: 21.75), Food(Name: "Salmon", Price: 15.00), Food(Name: "Burrito Bowl", Price: 13.99), Food(Name: "Chicken Fajitas", Price: 20.50) ] var DessertFoods: [Food] = [ Food(Name: "Ice Cream Sundae", Price: 10.00), Food(Name: "Fudge Brownie", Price: 4.85), Food(Name: "Chocolate Cake Slice", Price: 6.10), Food(Name: "Pumpkin Pie", Price: 6.10), Food(Name: "Ice Cream Float", Price: 3.50) ] var Drinks: [Food] = [ Food(Name: "Water", Price: 0.00), Food(Name: "Sparkling Water", Price: 2.15), Food(Name: "Soda", Price: 3.00), Food(Name: "Coffee", Price: 2.50), Food(Name: "Hot Chocolate", Price: 3.50) ] @State var MyCart: [Food] = [] var body: some View { NavigationStack{ ZStack{ LinearGradient(colors: [Color1, Color2], startPoint: .top, endPoint: .bottom).ignoresSafeArea() VStack(spacing: 40){ ForEach(OptionTypes, id: \.self){ OptionType in NavigationLink(value: OptionType){ Text(OptionType) }.frame(width: 250, height: 70).background(LinearGradient(colors: [.cyan, .white,.cyan], startPoint: .topLeading, endPoint: .bottom)).foregroundStyle(TextColor).cornerRadius(100).font(.system(size: 25, weight: .medium)).padding(.top, 16) } }.navigationDestination(for: String.self) { OptionType in switch OptionType{ case "Breakfeast": BreakFeastView(BreakfeastList: BreakfeastFoods, Color1: Color1, Color2: Color2) case "Lunch": LunchView(LunchList: LunchFoods, Color1: Color1, Color2: Color2) case "Dinner": DinnerView(DinnerList: DinnerFoods, Color1: Color1, Color2: Color2) case "Dessert": DessertView(DessertList: DessertFoods, Color1: Color1, Color2: Color2) case "Drinks": DrinksView(DrinksList: Drinks, Color1: Color1, Color2: Color2) // case "My Cart": // MyCartView(MyCartList: MyCart, Color1: Color1, Color2: Color2) default: Text("Error") } } } .navigationTitle("Choose Menu") TabView{ Tab("Menu", systemImage: "fork.knife"){ } Tab("My-Cart", systemImage: "cart.fill"){ } Tab("Store Location", systemImage: "mappin"){ } } } } }

I am working on a Mac App that was developed with Objective C and Interface Builder. In earlier versions of Mac OS the window title was centered. Now in Tahoe it's left-justified. Is there some way to set this? There is no setting for this in Interface Builder and I can't see any way to do it programmatically by reading the developer documentation. Is this even possible?

Is there anyway I can customize Carplay template look like this

Hi, I want to generate some sample datas for demonstrating the functions of my app when the app launched. My codes are as followings: func generateSampleData() { let hasLaunchedKey = "HasLaunchedBefore" let defaults = UserDefaults.standard if !defaults.bool(forKey: hasLaunchedKey) { //generate the demo data } defaults.set(true, forKey: hasLaunchedKey) } And I put the func in a view's onAppear modifier. I found every time I go the view, it generates the demo data again, which results in producing a lot of demo data. But I have set the status of the function running in the userdefault. Why did it happen? Best Wishes,

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.