İOS 26 beta battery %1

[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?

There isn’t an API to change the system time zone. If you’d like to see that change, I encourage you to file an enhancement request that outlines what you want to do and why. And if you do file an ER, please post your bug number, just for the record. Regarding the systemsetup tool, that tool is aimed at system admins. It’s not intended to be a substitute for an API. You can attempt to use it as such, but in my experience such attempts are usually less than satisfactory. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It sounds like you’re building an accessory and you want to use Wi-Fi Aware to talk to that accessory from iOS. If so, go to Developer > Accessories, download Accessory Design Guidelines for Apple Devices, and review the Wi-Fi Aware chapter. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Oh, you’re a system extension. That changes things. System extensions, due to their privileges position on the system, are not allow to use entitlements to disable the additional security measures imposed by the hardened runtime. The only exception that that rule is that macOS platform extensions [1] are allowed to use JIT via the com.apple.security.cs.allow-jit entitlement. Sadly this isn’t documented on the Hardened Runtime page, and I’ve filed a bug to get that fixed (r. 164078299). So, if you want to use JIT in your sysex, you can’t lean on the com.apple.security.cs.allow-unsigned-executable-memory compatibility crutch. You’ll have to do the right thing and use com.apple.security.cs.allow-jit, as explained in Porting just-in-time compilers to Apple silicon. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] So, not DriverKit drivers.

I recommend that you seek help from your third-party vendor here. It seems likely that they’ll have a well-trodden path that you can follow for this. If you decide to debug this yourself, I have some general hints. To start, dont use --deep when signing code. For an explanation as to why not, see --deep Considered Harmful. Rather, sign each code item separately, from the inside out. Creating distribution-signed code for macOS explains that process in detail. I think that’ll reveal that there’s an issue with FMWrapper.framework. If so, that’s good, because gives you something to focus on. One of the most common causes of weird problems signing frameworks is that folks copy the framework without preserving symlinks. You should check that’s not the case here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com