İOS 26 beta battery %1

I’m building a custom input field using UITextField. When the user taps to focus the field and the text is long, the entire text becomes selected by default. This is the same behavior you can see in iOS Safari’s search field or the Messages app search field. What I want: when the field becomes first responder, the caret should be placed at the end of the text (latest word), without selecting all the text. Here’s the code that builds my text field: public func makeTextField() -> UITextField { let textField = UITextField() textField.autocorrectionType = .no textField.setContentCompressionResistancePriority(.required, for: .horizontal) textField.setContentCompressionResistancePriority(.required, for: .vertical) if #available(iOS 13.0, *) { textField.smartInsertDeleteType = .no } textField.smartQuotesType = .no textField.smartDashesType = .no textField.autocapitalizationType = .none textField.contentMode = .scaleToFill if let font = attributes[.font] as? UIFont { textField.font = font } if le

My app has three main SwiftData models: Collection, SavedItem, and Extract. A Collection can contain subcollections (folders within folders) and SavedItems (files). Each SavedItem can have child Extracts. I'm preparing for the ability for users to be able to share Collections with each other. Currently, my architecture treats each Collection as the root of its own CloudKit zone (a root parent Collection and all of its items and subcollections live in 1 zone). This makes sharing and isolation straightforward, but it also means that moving a SavedItem or subcollection between Collections involves moving it across zones. I’m trying to figure out the best pattern for handling these cross-zone moves while keeping data integrity, relationships, and sharing intact. My understanding is that in CloudKit, and moving a record from Zone A to Zone B would require deleting it from Zone A and recreating it in Zone B - while somehow maintaining the link back to my local SwiftData store. Has anyone run into this or k

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgroun

Hi everyone, I’m posting this to ask for advice and see if anyone has experienced a similar issue with the Apple Developer Program subscription. On July 9th, 2025, I registered for the Apple Developer Program via the Apple Developer app on my iPhone using my main iCloud account (Apple ID). The expected annual fee was 2,299,000 VND (~$99). However, I just checked my billing history and saw that I was charged twice for the same subscription, both under the same Apple ID / iCloud account, on the same day. Key Details: I only enrolled once. Both charges are labeled “Apple Developer Program”, exactly the same amount (2,299,000 ₫). The payments were made through the App Store, not via the website. My account on developer.apple.com/account still shows “Enroll Now” — meaning I haven't been activated yet. I have not received any welcome email either. My questions: Is it possible to request a refund for one of the charges, since both payments came from the same iCloud account and clearly refer to the same subs

List { Text(ITEM 1) .onHover(perform: { hovering in debugPrint(hovering: , hovering) }) .help(ITEM 1) Text(ITEM 2) .onHover(perform: { hovering in debugPrint(hovering: , hovering) }) .help(ITEM 2) Text(ITEM 3) .onHover(perform: { hovering in debugPrint(hovering: , hovering) }) .help(ITEM 3) } .fixedSize(horizontal: false, vertical: true) .frame(maxHeight: 200) } Hello everyone!!! Considering the snippet above, seems like the onHover action, including help modifiers, doesn't work for the elements of a List, on macOS Tahoe. The situation changes using a ScrollView embedding a LazyVStack, or disabling Liquid Glass from the info plist, so my guess is that the new Liquid Glass style has something to do with this issue though I didn't find any clue about it. Does anyone have any idea? Maybe there's a layer above that doesn't allow to trigger the onHover modifier? Thanks in advance for your help!

An app that is capable of running on iPad can be usually run on Mac if properly designed and that's great. Recently I've tried to launch one of my old apps on macOS 26 in Designed for iPad mode and noticed that image picker behaves oddly. Images are barely selectable, you have to click several times and yet it might select image and might not. On iPhone and on iPad any kind of image picking works fine. I've tried all kinds of native pickers (PhotosPicker, PHPickerViewController, UIImagePickerController), but the result is almost the same. So how should I nowadays do image picking in (mostly) iOS app when it is run on macOS? Below is the most canonical and modern code I've tried. The issue is reproduced even with such bare minimum of code with the label not being put to a Form/List or any other factors. import SwiftUI import PhotosUI struct ContentView: View { @State private var selectedItem: PhotosPickerItem? @State private var selectedImage: UIImage? var body: some View { VStack {