We are unable to process your request

I am new to the apple developer program...The software is entirely written in python and includes ffmpeg That's probably the single most difficult type of software you can try to build on a Mac. We are currently adding the signing and notarization of the app to our github workflow. Have you tried to do any of this not using a GitHub workflow? Because I hate to tell you this, but most people who experience notarization problems get stuck at a much later stage. You haven't got to the difficult part yet. I would like feedback about if there is a fundamental flaw in our approach for signing and notarizing our application, so that we can identify it. I recommend skipping all the automation stuff until you confirm that your notarized app actually runs. Notarization adds a lot of runtime checks that are particularly difficult for Python apps to pass. I would appreciate some guidelines about how long to expect this notarization step to take until we can get notarization to finish within 10s of minutes, as we have a h

You can use BGTaskScheduler, especially BGProcessingTask to perform long running actions, including CoreBluetooth data transfer, but you can't have defined schedules for background tasks. They will be run by the system whenever it is appropriate to do so, and not being run is also a possibility. You may want to read about iOS Background Execution Limits before deciding to depend on background tasks. In any case, I am not sure how this will help. With Bluetooth state restoration, and for being woken up from suspended state there is indeed a ~10 second time limit, but that is per Bluetooth event, not for the whole task you are trying to do. If you need a minute to download the whole set of data from the device, you would not be doing that all at once anyways. The device will be writing the data in pieces, and as long as the subsequent writes to a notifying characteristic happens within the ~10 second limit, your app's time will be topped up. So, as long as you take less than 10 seconds to process each

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.