İOS 26 beta battery %1

I'm looking into rewriting our non-replicated FP as a replicated FP, and I'm running into this as well. I'd like to show some UI that includes information from the database we keep about items, and if I had the NSFileProviderItemIdentifier we give to iOS, I could use that to look up the info. Is there any no way to convert the __fp/fs/docID ID into the original ID?

Yes Xcode 26.0 iOS 18.7.1 Alright, thanks for the feedback. I guess it wasn't working because of the ios version. I tried the legacy version and it work.

FB20662270 Thanks for that. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

“Allowed” is a tricky word, because it covers both business and technical limitations. I don’t work for App Review and thus can’t offer definitive answers about the former. I recommend that you review their published guidelines. But ignoring that, the technical aspects are also tricky. The basic idea of updating your Core Spotlight index in the background should be feasible. The sticking point is getting access to the documents. The cool thing about Spotlight importers is that they’re tightly sandboxed. So the system is able to find all the user’s documents and present them to the importer. The importer is sandoxed so info can’t leak to the app, and the app never gets access to the user’s entire file system. Neat-o! You lose that if you do this indexing yourself. You will be able to access any documents in your app’s container, and any documents which you were previously granted access to by the system [1], but you won’t necessarily be able to see all documents. Share and Enjoy — Quinn “The Eskimo!”

Hmmm. You are somewhat crossing the streams here. Development-signed builds are intended for development machines, and there’s an implicit assumption that apps built on development won’t be quarantined. Normally I’d suggest you get around that by following the Developer ID path — signing with Developer ID and then notarisation — but that’s not really feasible for an NE appex, because we don’t support those for Developer ID. Directly distributed apps have to use a sysex. And converting an appex to a sysex is not a trivial task. Except… Are you ultimately planning to ship this app on the Mac App Store? If not, you might as well grasp the sysex nettle now. For detailed info about NE distribution limitations, see TN3134 Network Extension provider deployment. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='864642022, oddeyed, /thread/805992?answerId=864642022#864642022, /profile/oddeyed'] I am looking at performing this check on file system paths which I can consume as an input to my product. [/quote] OK. But I’d like more info about your goal. Is this a security product? Or a developer tool? Or something else? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Same problem here with ReportCrash. But I see it even with the iOS 26.0 Simulator. It started in Xcode 26.1. I didn't have this issue in Xcode 26.0. Reported yesterday via Feedback Assistant: FB20918609 I can't work like this. My MacBook is getting extremely hot in seconds.

Is this only affecting new versions of your product? Or are you seeing it with old versions? That is, if you take a version of your product built, say, 6 months ago and try to install it on macOS 26.0 and macOS 26.1, do you still see it work on the former and fail on the latter? If so, you should file a bug about that, making sure to include: A copy of the installer package A sysdiagnose log taken shortly after seeing the failure Once you’re done, please post your bug number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

When the notary service actually goes down, DevForums tends to light up with complaints. I suspect that this issue in something specific to your product. Looking at your older thread, it shows that notary responded, but with an error complaining about the format of your submission. Is that case again now? If so, please post your notary log again and I’ll see what I can figured out. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='806186021, binarytwist, /thread/806186, /profile/binarytwist'] How can I get a provisioning profile that only has the entitlements that I actually need? [/quote] You shouldn’t need to do this. The entitlements in a provisioning profile act as an allowlist. For an in-depth explanation of that, see TN3125 Inside Code Signing: Provisioning Profiles. When you enable the NE capability on an App ID and generate a profile for that App ID, the Developer website includes all NE types supported by the target platform. Hence the presence of url-filter-provider value. However, this is just an allowlist. The entitlements you claim are those in your code signature, and that’s what the Validate App should be checking. [quote='806186021, binarytwist, /thread/806186, /profile/binarytwist'] My entitlement file has [/quote] Your .entitlements file isn’t the source of truth here. It’s source code that acts as an input to the Xcode build system. So you need to check the entitlements on your built binary. Do this: In the X

Hi Ziqiao, Your previous guidance to use a ModelActor and PersistentIdentifiers has successfully resolved all my data race crashes. However, I'm left with one persistent UI-level race condition, specifically related to deletion. My View Structure My setup is a standard master-detail pattern, which on iPhone (where I'm seeing this bug) acts like a NavigationStack: ScheduleView (Master): Uses @Query to fetch and display all events in a List. Each row is a NavigationLink. This view also has a swipe-to-delete action on its rows. EventDetailsView (Detail): The destination of the NavigationLink. It contains a Delete button. The Problem: A dismiss() vs. @Query Race When I tap the Delete button in EventDetailsView, I call my actor (e.g., await databaseManager.deleteEvent(id: event.persistentModelID)) and then immediately call dismiss() to pop the view. The Bug: When the app returns to ScheduleView, the row for the just-deleted event is still visibly active in the list for at least 5 seconds before it finally

iOS 26.1 is released, iOS 26.2 beta appeared, but no signs that UIManagedDocument loses @MainActor. Does anybody have the same concern? Anybody uses UIManagedDocument and wants to transition to Swift 6? Or, perhaps, already use it?