I'm stunned that there doesn't seem to be the most basic way of checking whether 'Voice Control' is running, and that this has been nonexistent for years. People were even hoping that maybe it would've been introduced in iOS 13.0: https://stackoverflow.com/questions/57779170/ios-13-how-to-detect-voice-control-is-running. We're now at iOS 17.0 and this is still such a vital feature to have.

Wow, no reply in 7 years! Maybe I can help :) Rather than rely on VoiceOver to interpret your strings, what if you rely on explicitly spelling out the period so an accessibility label would comprise "four point twenty nine out of five stars"? One way to do this is explicitly set a MeasurementFormatter's numberFormatter property with a new NumberFormatter instance whose numberStyle property is set to .spellOut: class UnitRating: Dimension { override static func baseUnit() -> Self { return UnitRating.star as! Self } static let star = UnitRating( symbol: "star", converter: UnitConverterLinear(coefficient: 1.0) ) } final class VoiceOverSeparatorAnnouncementWorkaroundTest: XCTestCase { func testVoiceOverAnnouncingPoint() { let measurementFormatter = MeasurementFormatter() measurementFormatter.unitOptions = .providedUnit measurementFormatter.numberFormatter = { let formatter = NumberFormatter() formatter.numberStyle = .spellOut return formatter }() measurementFormatter.unitStyle = .long XCTAssertEqual( measurementFormatter.string( from: .init(value: 0.0, unit: UnitRating.star) ), "zero star" ) XCTAssertEqual( measurementFormatter.string( from: .init(value: 1.0, unit: UnitRating.star) ), "one star" ) XCTAssertEqual( measurementFormatter.string( from: .init(value: 0.1, unit: UnitRating.star) ), "zero point one star" ) XCTAssertEqual( measurementFormatter.string( from: .init(value: 5.1, unit: UnitRating.star) ), "five point one star" ) } } While the example above does not take localization into account, I imagine this can be a starting point (assuming this is still a problem for you LOL)

Ah, I see I'm not the only one experiencing this problem!

Perhaps this was all just a misunderstanding and a bug that wasn’t caught from any of the unit tests, or there’s a new API that we will need to migrate towards to get the same functionality. I understand that not every release is perfect and that’s okay! Hopefully we get some documentation so our paying customers can be happy with the functionality they’ve come to expect from the products we developers create for the App Store, especially for those of us that make music apps whose customers solely need tempo-changing functionality to get better as musicians (what’s the point of a slow downer app without this functionality?). However, if iOS 15.4 intentionally prevents developers from manipulating the speed of music in Apple Music and does not intend on adding this functionality back in the future, Apple owes developers that make music apps that rely on this functionality an official announcement at the very least. A timeline would’ve been ideal. Not a rug pull like this! I’m working on an app that depends on this functionality. If Apple does not right its wrongs, I fully intend on giving my users a way to air their grievances on your forums. Why should I be the one to receive negative reviews because of how Apple rolls out feature changes like this? Nope; I will definitely be taking the time to design a simple, intuitive UX in my app to ensure my users can channel their frustrations onto the group that solely deserves their condemnation.

I have not had any luck using animation when using the new UIButton API made available for iOS 15 :( Of course, I appreciate all the amazing work that's gone into iOS 15! However, it's the subtle animations like being able to change a UIButton's scale transform when a button is pressed, or animating a backgroundColor update that delights users. It's so close to being perfect and unfortunately, what may appear small is the reason I'll probably have to forgo adopting the new API for a long, long while.

Wow this just started happening to me too! It was literally working 12 hours ago :( Edit: was just a coincidence. This is what happened to me and how I fixed it. My code was using a SwiftGen auto-generated Swift file containing enums. Because I changed the output filename last night and deleted the originals on the command line but not the actual Xcode IDE (which means Xcode didn't realize this change), whatever Xcode generates will be corrupt. Ideally, Xcode would encounter a build failure. Because it didn't, then the failure would have to turn up when loading it onto the simulator. This explains why the error made no sense, since Xcode kept saying that the path was erroneous when in fact the path DID exist. Once I deleted the references to the non-existent files and added the new files, Xcode then expectedly complained that the old enum didn't exist. After I made those updates and ran the build, it worked.

It appears that I found a solution! However, I don't know if it is a big no-no since I've read on forums that it's private and can be unsupported at any time: // PkgA.swift @_exported import PkgB Is there a way to get that same kind of functionality that is more reliable?

For anyone who reads this in the future, I spoke with an engineer in a 1-on-1 session for WWDC and found that this is not possible with AVAudioEngine; it looks like AudioStretch use their own DSP to do this. Makes sense since they also have an Android app with this feature. Thank you Apple and WWDC!

Thank you for your response. I don’t know why I thought there was a limit at 0.25. However, it does seem to not go past 1/32, and there is an app called AudioStretch that can not only play at 1%, it can also play a point in time indefinitely and even backwards. Can AVAudioUnitTimePitch do this same thing as well?