Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

(Reordering questions for clarity...) Questions: Is this behavior intentionally blocked by iOS as a user privacy/power decision? So, in general, the normal behavior of iOS is that it does not relaunch applications that have been force quit by the user, primarily to simplify the user’s general management of background app usage. However... Is it officially supported for iBeacon region monitoring to relaunch an app after the user force-quits it? ...there are exceptions and, yes, region monitoring is one of them. The issue here is that there are use cases we want to support that don't really work within the standard force quit behavior. The canonical example here is supporting airline apps notifying the user when they arrive at the airport, as it isn't really reasonable to expect the user to have not force quit an app they may not have used for weeks or even months. Are there any supported mechanisms to resume beacon monitoring after a force-quit? Not specifically, no. The main issue here is th

Thanks for the post and thanks for the feedback number. Looks like you didn’t run it under the Xcode Instruments to see if the memory is a memory leak or something else? Providing a Instrument trace will help you as well as in the feedback to see why is the app loading so much memory. Newer macOS versions may employ more advanced rendering techniques that utilize additional memory for caching and effects to improve visual fidelity and responsiveness if available. Changes in how macOS manages background apps and pre-fetches data might contribute to higher baseline memory usage. If your app handles images or textures, ensure that caching mechanisms are efficient and purge unused resources promptly and here using instruments will help you to know what objects are being loaded. Employ Xcode’s Instruments, especially the Allocations and Time Profiler tools, to pinpoint where excess memory is being used and identify any unexpected overhead introduced by system frameworks. Hope you go over the path to use I

Hi, the runtime warnings are accompanied by a backtrace associated with the warning in the Issue Navigator. Can you uncollopase the chevron in the Issue Navigator and share the backtrace so that we can see which framework is the warning originating from ?

The problem still exists on iOS 26.3

This isn’t an answer to the question you asked but… [quote='815452021, Philipss, /thread/815452, /profile/Philipss'] When launching an app in a Rosetta simulator [/quote] See my response on this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I didn’t reply earlier because I didn’t see your comments )-: See tip 5 in Quinn’s Top Ten DevForums Tips. Regarding FB20753534, I’ve got no info to share on that front. I can’t talk about Apple’s internal processes and I can’t offer predictions about The Future™. Having said that, iOS 26 has been shipping for a while now, so even if this behaviour changed today you’d still have to decide what to do about all the existing iOS 26 installs. And once you make that decision, which admittedly might involve some tough choices )-:, there’s less pressure on you getting a resolution from Apple. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='876243022, disinghal, /thread/811887?answerId=876243022#876243022, /profile/disinghal'] It's MacOS [/quote] D’oh! Yes, sorry, I had my iOS coloured glasses on )-: [quote='876243022, disinghal, /thread/811887?answerId=876243022#876243022, /profile/disinghal'] We are calling some custom extension using Apple's enterprise single sign-on feature. [/quote] So your packet tunnel provider is using URLSession to issue a request that’s triggering enterprise SSO which then ends up calling an SSO app extension? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com