We are unable to process your request

Thank you for your post. I would like to request two favors from you. First, could you create a bug report and provide me with the Facebook number? Second, could you add yourself to this thread and monitor it? https://developer.apple.com/forums/thread/773818 Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Thanks again for everything. Looking forward working with you to resolve it quickly. Albert Pascual
  Worldwide Developer Relations.

Same issue in my app. My app had been working for 9 years but started showing this UISlider bug in iOS 26. Below used to work previously: slider.addTarget(self, action: #selector(sliderValueChanged(sender:event:)), for: .valueChanged) @objc func sliderValueChanged(sender: UISlider, event: UIEvent) { print(Slider: (slider.value), (event)) label.text = Value: (sender.value) switch event.allTouches?.first?.phase { case .began: print(began) case .moved: print(moved) case .ended: print(ended) case .cancelled: print(cancelled) default: break } } But, in iOS 26, the event being passed is uninitialized and so, event.allTouches is always nil. So, I am unable to detect what phase of the event it's in. Note that changing from UIEvent to UIControl.Event is not a solution as it's also just UIControlEvents(rawValue: 0), so unable to find what phase it's in. I have reported this as a bug: https://feedbackassistant.apple.com/feedback/20727378 EDIT: For now, the below workaround works: slider.addTarget(self,

Thanks for the recommendation; I've added extra information. Basically my main concern is to isolate unstable code to make the app more stable, but also extensions are running as separate process, which would allow me to add a lot more commands to the terminal app. I also have potential uses in mind if there is no memory limit, and if we can share extensions between apps, but I think these are hills too large to climb at the moment.

@WeAreAllSatoshi Thanks for the reply and thank you for providing this information. I recommend monitoring the report as the engineering team will be sharing updates there. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

Thanks for the post. Your inquiry appears to pertain to a developer account and looks like you already talking to the developer Apple Support team that created those limits. I would recommend to file a enhancement request. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? I trust you will achieve a favorable resolution. I extend my best wishes for your success. Albert Pascual
  Worldwide Developer Relations.

Since we're talking about debuggers here, I just want to say that having DWARF (1) in your user name is excellent — thanks for the chuckle! As to attaching your custom debugger to a process with devicectl, this is not possible with the currently available commands provided by that tool. Our folks who work on the tooling around that command are interested in hearing what your needs are, so please send them some information on the type of functionality you need through Feedback Assistant. Once you've done that, please post the FB number here for reference. — Ed Ford,  DTS Engineer (1): https://dwarfstd.org

Just following up as I am still in need of a resolution. Quinn was handling this from the code/operation side, so wasn't really tracking this thread. However, there are two common issues here from the framework usage side. The first one is that by calling scheduleAppRefresh at app launch, you're unintentionally preventing your own task from reliably firing. Basically, here is what happens: Your app stopped running at some earlier point in the day for normal reasons (free up device memory, etc.). It came time to run your task, so the system launched your app. Your app started up, you configured the background task framework, then ran scheduleAppRefresh. scheduleAppRefresh scheduled your task to run 10 mins from now. Duet (the daemon that supports the background task framework) assessed your task state, determined that you had not tasks ready to run (since the next one isn't runnable for 10 min...) and suspended your app. Secondly, I think you probably want to use BGProcessingTask, NOT BGAppRefreshTask. These t

@neil95 This is great!! Thank you so much for this. I see you included a link to the code. I would recommend to zip it and upload it into the bug itself. You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. I'll keep an eye out for issue and fix. Albert Pascual
  Worldwide Developer Relations.

Hi @arthurfromberlin Thanks for the response and detail. Can you attach a sysdiagnose to the feedback request? You can find instructions on how to capture a sysdiagnose here. The issue is tricky to debug since it only happens via TestFlight so the logs will help.