Hello everyone, I just want to offer you image modifications that seem useful to get out of a version that has not evolved since the iPhone 3GS/4. The addition of options without redesign after a few years creates a "kind of tidy mess". I arrive from android having not had an iPhone since the 3GS, I am shocked to find the same interface as at the time. (I'm not criticizing, it's an observation). And I'm surprised by the lack of some essential options such as the right back, the missing numeric line in the keyboard, or the missing Touch ID (I don't want to record my face). So since I have been offering improvements to android and these applications, as well as play store applications, for years, and I love doing it, I naturally started thinking about Apple improvements. I let you take part in these different ideas (in French, Google translation can translate the images if you wish). Thank you all for your constructive opinions. Best to you. https://goopics.net/a/4r0fqeqw

I'm trying to restore an APFS volume to its previous state using a snapshot created with the tmutil command. The only native Apple tool I've found for this purpose is apfs.util. According to the documentation, the correct command for this task is /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -R </dev/diskXsY>. However, this command is not working for me. It returns the error "No such file or directory" for any existing . If I use a valid file/dir path instead of the as an experiment, I get an "Invalid argument" error. To investigate the issue, I decided to debug apfs.util and found that the fsctl() function is responsible for these errors (ENOENT and EINVAL). The first argument passed to fsctl() is the (or file/dir path in my experiment), and the second argument is the value 0x80084A01, which corresponds to the APFSIOC_REVERT_TO_SNAPSHOT command according to xnu's source code (https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L174). It seems that this command is not supported by the latest versions of macOS (see https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L12984) and always returns EINVAL error. Is this correct? Are there any other tools available that can be used to revert APFS snapshots?

