Environment→ ・Device: iPad 9th generation ・OS:**iOS17.5.1 ・Printer model:EPSON PX-S730
Current issues→
An error message is not returned from the printer if a print job is sent while the printer is off.
Problem Description→
The AirPrint feature on an iPad 9th generation running iOS 17.5.1 is being used with an EPSON PX-S730 printer. When sending a print job while the printer is off, the Print Center shows the ongoing printing job, but the printing cannot be executed because the printer is off.
What I want→
I would like an error to be returned when I submit a printing job while the printer is off.
Test code:
Note: printController.print response is completed but Print Center status is printing
let printInfo = UIPrintInfo(dictionary: nil)
printInfo.jobName = "Print Job"
printController.printInfo = printInfo
let pdfURL = Bundle.main.url(forResource: "sample", withExtension: "pdf")!
printController.printingItem = pdfURL
let printer = UIPrinter(url: printerUrl)
printController.print(to: printer, completionHandler: { [self] printController, completed, error in
if(error != nil){
print("error").
}else if completed{
print("completed"). //this scenario handles completion response
}else{
print("cancel")
}
})
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Environment→ ・Device: iPad 9th generation ・OS:**iOS17.5.1 ・Printer model:EPSON PX-S730
Current issues→
01). After canceling a print job in the Print Center, the Print Center screen on the iPad does not close.
02). When the printer is turned on and a new print job is sent, the Print Center shows the ongoing waiting job instead of proceeding with printing.
Problem Description→
The AirPrint feature on an iPad 9th generation running iOS 17.5.1 is being used with an EPSON PX-S730 printer. When sending a print job while the printer is off, the Print Center shows the ongoing printing job. If the print job is canceled in the Print Center, the Print Center screen on the iPad does not close. After turning on the printer and sending the print job again, the Print Center shows the ongoing waiting job.
What I want→
The Print Center screen on the iPad to close automatically after canceling a print job.
Test code:
Note: printController.print response is completed but Print Center status is waiting
let printInfo = UIPrintInfo(dictionary: nil)
printInfo.jobName = "Print Job"
printController.printInfo = printInfo
let pdfURL = Bundle.main.url(forResource: "sample", withExtension: "pdf")!
printController.printingItem = pdfURL
let printer = UIPrinter(url: printerUrl)
printController.print(to: printer, completionHandler: { [self] printController, completed, error in
if(error != nil){
print("error").
}else if completed{
print("completed") //this scenario handles completion response
}else{
print("cancel")
}
})
I'm developing two native apps and one is a authentication app and other one is business app. In the main flow if buisness application is on the foreground and did nothing for at least 10 minutes it will automatically time out and redirect to the autentication app for token refresh. In this flow universal link redirect to the authetication app without opening Safari.
But if i execute the below flow buissness app redirect to the Safari.
Buisness App In Foregorund → Displaying a OS screen while app is in Foreground(Like Push Notification Center) → On this satate leave device for 10 minutes → Buisness app will automatically timeout and rediret to Safari(In safari 「NoSuchKey The specified key does not exist.」message is displaying but authentication app Universal link Start button is showing) → After click the Universal Link start button in Safari Authentication App open.
I use the below code to start the Universal Link:
if let url = URL(string: path) {
UIApplication.shared.open(url)
}
So i would like to know is there a special reason that when Displaying a OS screen while app is in Foreground(Like Push Notification Center) affect the normal flow of Universal redirection to another app?
Environment→ ・Device: iPad 10th generation ・OS:**iOS18.3.2
I'm using AVAudioSession to record sound in my application. But I recently came to realize that when the app starts a recording session on a tablet, OS automatically sets the tablet volume to 50% and when after recording ends, it doesn't change back to the previous volume level before starting the recording. So I would like to know whether this is an OS default behavior or a bug?
If it's a default behavior, I much appreciate if I can get a link to the documentation.
Environment→ ・Device: iPad 10th generation ・OS:**iOS18.3.2
We're using AVAudioPlayer to play a sound when a button is tapped. In our use case, this button can be tapped very frequently — roughly every 0.1 to 0.2 seconds. Each tap triggers the following function:
var audioPlayer: AVAudioPlayer?
func soundPlay(resource: String, type: String){
guard let path = Bundle.main.path(forResource: resource, ofType: type) else {
return
}
do {
audioPlayer = try AVAudioPlayer(contentsOf: URL(fileURLWithPath: path))
audioPlayer!.delegate = self
try audioSession.setCategory(.playback)
} catch {
return
}
self.audioPlayer!.play()
}
The issue is that under high-frequency tapping (especially around 0.1–0.15s intervals), the app occasionally crashes. The crash does not occur every time, but it happens randomly — sometimes within 30 seconds, within 1 minute, or even 3 minutes of continuous tapping.
Interestingly, adding a delay of 0.2 seconds between button taps seems to prevent the crash entirely. Delays shorter than 0.2 seconds (e.g.,0.15s,0.18s) still result in occasional crashes.
My questions are:
**Is this expected behavior from AVAudioPlayer or AVAudioSession?
Could this be a known issue or a limitation in AVFoundation?
Is there any documentation or guidance on handling frequent sound playback safely?**
Any insights or recommendations on how to handle rapid, repeated audio playback more reliably would be appreciated.
We have a login flow where the user authenticates in Safari, and at the end of the process the authentication server redirects back to our app using a Universal Link.
On most devices, the app opens automatically without any confirmation banner.
However, on several iPads, Safari always shows the “Open App A?” banner after the redirect. The user must tap Open every time. Other devices running the same iOS version do not show this issue.
Expected Flow (working devices):
Start authentication
Safari login
Authentication server redirects using a Universal Link
App A opens automatically
Problematic Flow (several iPads):
Start authentication
Safari login
Authentication server redirects using a Universal Link
Safari shows “Open App A?” confirmation banner
User must tap Open
App A starts
Questions:
Is this a known issue in iOS?
Or is this expected behavior under certain conditions (i.e., is there a specific Safari/iOS specification that causes this banner to appear)?
Is there any way to prevent Safari from showing the “Open App A?” banner and allow automatic redirection?
*This issue did not occur on iOS 16, but it started appearing after updating to iOS 17.
Devices :
iPad 9th Gen/iPad 10th Gen
Hello,
We are experiencing a behavior change with WKWebView related to upgradeKnownHostsToHTTPS.
Current application, we explicitly disable automatic HTTPS upgrades:
let config = WKWebViewConfiguration()
config.upgradeKnownHostsToHTTPS = false
Observed behavior
iOS 17.5 (built with Xcode 15.3)
http:// image URLs are not automatically upgraded to https://, and the behavior works as expected.
iOS 18.5 / 18.6.x (built with Xcode 16.4)
http:// image URLs appear to be automatically upgraded to https:// by WebKit, even when upgradeKnownHostsToHTTPS is explicitly set to false.
This behavior occurs for subresource requests such as <img src="http://..."> inside a WKWebView.
Question
Has the behavior of upgradeKnownHostsToHTTPS changed in iOS 18 / Xcode 16?
Is this property now ignored for certain types of subresource requests (e.g. images), or overridden by new WebKit security policies such as mixed-content HTTPS upgrades?
Any clarification or official guidance would be greatly appreciated!.
I have a question regarding the behavior of AVAudioSession.sharedInstance().outputVolume.
Observed behavior:
When the app is in the foreground, I read audioSession.outputVolume (for example, 0.1).
The app is then moved to the background.
While the app is in the background, the user changes the system volume using the hardware buttons (for example, to 0.5).
When the app returns to the foreground, audioSession.outputVolume still reports the previous value (0.1).
From my testing, outputVolume only seems to update when the system volume is changed while the app is in the foreground. Volume changes made while the app is in the background are not reflected when the app returns to the foreground.
Questions:
According to Apple’s documentation for AVAudioSession.outputVolume:
“The systemwide output volume set by the user.”
https://developer.apple.com/documentation/avfaudio/avaudiosession/outputvolume
However, based on our testing on iOS 18.6.2 and iOS 18.1, the observed behavior seems to differ from this description.
Questions:
The documentation states that outputVolume represents the system-wide volume set by the user. In our testing, the value does not reflect volume changes made while the app is in the background and only updates when the app is in the foreground.Is this the expected behavior of AVAudioSession.outputVolume?
Is there any other recommended way in Swift to retrieve the current system volume that reflects user changes made both while the app is in the foreground and while it is in the background?
Any clarification on the intended behavior or recommended handling would be greatly appreciated.