İOS 26 beta battery %1

Really? I would count having all system .app compressed on everyone's Mac as widespread use. Yes. I think well-designed, file system-level compression is a very reasonable feature that could be very useful. Unfortunately, that's not really what we implemented in HFS+ or APFS. There's a reason our APIs don't really support compressed files, and that's because their file system implementation means that they aren't fully supported by the entire system. Moreover, everyone loves macOS's compressed .dmg! It's a shame the app bundle I dragged out of it takes more than 2x the space than the distribution .dmg.[1] FYI, part of the reason this works so well is the other side of the same problem that makes it less valuable in the general file system. The file system manages storage in terms of allocation blocks (typically 4kb on our system), each of which is used regardless of the files’ actual contents. You can see this if you create a file with a few bytes of text in it, then Get Info on it using the Finder.

Hi @joelgethinlewis @mtsrodrigues. Thank you for your post. You can only track one image at a time currently. If you'd like to track multiple images simultaneously, please file an enhancement request via Feedback Assistant.

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