smb big sur

[quote='786668021, taisei_hikawa, /thread/786668, /profile/taisei_hikawa'] Is this concern valid? [/quote] Yes. The details vary based on the specific protocol you’re using but, in general, going ‘too wide’ will waste resources and can potentially slow things down. As to what you should do, that depends on a bunch of factors: How large are the images? And how many do you have to upload? What protocol are you using? If it’s HTTP[S], are you using a background session? Are you talking to one specific server? Or do you need to work with a lot of different servers? If it’s one server, what HTTP version does it use? IMPORTANT There’s a big difference between HTTP/1 and HTTP/{2,3} when it comes to parallelism. If you’re still using HTTP/1, you’ll likely get more ‘bang for your buck’ by upgrading the server to HTTP/2 than by tweaking your client. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Indeed. I guess I should be able to recognise our own documentation code )-: Anyway, with that context, I can answer your specific questions: is the function RefreshAppContentsOperation() where to implement code that needs to be run in the background? Yes and no. In this example RefreshAppContentsOperation is meant to be an Operation subclass that implements the app refresh operation. If you want to use this approach, you’d create your own subclass of Operation and then implement the main() method on that. For example: final class RefreshAppContentsOperation: Operation { override func main() { … your code here … } } However, there are other approaches you might adopt. For example, you might start a Task and run Swift async code within that task. Note The term task is overloaded in this context. The Background Tasks framework uses it to refer to the state that’s tracking the work and Swift concurrency uses it to refer to the state of the code that’s actually doing the work. [quote='786186021, marcofusco111, /t

Migrating a large codebase to Swift 6 is not a trivial task. You can expect to encounter a significant number of issues. However, it’s possible to make rapid progress because, in general, these issues falls into big groups. Once you work on the solution for one of the issues in a group you can apply the same solution to all other issues in that group. There are a couple of standard resources that I generally point folks at here: WWDC 2024 Session 10169 Migrate your app to Swift 6 Migrating to Swift 6 Additionally, the Swift team is actively exploring ways to make this process easier. For a general explanation of the plan, see the Improving the approachability of data-race safety vision doc. There are are a bunch of in-flight Swift Evolution proposals that work towards that vision. So, you have a choice here: You can choose to tackle this today. Or you can wait for those changes to land in a production Swift compiler. If you want to tackle this today then I’m happy to help, but I need to see concrete

[quote='840893022, TinyFish, /thread/785083?answerId=840893022#840893022, /profile/TinyFish'] Your crash report is similar to mine, except for the name of the dynamic library. [/quote] Right. That’s just because my app doesn’t use C++ directly. But both the libraries in question are built-in to macOS and thus I see these results as equivalent. [quote='840893022, TinyFish, /thread/785083?answerId=840893022#840893022, /profile/TinyFish'] Is it possible that it is a bug in macOS …? [/quote] macOS is big enough and complicated enough that literally anything is possible. However, the most likely scenario is that the user changed something without understanding the consequences. My immediate suggestion is that you ask them to check the state of the Open Using Rosetta checkbox, per step 9 of my previous post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks Quinn, I'm sure a new and clean empty project runs, but this is a (big) existing project, objective-c, no storyboard but XIBs, that has run fine before 18.4, for years. As the crash happens before my code is even entered I don't even know where to start! Does this Sanitizer message mean anything to you? What is the problem with MemoryMappingLayout? libclang_rt.asan_iossim_dynamic.dylib__sanitizer::MemoryMappingLayout::Next: 0x10f2dae50 <+0>: cmpl $-0x1, 0x8(%rdi)` With the sanitizers switched off in the Run Scheme the app runs fine in the Simulator, but I have a user that experiences an actual crash on device. That crash is different from what I experience: the app crashes on simulator before entering my code, after displaying the splash screen, while the user has an app that does startup, and can be used for a few seconds, but crashes on a certain input. As is, I cannot even establish if these crashes are related. In the App Analytics in AppstoreConnect I see no increase in the number o

Then VNOP_PAGEOUT gets called. I thought that VNOP_PAGEOUT was only called for mmapped files. No that's not correct, that's definitely not correct. The idea behind the UBC (Universal Buffer Cache) is unify the I/O and VM system into a common architecture. In concrete terms, these to cases: Reading the first 16kb of a file. Mapping the first 16kb of the same file. ...should both return a VM page that's actually backed by EXACTLY the same page in the UBC system. Similarly, writing to the first 16kb of that file and modifying a mapped file both have EXACTLY the same result- that is, they both modify the same page in the UBC. But there are no VNOP_MMAP/VNOP_MNOMAP calls being made for the files being extracted. No, you called cluster_write(), which basically means please modify this pages in the UBC. The current VNOP_PAGEOUT implementation ends up calling err_pageout() for files that didn't get tagged as being memory mapped by VNOP_MMAP. I don't think that's going to end very well. Have you looked at what it's ac

We have a problem in a scenario that SIM lock is disabled so after a phone reboots it has the Internet connection but it is still locked. When you call into the VOIP app the app is not being launched as the result (it seems reasonable because it wouldn't be able to access the keychain items etc...) So first off, yes, this can happen. There are a small number of edge cases (one of which is voip) where the system may launch the app prior to first unlock. This behavior has never been documented and can be somewhat inconsistent, however, it's is also VERY old (it comes the original, iOS 4, voip architecture). Because of that, my advice to voip developers has long been: Don't assume/rely on it always happening. As you've noted the behavior is somewhat odd and there are situations where it will not occur. Be prepared for it to happen and handle it as gracefully as you can/choose. Depending on your app architecture, that could mean handling the call completely or simply reporting and then ending the call. One note o

No, I never got a response. I filed a DTS, and the engineer who helped me wrote to the CarPlay team, or so he said. They also ignored him. I kept replying to the DTS for a while, until I was also ignored here. I also tried the contacting Developer Support. They replay to my e-mail, assign a case ID, they say they are escalating my request, and they they ignore me. When I replay a few days later, same history. I have also reapplied to get the entitlement every time I have added a big update to my apps which implement navigation. Also ignored. So I made a big investment to add navigation to my apps, I am not granted the entitlement when my use case is similar to other apps which have it, and now I am holding off on some marketing campings, what's the point to try to get more users if this will lead to bad reviews because they cannot see the map in CarPlay. Worst experience ever. I am quite desperate.

If the find a bug in the sample code please file a big report via Feedback Assistant and post the FB number here once you do. https://appleinsider.com/articles/25/04/18/when-you-report-bugs-on-ios-some-content-may-be-used-for-ai-training Thanks… but for privacy reasons I'm currently blocked on submitting bug reports due to a requirement on AI training. Are you referring to the dismiss environment property? I'm referring to the Select and Done buttons that appear to toggle EditMode:

Did I forget something in the InitializeInterrupt implementation? What's actually failing? Are interrupts not firing? Or is something else breaking? Or is there another reason for this issue? My big question here is what the details of this are: Right now, if I first load KEXT, then completely remove it and load DEXT without rebooting the storage, DEXT interrupts work fine. But if I restart the storage, DEXT interrupts stop working. Here is the implementation for initializing MSI-based Interrupts. One thing I would be careful of here is that you're testing scenarios that your hardware will handle in a reasonable way. For example, I've see a few different cases where developers ran into problems when their DEXT was run repeatedly against the same device without hot plugging after the DEXT has crashed. In a lot of cases, this is a pointless case to try and test/fix. If this was a KEXT, the kernel would have panic'd and you'd have reset the hardware. The DEXT may have avoided the panic, but that doesn't

The Table component displays a Select Button for selecting elements and a Done Button disabling that state. These buttons seem to be breaking something about navigation on iOS 18.4.1. It's a nondeterministic issue… but tapping the buttons seems to lead to some corrupt state where the app transitions out of OrdersView and back to TruckView. If the find a bug in the sample code please file a big report via Feedback Assistant and post the FB number here once you do. Bug Reporting: How and Why? has tips on creating your bug report. Is there any public documentation for me to learn about the Select and Done buttons? I don't see anywhere for me to learn about how these work and what my ability is to customize their behavior. Are you referring to the dismiss environment property? If you are then checkout the API docs on dismiss and DismissAction

That leads me to Part 2... I did a small sample project which demonstrates that using clonefile on a folder works correctly and is 10× faster than using FileManager’s copyItem method. As I've learned over and over again, you need to VERY careful and thoughtful when testing anything file system related, as it's very easy to build tests that don't actually show what you think. Case in point, I actually downloaded your sample project and did a bit of testing and here are the initial numbers I got: doClone (0.284348 seconds) doClone (0.149546 seconds) doDuplicate (0.340530 seconds) doDuplicate (0.102446 seconds) My immediate thought was that those numbers look REALLY big and the inconsistence is odd. The whole point of file cloning is to be fast and, just as important, all of this is basically manipulating the file system structures in memory so the time required shouldn't vary much. SO, the first thing I did was modify your project so that it reused the existing source data (if it already existed) inste