İOS 26 beta battery %1

Same for me. Happens for SwiftUI preview in xcode and also when running the simulator. It drains like 1% battery per minute or faster.

That's bad news. Am I allowed to use BGAppRefreshTaskRequest or BGProcessingTaskRequest, and a NSMetadataQuery, to watch all the files in the sandbox and manually index in Spotlight the updated ones? This way I can open a file and index each note separately.

Hi Kevin, Thank you again for your guidance. We have an important update based on your advice. Following your suggestion to compare property configurations, we analyzed our KEXT's source code, as we could not find the relevant properties in the KEXT's IORegistryExplorer snapshot. We then attempted to replicate the KEXT's behavior in our DEXT, which has led us to a final, specific contradiction that we hope you can help us resolve. Here is a summary of our findings and final questions: 1 - KEXT Source Code Contains setProperty Calls We discovered that our KEXT's Start() function programmatically sets several IOBlockStorageCharacteristics using setProperty. The key value is: // In KEXT's Start() function: #define MAX_IO_LENGTH (512 * 1024) // 512KB setProperty(kIOMaximumByteCountWriteKey, (UInt64)MAX_IO_LENGTH, 64); // ... plus other similar properties. 2 - DEXT Fails Despite Replicating KEXT's Configuration Based on this finding and your previous advice, we implemented the following in our DEXT: We im

Hi, Sorry to hear you are having problems getting builds working. This is indeed an odd error. I noticed that the source code is currently stored in your Downloads folder. This is a folder on your system that is a bit special (I'd put Documents, Desktop and maybe Library in to that same category). Could you try moving the location where you store it to a different place in the filesystem than one of those and see if that improves the situation?

Oi vey! You’re calling WKWebView from a secondary thread: Thread 4 Crashed: … 7 WebKit … -[WKWebView loadRequest:] + 160 8 SSOExtension.debug.dylib … closure #1 in closure #2 in AuthenticationViewController.beginAuthorization(with:) + 2132 9 SSOExtension.debug.dylib … ChallengeApiHelper.performChallengeApiRequest(authorizationRequest:deviceId:completionHandler:) + 1952 10 SSOExtension.debug.dylib … closure #2 in AuthenticationViewController.beginAuthorization(with:) + 2012 11 SSOExtension.debug.dylib … thunk for @escaping @callee_guaranteed @Sendable (@unowned Bool, @guaranteed Error?) -> () + 132 12 AppSSO … __81-[SOAuthorizationRequest presentAuthorizationViewControllerWithHints:completion:]_block_invoke + 248 That’s so not allowed, and it’s triggering a trap that crashes your process. Weirdly, the WebKit Features for Safari 26.1 blog post lists this: Fixed a crash when an app uses WKWebView::loadRequest API on background threads. (162225842) So clearly you’re not the only one doing thi

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. iOS and macCatalyst. Well, that doesn’t make it easy )-: I see at least two complications here: You have an app that’s kinda shoebox-y and kinda document-based. Spotlight uses different approaches for these two types of apps. For a documented-based app, iOS and macOS have completely different mechanisms for indexing documents. If you decide to build an importer, you’ll have to package your core code in two different ways: an iOS-style CSImportExtension app extension and a macOS-style .mdimporter plug-ins. Expanding on the first point, when you build a document-based app Spotlight implicitly assumes that each document is a single user-visible piece of content. It just doesn’t have a way to represents items within a document. That’s reflected in the API for both the iOS-style and macOS-style import APIs. Share and Enjoy — Quinn “The Eskimo!” @ Developer

I can’t say much here other than to confirm that your bug has made it to the right folks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm experiencing a similar issue. All my subscriptions in the Sandbox environment are marked as Your payment method was declined. I've tried everything—clearing payment history, creating a new sandbox account, changing region, switching devices, turn off/on Allow Purchases & Renewals—but nothing seems to work. Interestingly, one-time purchases go through without any problems. Does anyone have any idea what might be causing this?

That option certainly works, but it’s not without its challenges, including: If the app costs money, or has in-app purchases, users are likely to get grumpy about having to buy things again. If the app stores critical data in its container, you’ll need a way to migrate that data, which is tricky these days due to app container protection [1]. Regardless of what else you do here, I recommend that you file a bug against App Store Connect asking them to remove this limitation. Things have changed a lot since app transfers first rolled out on the Mac, and maybe that offers an avenue for improvement here. 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 [1] I have a link to the WWDC session that covers that in Trusted Execution Resources.

[quote='805992021, oddeyed, /thread/805992, /profile/oddeyed'] I am currently researching for ways to get the versions of all of the Mach-O executables and dylibs [/quote] To what end? Your ultimate goal here matters, because that affects what path you follow. For example, if you’re just messing around with shell scripts, then lsappinfo is a reasonable enough choice. However, if you’re trying to build a product that you ship to a wide range of users, you wouldn’t want to rely on lsappinfo because it’s output is intended to be read by humans, not by programs. OTOH, there are APIs that let you get similar information. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com