file uri scheme

This is only with the new NetworkConnection API, right? So things work if you use the older NWConnection? If so, my advice is that you file a bug against the new API. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you for your reply. I understand that the following is a reserved character in XML: & Below are the current expected and actual values. Driverkit expected value 0x00001916&0x0000FFFF Provisioning file contents 0x00001916&0x0000FFFF Entitlements file contents 0x00001916&0x0000FFFF I'm not sure why Xcode Signing Certificate status is Failed with the above configuration. It doesn't seem to me that Driverkit and the provisioning file expect & as the expected value. Based on the above, isn't it Xcode that expects &? I'm suspicious of Xcode's behavior. I'm worried that resubmitting the authorization request won't improve the situation. Is my understanding incorrect?

Thanks! That clears my confusion up. Right now I'll just be focusing on the layers relevant to an FSKit module. I wasn't even really thinking of the case where reported total bytes != physical total bytes, but that example makes sense. As a real-world example, copy-on-write (COW) file systems like APFS work by pushing all changes out as writes which are then applied, but that also means that it's possible to put the file system into a state where it can no longer be modified. Modification would require free space, so if all the space is gone modification becomes impossible... and that INCLUDES deleting files. The simplest solution to this is exactly what APFS does— set aside enough space that you'll always be able to delete files, then increase your used count so that the volume is full before you ACTUALLY run out of all space. Huh. Out of curiosity, did APFS always do that to prevent that issue? I vaguely remember seeing an issue like that at a user level years ago (althou

However, currently, if I enter &, the Signing Certificate status displays Failed. Based on the current situation, does this mean that when resubmitting, I'm required to enter the following value, including &? I don't think it actually matters. More specifically, if you submitted with a value of: 0x00001916&0x0000FFFF We'd HAVE to modify that to: 0x00001916&0x0000FFFF That is, we CANNOT create a provisioning profile that directly contained that first configuration. That configuration is invalid XML. I don't think any of our tooling will allow it to be created, and I do know that none of our validators will accept it. Now, theoretically, we could construct an entitlement which displayed as: 0x00001916&0x0000FFFF Because its raw text value was: 0x00001916&0x0000FFFF However: I believe our internal tooling is set up to prevent that. Even if it didn't, our tooling actually shows the raw value when we create entitlements, and the approvers know enough about all this to recognize that the

Thanks for the post. This is interesting you want to remove some support. On top of my head. What about setting the architecture the project supports? Xcode Project Settings: Open your project in Xcode. Go to your project settings by selecting the project file in the Project Navigator. Select your app target, then navigate to the Build Settings tab. In the search bar, type Valid Architectures. You may need to show all settings by clicking the All button at the top. Set Valid Architectures to arm64. This change ensures that your app is built only for Apple Silicon, which uses the ARM architecture. Will that work for what you trying to accomplish? Other developers here may have better ideas of how to drop support for Intel. Please be sure to note that if you targeting the App Store. In general, App Store does not allow you to ‘narrow’ your requirements. You can’t remove support for device type in a newer version. There is a device narrowing exception that you can apply for to allow this sort of thing.

Is there any resolution on the horizon for this issue? Have you specifically tested this in iOS 26.1? FB19916760 should have been fixed in that release. Would it help if I file a Feedback Assistant report or can I join an existing one? If it's happening on 26.1, then the next step is to test in the latest seed* of iOS (iOS 26.2 beta 3/23C5044b). If it's still happening there, then please file a bug, upload sysdiagnose, and then post the bug number back here. *This both makes sure it's still happening and avoids being asked to reproduce on the latest seed. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I suppose a lot of my confusion lies in how FSBlockDeviceResource.blockSize is described as The logical block size, the size of data blocks used by the file system, which I understand to mean that in my case, I should be able to set it to the value stored in the superblock (let's say that's 4096). So, the more useful description is what's in the discussion: FSBlockDeviceResource.physicalBlockSize: This is equivalent to the DKIOCGETPHYSICALBLOCKSIZE device parameter. Conceptually, this means the smallest transfer the device is physically capable of transferring. In high-level API terms, all I/O done to the rdev (raw dev node) MUST be an even multiple of this value, otherwise the I/O will immediately fail without ever reaching the hardware driver. FSBlockDeviceResource.blockSize: This is equivalent to the DKIOCGETBLOCKSIZE device parameter. This value is the device’s preferred I/O size, meaning the size it would like to have even if it COULD handle smaller requests. Two points to understand here: Much

For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, This is a very good goal for security. However it still involves the movement of private keys, which is inherently less secure than a system where the private key never moves. Apple devices offer support for ACME and SCEP. With those protocols the private key is generated on the device and never moves. In addition Apple's support for ACME includes support for hardware-bound keys, which offer very strong protections against exporting private keys. Considering your attention to the security of your architecture, I would strongly suggest adopting ACME instead of identities generated by your MDM server. That aside, configuration profiles require that (in nearly all cases) when one payload references another payload, both payloads must be in the same configuration profile. That requirement applies to all identity types (PKCS12, ACME and SCEP). Declarative Device Manage

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

The SwiftData files can be found via the modelConfiguration.url property, typically in the program container's Application Support folder. If you have a ModelContainer, you can pass it to something like this: showDatabase.txt Which will print all the filenames and sizes for the sqlite databases as well as any support files for model attributes marked as external storage.

The way this is written makes it sound like there will be a call to... Yes, and I'm actually not sure where that documentation entry actually came from, as it doesn't actually make very much sense (r.165622059). The header doc is a bit more clear: Disable implicitly starting access of the ephemeral security-scoped resource during resolution. Instead, call -[NSURL startAccessingSecurityScopedResource] on the returned URL when ready to use the resource. Not applicable to security-scoped bookmarks. The key word there is ephemeral. On macOS, there is infrastructure in place such that if an app makes a normal bookmark and gives it to another app, that other app has access to the file it JUST received without any additional action. That mechanism is what ephemeral and implicit refer to. That system is better described in NSURLBookmarkCreationWithoutImplicitSecurityScope: Bookmarks that you create without security scope automatically carry implicit ephemeral security scope. This security scope is valid unti

First, a quick comment here: And on iOS, what are the equivalent creation and resolve options? The minimal variants? So, let me actually run through the option set here. First, the standard cases that are actually in common usage: 0/NULL/No Option: This is a default bookmark and what you'd almost always use on iOS. On macOS, they're also used to transfer access between processes and may be used if/when you're trying to track files in a situation where you're already known to have access to the file (for example, shoebox apps tracking files within their shoebox directory). NSURLBookmarkCreationSuitableForBookmarkFile: This creates the exact same data used to create Alias files in the Finder. NSURLBookmarkCreationWithSecurityScope/OnlyReadAccess: The macOS bookmark type used to preserve access: Edge cases: NSURLBookmarkCreationWithoutImplicitSecurityScope: Discussed in more detail below, but allows the creation of a bookmark that specifically DOESN'T provide any access to the