file uri scheme

I recommend filing an enhancement request asking for documentation for these items. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

And when PTT notification arrives, saving the URL to the audio file in incomingPushResult, then downloading and playing that sound using AVAudioPlayer when didActivate is executed. It's working fine on the foreground, but when the app goes to the background, incomingPushResult is called as expected, but didActivate is not for some reason. Am I missing anything in my setup? Yes. The issue here is that you can't use AVAudioPlayer, as it does its own AudioSession activation. More specifically: It's working fine on the foreground. It works in the foreground app because the foreground app has inherent access to the audio system and can do whatever it wants. However: when the app goes to the background, incomingPushResult is called as expected, but didActivate is not for some reason. ...what happens in the background is that the same activation attempt then occurs and either fails entirely or succeeds (partially) but is then disrupted by callservicesd's own activation. Unfortunately, you'll ultimately end

I understand now, thanks for your patience. Unfortunately this means that the only way for this to work is having the Gurobi libraries' code, and incorporate mmap there, because that's where the memory-heavy node-files are created and put in memory. Too bad this is not open-source software, and therefore this is impossible. Is there an alternative to mmap to perhaps squeeze some extra space in the disk? I was wondering if renicing the process to, say, -20, can have some indirect benefits...

Thanks so much again for your time and effort, Kevin! I did look into the documentation and tried different approaches, but none seem to work. I also found a BLE sample project on the Apple Developer Documentation, and it is also terminated after some time. Yes, and that's expected. Across most/all our background APIs, the focus isn't on ensuring that processes never terminate but is instead on relaunching the process and returning it to normal operation. Case in point, this is the real problem here: However, unlike the documentation states, I wasn't able to implement State Restoration and receive Characteristic updates once the app is terminated because of Memory Pressure. Why? Is the problem that you're not being relaunched or is state restoration failing? What happens from the accessory side? One side note here is that what triggers the relaunch is activity from the BLE accessory, so if your accessory never generates activity back to the iOS device, then you may not relaunch. May I suggest updating the doc

Thanks for the post. Very interesting. My 5 cents if I may. It is crucial to prioritize user experience by ensuring consistency and stability in production environments. This is why feature flags, such as UIDesignRequiresCompatibility, are typically controlled by developers rather than end-users and are not exposed for arbitrary user-based toggling in production builds. This key allows developers to test the feature but does not provide a way to deploy it as it can be turned off, as explained in the documentation. Therefore, developers should refrain from rolling out new designs broadly before testing them thoroughly. Controlled feature flags enable developers to incrementally roll out new designs to ensure stability. By monitoring feedback and performance, developers can address issues before a full deployment. Apps submitted to the App Store should not contain hidden features or debugging options that alter the intended user experience for the general public. In development, set up different build schemes

Apologies if I misunderstand things completely. I am no developer, so memory management is completely foreign to me. OK. So, stepping back for a moment, I think what's helpful to understand is that one of the VM system’s basic primitive operations is designate that a range of address space corresponds to the contents of a file. That process is called mapping a file and is how, for example, executable files are loaded into memory so that they can be executed. That is, what part of what running an executable actually means is map the contents of that file into memory and start executing at a specific point. Similarly, the basics[1] of swap files are simple create a file and designate which parts of it correspond to specific memory ranges. Mapping VM address space to file ranges with what mmap() does. That is, a low-level mach memory function like vm_allocate() (what malloc calls within its implementation): https://web.mit.edu/darwin/src/modules/xnu/

Can you file a feedback report with your model and a test / set of steps to reproduce?

Thanks for the post and the details, the error is not about having the latest version of Xcode, looks like you do have it as Xcode Version 26.2 (17C52). The error message you're encountering, ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing., indicates that your app submission to App Store Connect is missing a required folder named SwiftSupport. So this is extremely interesting to me for sure. When archiving your app, ensure there are no build warnings about folders. Go to > , and then check the Organizer to ensure everything is correctly packaged. If your app uses Swift Package Manager, ensure that all packages are updated and correctly integrated. Sometimes issues arise from improperly configured packages? I believe this issue is always about packages you are using. Can you check that? read until the end where a post from an Apple engineer will give you more information. If you're manually managing your app bundle, ensure the folder is present in the archive's structure. It should b

Thank you Justin. There's one more quirk I've observed - Apple doesn't expose the analog proximity sensors on the trigger or grip buttons. These are the sense part of Sony's Playstation VR Sense Controller branding ;) In OpenXR / SteamVR with the Playstation VR2 these paths as independent triggers i.e. /user/hand/right/input/r1_sensor, /user/hand/right/input/r2_sensor, /user/hand/right/input/l1_sensor, /user/hand/right/input/l2_sensor, corresponding to the grips & triggers. Yes, this means the l2/r2 triggers have TWO analog capabilities - one for the analog relative touch/proximity, and one for the analog degree of trigger pull (which can be accessed via the .value on the button). Since this is an entirely new thing, should I update my existing feedback or file a new one?

Hi Kevin, Q - How we know didFinishLaunchingWithOptions is not being called at user-visible launch time We agree that the most important question here is when the app was actually initialized versus when the user opens it. To address this, we have implemented explicit lifecycle logging at the very earliest entry points of the app, including: A log at process start Logs at the very beginning and end of application(_:didFinishLaunchingWithOptions:) Logs for all other UIApplication lifecycle callbacks We log all lifecycle events (including process start and didFinishLaunchingWithOptions) using a dedicated serial queue and persist them directly to disk. In simplified terms, our logging flow is: Logs are written via a serial logQueue Each log entry is appended to a file in the app’s Documents directory Logs include: ISO timestamps Explicit lifecycle markers The process ID (pid) This means: Logs are persisted to disk, not memory Logs survive suspension and backgrounding We do not clear or rotate logs on ba

I have verified that in Xcode, my main target Runner has a bundle identifier of com.mycompany.pushnotifications and my extension target has a bundle identifier of com.mycompany.pushnotifications.pushnotificationsmessageextension I unzipped my .IPA file and see Payload/Runner.app/pushnotificationsmessageextension.appex In my uncompiled app, I looked in the pushnotificationsmessageextension/Info.plist file and see the following NSExtension NSExtensionPointIdentifier com.apple.usernotifications.service NSExtensionPrincipalClass $(PRODUCT_MODULE_NAME).NotificationService