smb big sur

I've faced with some performance issues developing my readonly filesystem using fskit. For below screenshot: enumerateDirectory returns two hardcoded items, compiled with release config 3000 readdirsync are done from nodejs. macos 15.5 (24F74) I see that getdirentries syscall takes avg 121us. Because all other variables are minimised, it seems like it's fskit<->kernel overhead. This itself seems like a big number. I need to compare it with fuse though to be sure. But what fuse has and fskit seams don't (I checked every page in fskit docs) is kernel caching. Fuse supports: caching lookups (entry_timeout) negative lookups (entry_timeout) attributes (attr_timeout) readdir (via opendir cache_readdir and keep_cache) read and write ops but thats another topic. And afaik it works for both readonly and read-write file systems, because kernel can assume (if client is providing this) that cache is valid until kernel do write operations on corresponding inodes (create, setattr, write, etc). Questions are:

On iPhone, I would like to have a more button at the top right of the navigation bar, a search field in the bottom toolbar, and a plus button to the right of the search field. I've achieved this via the code below. But on iPad they should be in the navigation bar at the trailing edge from left to right: plus, more, search field. Just like the Shortcuts app, if there's not enough horizontal space, the search field should collapse into a button, and with even smaller space the search bar should become full-width under the navigation bar. Right now on iPad the search bar is full width under the navigation bar, more at top right, plus at bottom middle, no matter how big the window is. How can I achieve that? Any way to specify them for the system to more automatically do the right thing, or would I need to check specifically for iPhone vs iPad UIDevice to change the code? struct ContentView: View { @State private var searchText = var body: some View { NavigationStack { VStack { Text(Hello, world!) } .na

Code that reproduces the issue import SwiftUI @main struct KeyboardLayoutProblemApp: App { var body: some Scene { WindowGroup { iOSTabView() } } } struct iOSTabView: View { var body: some View { TabView { GameView() .frame(maxWidth: UIScreen.main.bounds.width, maxHeight: UIScreen.main.bounds.height) .tabItem { Label(Play, systemImage: gamecontroller.fill) } } } } struct GameView: View { var body: some View { VStack { Text(Play) Spacer() KeyboardView() } .padding() } } struct KeyboardView: View { let firstRowLetters = qwertyuiop.map { $0 } let secondRowLetters = asdfghjkl.map { $0 } let thirdRowLetters = zxcvbnm.map { $0 } var body: some View { VStack { HStack { ForEach(firstRowLetters, id: .self) { LetterKeyView(character: $0) } } HStack { ForEach(secondRowLetters, id: .self) { LetterKeyView(character: $0) } } HStack { ForEach(thirdRowLetters, id: .self) { LetterKeyView(character: $0) } } } .padding() } } struct LetterKeyView: View { let character: Character var width: CGFloat { height*0.8 } @ScaledMetric(rel

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.

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.

Hello, I am running into a bit of an issue with the Screen Timeout/Screen Lock setting and would like some clarification on. First for a bit of context, I am enrolling personal iOS devices 18.0+ into the company MDM (Intune) with Account Driven User Enrollment. We are trying to set a screen timeout of 5 minutes and immediately after it asks for the passcode on the device, though this setting is not being applied and the device timeout setting can be set as Never on the user's end. This is a big security risk for the company I work for and and the issue with being HIPAA compliant. According to the Microsoft Intune Support, In iOS 18, when using Account-Driven User Enrollment for BYOD (Bring Your Own Device) scenarios, the screen lock timeout setting is indeed marked as “Not Applicable”. This is because Apple’s privacy-preserving model for personal devices restricts administrative control over system-level settings like screen lock or idle timeout. I am needing clarification on the item mentioned from