İOS 26 beta battery %1

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

Quinn, Thank you very much for the prompt and detailed reply. Do you happen to know if the problem might be caused by a plugin that is no longer being used but may still be referenced within my app? I ask because the only difference between the first version of my app (that sailed through to the launch file stage) and the one that fell at the first hurdle is that I added a plugin to the latter; then removed it. I tried removing all plugins from my runtime, and signing it again, but it made no difference. Thanks again.

I tried different device models, and some could trigger the task normally, such as the 15 Pro Max and 12 Pro Max. However, there were also some models, such as the 17 Pro, 15 Pro, and 15, that could not trigger the task properly. Moreover, there was no additional error information to help locate the issue. I assume you're doing this on device and not the simulator, right? And did you check the Console logs to see if an error was reported there? (look for the dasd process) I also just wanted to reiterate your other points about the BGContinuedProcessingTask API, in case someone from Apple is listening: I agree that the experience on non-Dynamic Island devices is not great. The task notification banner thing is a obtrusive and redundant. My app already displays a progress bar, so displaying another progress indicator is redundant. Moreover, the banner obscures my app's UI and does not disappear automatically like normal notifications. This leaves the user uncertain if they can safely dismiss it, or if dismissin

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. I'm confused by what you're trying to do here. Your file provider is the fundamental source of truth the system relies on. I can certainly see cases where you have user-relevant data that the system doesn't have— for example, displaying metadata the system doesn't use/support or showing the contents of directories the user has configured to NO sync. What I don't understand is how this flows in the other direction. The system’s view of your data should either always match yours or diverge in ways your provider understands and controls (for example, because you’re uploading/downloading data). What am I missing here? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hello @DTS Engineer , thanks for the response. Just to clarify, my app do send HTTPS requests and those work fine. It's when it tries to do a websocket connection with SSL that it fails to get the root certificate. The specific error would read something like SSL error: unable to get local issuer certificate (preverify_ok=0;err=20;depth=2) I am using Unreal Engine's built-in libwebsocket module to make a connection to a secure websocket server. I have built this project in the past with the same code and it used to work. I actually still have an old build that I can run and see it working. But any new build I am making with the same exact codebase, is now failing. The only things that have changed are updates to the build environment, we upgraded XCode at some point (I don't remember exactly when) to 16.4 - That is why my first suspicion was that it is caused by a change in the build environment. I'm kind of stumped honestly, this issue came out of nowhere and we made no code changes to our project. The built

Hi, Thank you for the reply. Yes, it is affecting the older version of the product which was released few months back. New and older version of the product works on macOS 26. Our software was working on beta version of the macOS 26.1 as well. Bug id is: FB20929578 Regards Prema Kumar

Please file a bug about this. There’s advice on how to gather the necessary info in that error alert, and it’d be great if you attach that to your bug report. Once you’re done, please post your bug number, just for the record When you click the Show Details button in that error alert it shows a bunch of info about what’s causing the error. It’s clearly grumpy about the provisioning profile. However, when you compare the profile’s allowlist and the code signature’s claims, things generally look OK. One thing I did notice is that there’s a bit of a mix up about the type of the com.apple.security.hardened-process.enhanced-security-version entitlement. That’s documented to be a string, and the profile’s allow list uses a string value of *. However, the code signature claims an integer value of 1. I manually re-signed the app to use a string: % cat tmp.entitlements … … com.apple.security.hardened-process.enhanced-security-version 1 … % /usr/bin/codesign --force --sign 09513FD4A0338742