İOS 26 beta battery %1

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

-10985 is not in any of the standard error ranges that I’d expect to see returned by URLSession. Indeed, I was unable to find an uses of that number as an error code. Are you able to reproduce this? If so, please add code to print the error and then post the results: … assuming `error` is either an `NSError` or a Swift `Error` … print(error) Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The first thing to rule out is the device not actually being included in the profile. Do this: Dump the profile of the app: % security cms -D -i MyApp.app/Contents/embedded.provisionprofile Dump the profile of the provider: % security cms -D -i MyApp.app/Contents/PlugIns/MyAppEx.appex/Contents/embedded.provisionprofile Check that the ProvisionedDevices lists match. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please post a full Apple crash report, per the advice in Posting a Crash Report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='806035021, chris_ogden, /thread/806035, /profile/chris_ogden'] I'm running on x86_64 macOS 13.6.6 [/quote] Are you able to reproduce this on a more modern version of macOS? There’s a couple of reasons why this matters: The dynamic linker has received significant updates in the last few years, so it’s possible that this is fixed already. If that’s the case, there’s no point filing a bug against macOS 13 because there’s no release vehicle for such a fix. Notwithstanding the above, be aware that dlclose has a significant limitation on macOS: In many cases its unable to actually unload the library. This limitation is fundamental to the system, rather than a bug. The dlclose man page lists some of the causes, but those are just the start. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='806107021, Yuantong, /thread/806107, /profile/Yuantong'] when I switch to Swift6, the example would crash [/quote] This doesn’t surprise me. The Multipeer Connectivity API hasn’t been updated for Swift concurrency [1]. Specifically, MCSession makes delegate callbacks on some unspecified serial queue, and Swift concurrency is that trapping because it’s expecting the callback to arrive on the main thread/queue/actor. You can fix this by implementing a non-isolated conformance to MCSessionDelegate. Having said that, my advice is that you use this as excuse to move away from Multipeer Connectivity completely. It has at least one known crashing bug that… well… while I can’t predict the future, the fact that it’s remained unfixed for the last five years should tell you something |-: If you decide you want to tackle this now, see Moving from Multipeer Connectivity to Network Framework for lots of advice. Note I haven’t updated that post to use the new Network framework API we introduced in

You are mixing two technologies that don’t usually mix. A UIApplication background task makes sense when you’re using a standard session. It prevents the system from suspending your app, giving it time to complete the transfer. In contrast, when you use a background session you don’t need a UIApplication background task because the transfer gets handed off to a system process that does it on your behalf. That allows the transfer to run even if your app gets suspended. And if your app is suspended when all your session tasks complete, the system will resume (or relaunch) your app in the background to let you know. There’s a stark latency vs endurance trade-off here: Standard sessions are low latency. The transfer starts as soon as you create it [1]. However, the transfer only continues as long as your app can avoid being suspended. Background sessions work even if your app gets suspended, but they have high latency. A background session will only start a transfer when conditions are favourable, and th

This is failing with EPERM, which is the most common reason for this sort of failure. It means that the operation was deny by some security subsystem, like App Sandbox. I discuss this in great detail in On File System Permissions. [quote='806049021, Richie_Wu, /thread/806049, /profile/Richie_Wu'] My process running with root privilege [/quote] On modern versions of macOS there’s no guarantee that root can access all files [1]. Given the location of the problematic app, I doubt this is not being caused by App Sandbox or MAC, meaning that ES is the most likely culprit. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, that was true even on ancient versions of macOS, where NFS would map root to nobody.