İOS 26 beta battery %1

I think I may have found a workaround. Installing & using the iOS 26.0.1 simulator under Xcode 26.1 does not seem to engage the ReportCrash process. So far so good!

This is the notary log and it still contains the same critical validation errors claiming it has no signed executables or bundles. However if I skip notarization and just install it using installer -verboseR -pkg ConcealDistribution.pkg -target / it works just fine and everything installs as expected. As I mentioned in the older thread I have not changed the structure or format of this PKG and this has been working for months up until a few weeks ago when it suddenly started failing. { logFormatVersion: 1, jobId: 14cc46bd-10d5-4e9c-9ad6-86c06baad6b2, status: Invalid, statusSummary: Archive contains critical validation errors, statusCode: 4000, archiveFilename: ConcealDistribution.pkg, uploadDate: 2025-11-05T21:53:19.782Z, sha256: 48ba80a95c818ae81cadcca07afed1ef4d0d8c120a87622b200dc9935964ee26, ticketContents: null, issues: [ { severity: error, code: null, path: ConcealDistribution.pkg, message: Package ConcealDistribution.pkg has no signed executables or bundles. No tickets can be generated., docUrl

Xcode 26.2 beta 1 and iOS simulator 26.2 beta 1 has the same issue :(((((

Thanks for your reply! When a user clicks Export Video and I immediately start the export (taking ~5 minutes for long videos), can I use BGContinuedProcessingTask only to update progress, rather than triggering the export itself within BGContinuedProcessingTask? Yes. All the launch handler really HAS to do is export the new BGContinuedProcessingTask object so that the rest of your app can use it for things like updating progress and/or ending the task. That doesn't need to be any more complicated than using Dispatch to send it to some other part of your app. That leads to here: I'm unclear if iOS only protects tasks triggered inside BGContinuedProcessingTask or the entire app process. First, as a broad background, it's worth understanding that many of the new technologies (like GCD blocks or Swift Tasks) are largely syntax sugar as far as the large system is concerned. As far as the broader system is concerned, there are only really two basic constructs: Threads, which are individual execution stream

QLThumbnailGenerator is for generating thumbnails. It sounds like you are just trying to read whatever icon is there, not generate a new one. Just use one of the NSWorkspace or URL methods to retrieve the icon.

We could not find the relevant properties in the KEXT's IORegistryExplorer snapshot. Looking at the snapshots you sent, I've listed the configuration of both drivers. Note that the first section lists the properties of the direct driver itself, while the second is the actual IOSCSIPeripheralDeviceType00, the parent IOBlockStorageServices. Here are the two configurations: (1) KEXT configuration: KEXT (subclass of IOSCSIParallelInterfaceController): IOMaximumSegmentAddressableBitCount = 0x20 IOMaximumSegmentCountRead = 0x81 IOMaximumSegmentCountWrite = 0x81 IOMaximumByteCountRead = 0x80000 IOMaximumByteCountWrite = 0x80000 IOMinimumSegmentAlignmentByteCount = 0x4 IOSCSIPeripheralDeviceType00: IOMaximumBlockCountRead = 0x400 IOMaximumBlockCountWrite = 0x400 IOMaximumByteCountWrite = 0x80000 IOMaximumByteCountRead = 0x80000 (2) DEXT Configuration DEXT: IOMaximumSegmentAddressableBitCount = 0x40 IOMaximumSegmentCountRead = 0x81 IOMaximumSegmentCountWrite = 0x81 IOMinimumSegmentAlignmentByteCount = 0 IOSCS

One minor update on this. If you happen to test with the current beta of iOS 26.2 (23C5027f), you'll find that the issue is still present. This is purely a matter of release timing and not a regression. Due to the sensitivity of this particular issue, the fix was directly back ported into the release build of iOS 26.1 and we simply haven't released a new seed build that contains the same fix. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Contact Access Picker works on Simulator (iOS 18.6 and iOS 26.0) and on a device (iOS 18.6). Should I prepare a test project to share with you?

That makes sense. I think it's not going to be too bad for customers. The data in the containers is basically transient cache and temp files (another reason why this particular App Store restriction is probably inappropriate in this case). The user's programs are stored in NSDocument bundles wherever they put them on disk (these bundles are used by the IDE via security scoped URLs which we bookmark and pass to the XPC service in the new versions of the app). In all app versions, a customer can wipe the app container, even the group container, and as soon as they restart the IDE it's all recreated and works perfectly. I test this use case regularly and it's bullet proof. Financially, the app uses (very cheap) monthly auto renewing expenses. The app itself is free to download (the auto renewing subscription is required for building programs, and comes with a month free trial) and doesn't have any permanent in-app purchases that people would lose. I can work with the new developer (a good friend), customers, etc

Tab bars accessory views stay visible across your app, this was introduced in iOS 26.0. Please review Get to know the new design system to explore the new design system and key changes

It's a user's preference whether they want privacy-sensitive information to be redacted. This is similar to the preference that allows a user to decide if iMessage notifications on their iOS Lock Screen should show the actual message. On watchOS, a user can set their preference at Settings -> Clock -> Show Data When Locked for Lock Screen, and at Settings -> Display & Brightness -> Always On > Show Complication Data for Always On. The settings are on by default, and I guess that is why you don't see privacySensitive() working. Please confirm if that is your case, if you don't mind. For Always On, you can overwrite the user's preference by providing a different appearance based on the isLuminanceReduced environment variable. That explains why your code works when the device is in that state. If you'd really like to overwrite the user's preference for Lock Screen, you can add the Data Protection entitlement to your widget extension, and set it to NSFileProtectionComplete or NSFilePro

Hello @sadaotokuyama ! Thank you for your question. Could you please submit feedback using Feedback Assistant? And then share the ticket number here. I think understanding your usecase would be helpful for us, and you'll be able to receive updates about any changes or improvements in the future. It is true that when you modify content inside your RealityKitContent package, the entire package will need to be rebuilt. This is inconvenient, especially when you need to make frequent changes during development. For now, I recommend focusing on ways to reduce the frequency of changes you make to the asset itself that would require a rebuild in the first place. For example, are there ways you could verify changes in an external DCC? One thing you could do now: try placing your large USDZ file outside the RealityKitContent package, and inside a separate bundle, like the main bundle. Then, when you make changes to the large USDZ file, your entire RealityKitContent package won't need to be rebuilt. Depending o

Same for me, macOS 26.1 and visionOS 26.1 or 26.2 beta 1