When users share a file with my app I am having trouble 5-10% of the time obtaining the file meta data, specifically creation and modified time and size. Using SwiftUI with the code below.. .onOpenURL { url in var fileSize: Int64 = 0 var creationTime: Date = Date(timeIntervalSince1970: 0) var modificationTime: Date = Date(timeIntervalSince1970: 0) do { let fileAttributes = try FileManager.default.attributesOfItem(atPath: url.path) fileSize = fileAttributes[FileAttributeKey.size] as? Int64 ?? 0 creationTime = fileAttributes[FileAttributeKey.creationDate] as? Date ?? Date(timeIntervalSince1970: 0) modificationTime = fileAttributes[FileAttributeKey.modificationDate] as? Date ?? Date(timeIntervalSince1970: 0) <SNIPPED CODE no other tries though and not involving above variables> } catch { // quite confident I am ending up here because variables after the above code aren’t being set and there are no other try blocks, // so FileManager.default.attributesOfItem(atPath: url.path) must be throwing…. } <SNIPPED CODE> To attempt to resolve this, I added in a 0.5 second wait cycle if creationTime == 0 and modificationTime == 0 , so if obtaining both metadata fails, wait 0.5 seconds and try again, try this a max of 3 times and then give up. I don’t know how often I am entering this code (didn’t instrument the app for it), but am still getting times when metadata comes back blank which means this code wasn’t successful after 3 tries. I assume the file would only become visible and sharable with my app after it has completed being written by the original app/process. Perhaps it hasn’t finalized yet? Is there a way to detect this so I can tell the user in my share screen to wait and try again? I am assuming that the file has finished writing though since when I read the data from the file contents, it’s good data and complete even when metadata failed. I will be instrumenting the above code in my next app version, just hoping to fix it right now since users are emailing saying my app is broken. Thanks!

Recently, my application has a crash, which did not exist before iOS18, how can I fix this problem, the following is crash stack my code how i ues it darkText = NSAttributedString.getHtmlText(self.bannerModel?.darkText ?? "")

As a system & security administrator I started to install a lot of Unixes, 20 years ago with a dual volume for security purpose, inside critical infrastructures: volume mount options ------------------------------------------------ / ro /var rw, nosuid, nodev Everything which could be end user or admin modifiable and to be referenced from / was defined through simple symbolic links: /tmp --> /var/tmp /home --> /var/home /local --> /var/local /opt --> /var/opt /private --> /var/private And through many tests, and real attacks pressure of every day, with such a configuration, even as root, it was impossible to damage the system. Many attacks struck us ( ~ 20 / day )… none succeeded ( at least as I was aware of, and as I wasn't fired ). Why did Apple chose a rather more complex way similar architectures with the 2 volumes: volume mount options ------------------------------------------------ / ro /System/Volumes/Data rw, nosuid, nodev with a new concept of firmlinks which is not compatible with any other Unix FS, which brought Apple to put fundamental components of their new APFS outside of the FS internals ( in plain old files ) and which is rather very tricky to understand and to manage for system and security administrator? To give just one example of an highly deceiving point: it isn't now possible to make a quick carbon copy of a volume with tools as simple as cp or rsync because of new extended attributes. Real life teach us everyday that complexity is one of the biggest enemy of performance and security. What are the advantages of this sibling volumes architecture? ( I am not talking here of the real internal advantages of APFS versus HFS and traditionnal Unix UFS or ZFS, which I much easily grasped and verified in real life. ).

Hello, I have many problems to manage the new structure of the volumes introduced with High Sierra and Big Sur around the use and configuration of the APFS. Where could I find a technical documentation about this APFS organisation? By technical documentation I don't mean a theoretical nice PowerPoint for the boss. I mean a real technical documentation which will permit me for example: • to understand how is built and organized the complete set of different APFS volumes to install a new macOS, • to build an installer on an USB key which will be usabel for a highly secured environment where an Internet connection is not allowed and not possible, • to build a script to check that an actual APFS set of volumes doesn't present any major discrepency, a kind of meta-fsck, not the Disk Utility way, but the engineer way, essentially running through command line, and fully compatible with the traditionnal system, network and security administration. Sorry, I am a very special case of developper. I only develop tools from shell scripts to make system, network and security administration. And to build more scripts withm them. My answer to Select a Subtopic could have been: system administration, technical documentation

While playing with this app I found something odd: let dylib1 = dlopen("/System/Library/Frameworks/CreateMLComponents.framework/CreateMLComponents", O_RDONLY)! let s1 = dlsym(dylib1, "CreateMLComponentsVersionString")! var info1 = Dl_info() let success1 = dladdr(s1, &info1) precondition(success1 != 0) print(String(cString: info1.dli_sname!)) // CreateMLComponentsVersionString let path1 = String(cString: info1.dli_fname!) print(path1) // /System/Library/Frameworks/CreateMLComponents.framework/Versions/A/CreateMLComponents let exists1 = FileManager.default.fileExists(atPath: path1) print(exists1) // true let dylib2 = dlopen("/System/Library/Frameworks/Foundation.framework/Foundation", O_RDONLY)! let s2 = dlsym(dylib2, "NSAllocateMemoryPages")! // var info2 = Dl_info() let success2 = dladdr(s2, &info2) precondition(success2 != 0) print(String(cString: info2.dli_sname!)) // NSAllocateMemoryPages let path2 = String(cString: info2.dli_fname!) print(path2) // /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation let exists2 = FileManager.default.fileExists(atPath: path2) print(exists2) // false The app runs fine and prints true for exists1 and false for exists2. That means that while both dlsym calls succeed and both dladdr calls return paths (within CreateMLComponents.framework and Foundation.framework correspondingly) the first file exists while the second file doesn't exist. This raises quite a few questions: Why some of the dylib files (in fact – most dylibs inside /System/Library/Frameworks hirerarchy) don't exist at the expected locations? Why do we have symbolic link files (like Foundation.framework/Foundation) that point to those non-existent locations? What is the purpose of those symbols links? Where are those missing dylib files in fact? They must be somewhere, no?! I guess to figure out the answer I could search the whole disk raw bytes for a particular byte pattern to know the answer but hope there's an easier way to know the truth! Why do we have some exceptional cases like "CreateMLComponents.framework" and a couple of others that don't follow the rules established by the rest? Thanks!

Our team has recently added support to our app for Live Activities where the source of the data is driven from the app itself (not push notifications). We've noticed a crash happening in our core data code caused by the following error thrown by the addPersistentStore function where it would attempt to recover and eventually crash. Here's an error we created to help us debug that contains the error details: Domain: CoreData Code: 1 NSLocalizedDescription: Error performing migration for databaseName=mydb.sqlite. Error details=The file couldn’t be saved because you don’t have permission. - userinfo: ["reason": No permissions to create file; code = 1] After some trouble shooting, we managed to reproduce the issue by doing a hard reboot while we're running a live activity. It appears that when the device starts back up, the Live Activity starts which triggers the app to hit didFinishLaunchingWithOptions which is where we get our Core Data store initialized. The problem is that our app uses Data Protection using NSFileProtectionCompleteUntilFirstUserAuthentication and we'd prefer to keep it that way. The Core Data db is present in the app sandbox and we're also seeing logs to suggest a failure trying to access NSUserDefaults as well. Is there an accepted solution for this? Is it expected that a Live Activity would cause an application to launch prior to the device being unlocked for the first time? Is there a way to change that?

My phone gets very hot and then turns on and off, and it's been crashing a lot lately

Anyone download this yet and have your system data **** up in size? Lesson learned to never download beta of anything. Can barely work in Xcode 16 now, another beta I should not have downloaded :/ Anyway to reduce this size of system data properly? Thanks!

My App Rejected 4.3 Design: Spam What does that mean exactly? I took extra pictures with the phone from the app and upload to APP Store and the same thing over and over again (Guideline 4.3 - Design - Spam) just the question Why don't you want to unlock it? what is spam? The APP Or the pictures? If the APP is spam why? That means One user cannot create two different websites with Various APP An e.g. I have a social network I want to do then a dating site On the dating app I only get a message saying it's spam Funny what's in an APP is spam? Because dating app? Or can a user not make multiple page APPs because it almost looks like this? Then that means BMW can't make new BMWs because the new BWM also has 4 doors and 4 wheels or how should I understand that? which is still funny on Google Play the same APP is not spam