smb big sur

FYI, you also asked about APFS on this thread and I've moved you answer to that question on this thread. Is it bug or ATTR_VOL_SPACEUSED is unsupported on macOS 11? I don't know exactly why it was done, but I believe it was an intentional choice while the team was sorting out how APFS should present itself to the VFS system. ATTR_VOL_SPACEUSED is actually calculated in the VFS layer (you can see the code here if you're curious) and I suspect that at the time vs.f_bused wasn't giving a value that matched well with the expectation of the rest of the system. Disabling ATTR_VOL_SPACEUSED was the easiest way to prevent that from causing broader problems. That leads to here: Are there any other way to get space which is used on an APFS volume? (C++) So, the basic answer is what's the described in Checking Volume Storage Capacity. The more complicated answer starts with What are you actually trying to do?. The big issue here isn't simply that APFS is more complicated (which it definitely is), it's that part

[quote='783226021, billh04, /thread/783226, /profile/billh04'] How can you force cancel a task that … doesn't check for cancellation? [/quote] You can’t. [quote='783226021, billh04, /thread/783226, /profile/billh04'] would this be a useful addition to Swift? [/quote] Unlikely. You’re reasoning from a false premise here. All meaningful Swift functions require some sort of cleanup. The fact that this cleanup isn’t obvious is just the compiler hiding fiddly implementation details from you. A classic example of this is ARC, where you don’t have to worry about cleaning up because the compiler is emitting all the necessary retains and releases. Given that reality, there’s no way to stop code that doesn’t check for cancellation. Attempting to do that would leave the program in an undefined state. For example, a valid implementation of malloc would be: Lock a mutex that protects the memory allocator’s state. Manipulate that state to allocate the memory. Unlock the mutex. Return that pointer from step 2. If your task

If you haven’t already found it, please read An Apple Library Primer. But before we start talking about the dynamic linker, I want to chat about the big picture. You wrote: [quote='783167021, mettar, /thread/783167, /profile/mettar'] I have offered to help port a custom debug tool that revives a process from a core file. [/quote] What sort of fidelity are you looking for here? This is impractical in the general case because macOS leans heavily into Mach IPC. The vast bulk of system services aren’t provided by the kernel but are instead provided by daemons and agents via IPC. A process typically interacts with those via Mach IPC, and specifically XPC, and rebuilding those connections is pretty much impossible. So, if your OK with limiting this to Unix-y APIs then it might be worth continuing down this path. But if you want to get this working for apps, you should rethink your life choices )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + app

It's going to be a big challenge to port an existing project to SwiftUI. What you describe makes a lot of sense. Most people never encounter this error anymore because they are starting small, with a new project. That being said, you specifically said that you were porting a project over to iPhone. I don't think trying to do that kind of massive port from a foreign architecture is going to be any more pleasant in UIKit. I recommend starting small, with a new project. Build the bones of your UI to match the old project. But don't attempt to port the entire thing at once. Follow the path of least resistance and write the code the way SwiftUI or UIKit expects.

I think you're looking for something like this: import SwiftUI struct ContentView: View { var body: some View { ScrollView { VStack(spacing: 24) { ForEach(1..<20) { i in Text(Line (i)) } } } .frame(maxWidth: .infinity, maxHeight: .infinity) .background( Image(background) .resizable() .scaledToFill() .ignoresSafeArea() ) } } #Preview { ContentView() } The main difference is that my code adds a background to the ScrollView rather than putting everything on top of an image via a ZStack. When you do it your way, you've kind of told everything on top of that layer how big they'll be, which is why your ScrollView is distorted, and bits of it disappear off the screen.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks. System data is the System, i.e. iOS plus necessary files such as logs and cache files. That number will stay pretty static. There's not really a lot you can do to reduce that. Try and offload some of your data to iCloud. Enable iCloud Photos and turn on Optimise iPhone Storage in Settings > Apps > Photos. Regardless, you have a 64GB iPhone, which isn't that big these days. It might've been fine five years ago, but not really now.

Lots of people write apps that connect to their web servers. I think it's pretty unusual when an app doesn't do that. Internally, Apple is really old-school, big-iron corporate. I don't know specific details of specific products, but Apple's a big company, so there are lots of them. Generally speaking, if a 3rd party corporate networking/security app was a Big Deal 15 years ago, Apple probably still uses it today. Probably the two most important things to check are IPv6 and SSL. Make sure your app works in a purely IPv6 environment. Curiously, this policy is 9 years old now. Apple has a solid track record of announcing major changes 9 years before making a hard change. People who ignore those warnings because their app is working fine then get blindsided years later. Also, Apple can be very strict about SSL certificates for its own use. It really doesn't matter if your website works great in Chrome. It might not work from an Apple app or from an Apple internal network. People who ro

I’m not sure what’s happen in your exact case but I wanna step back and ask about the big picture. /usr/lib/libc++.1.dylib is macOS’s built-in copy of the C++ standard library. It’s meant to be referenced by an absolute path: % grep install-name /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libc++.1.tbd install-name: '/usr/lib/libc++.1.dylib' Why are you trying to load it via an rpath-relative reference? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

All my apps work on both the iPhone and iPad, but due to the amount of changes - some structural - that are required to get an iPhone version to look and work properly on the iPad, I use two different views: @main struct MainApp: App { // ... var body: some Scene { WindowGroup { if(UIDevice.current.userInterfaceIdiom == .pad) { TabletView() } else { PhoneView() } } } } So, if the user is using an iPhone, the PhoneView() is the main entry point. For iPads, it's TabletView(). The reason I did this is because the iPad has much more space and allows me to do more things, so the TabletView has more things in it. Also, I'd rather not have one big, unmanageable View full of if ... else statements and ternary operators. It also means your spacers and padding values apply only to that device type. Where the two views have similar UI, those bits are extracted into their own little View structs and called within those two main entry points. When you separate out the two views you may find you're duplicating som

I’ve asked as well on the app support forum. As a dev, I often answer questions on my github that are config or usage related. And yes, these are my apps so it’s different but these questions are normally asked on dedicated support forums not on GH. Anyway, I’m not sure we need to make a big fuzz about that, let’s say then that my ask to devs in general here, related to my issue, is ”please don’t do the same in your apps and make sure that when you use certs, you don’t forbid use of IP-addresses directly”.