Frankly, I wasn't making much headway before, hardly managing to keep up with changes to Objective-C, and significant changes to the frameworks, like ARC, and to the developer tools.
Now there's a whole new language (Swift) to learn, and learn it I will, even if it means putting off everything else until I've done so.
Even if, as I expect is the case, Swift can't yet be used with Core Audio, which is a C-based API, it will be otherwise applicable, and important for me to get an early start with it, rather than trying to put off the inevitable change.
Besides, there's quite a bit to like about Swift. It's clear that a lot of thought has gone into its design, and it continues the trend, which began with the addition of declared properties to Objective-C, of reducing the amount of code needed to get something done.
Beyond that, from what I've seen so far, it strikes me as being closer to the metal, not of the machine, but of the essence of programming. I presume this is a result of it evolving out of compiler technology, rather than the compiler being created to fit the language. This impression gives me confidence that what I haven't yet seen will also make sense to me.
Understand that I wasn't one of those who was easy to convince regarding the need for a new language. I like both C and Objective-C. In particular I like being able to use numerical variables as logical values (zero being false and everything else being true), and, while I haven't used it much, pointer arithmetic strikes me as an elegant solution. Admittedly, it took me more time and fretting than it should have to wrap my mind around expressions like primativeValue** or &scratchpadMemory, but I did eventually catch on, and now I appreciate the precise control they allow. On the other hand, having to use malloc() to obtain scratchpadMemory is a pain.
But this is all moot. Apple wouldn't have introduced Swift with such fanfare if it weren't destined to be the future. There are already Swift versions of frameworks that worked with Objective-C, and lower-level frameworks, like Core Audio, are sure to be given the same treatment or replaced with updated versions that are Swift compatible, and that's a trend I don't care to buck.
So, RatioKey 2.0, or whatever it ends up being called, if and when I get it done, and provided that it's accepted for distribution by Apple, will be a complete rewrite, using Swift, and probably targeted for iOS8, or, realistically, maybe even iOS9.
Thank you for your patience!