Ferrite 2.6 can record in stereo with the built-in mics on some iPhones. There’s a little confusion out there about how it works, which is understandable, since iPhones don’t have mics set up for stereo recording! Here’s a thread about it, if you’re interested: (For clarity: Ferrite has always been able to record in stereo when using an external stereo microphone, or with a stereo USB Audio Interface. This is just about the mics built into the iPhone itself.)

Displacement activity: During R&D phases, I often end up with a bunch of testbed apps on my devices, trying out different tech & so on. Since they all have the same default template icon, it can be hard to pick them apart at a glance. So: …I procrastinated my way into hacking together a quick SwiftUI-based Mac app, where I can drag-and-drop any glyph from the Mac's Character Viewer palette & it’ll instantly blueprint-ify it. Can then export a single 1024px image, or complete set of sizes ready to drop into Xcode.

Ferrite 2.5 is now rolling out across the App Store. The three most visible changes? Enhanced trackpad/mouse support, Presentation Mode, and Deleted Items.

(Ferrite continues to work on iOS 12.4 for now, but you’ll need iOS 13.4 to take advantage of all the latest features) Presentation Mode is a new feature to help folks teaching others how to use the app. It can be tricky to show gestures & keyboard shortcuts, especially when teaching via video (e.g. due to social distancing…). So Presentation Mode shows them on-screen. Customisable too:

New update to Ferrite has been released — mostly minor fixes, performance improvements, that sort of thing. It does also include a big update to the User Guide, now featuring a full search facility: You can just type some text and it'll search for it throughout the guide — but it'll also suggest chapters or keywords you might be interested in:

If you want to make a Mac app, there are _4_ primary APIs you could be using, in a sorta 2x2 grid: AppKit, UIKit (w/Catalyst), SwiftUI-in-AppKit, SwiftUI-in-UIKit. It’s a complex mess of what each does/doesn’t support — figuring out which to use for any given UI is trial & error I’ve been trying to make one relatively simple bit of UI (in a standalone testbed app) for days. Every time I think I’m on a roll, I bump into a different wall of missing functionality. I try different implementations. I try different designs that don’t need same features.

Trying to get stuff ready for the iOS 13 launch that’s (probably?) going to happen in the next week or so. Going through mopping up text translations. And I find that, wow, localised text in "static cells" table views seems to be broken when built against iOS 13 SDK Even when running on iOS 12. Other text translates fine, but table cell text is ignored. Created a minimal repro project, previews A-OK in Xcode, broken on-device.

FB7198417

Porting Pro iPad apps to Mac: A Thread.

Some of you may have heard that Apple have a new technology to make it easier to bring iPad apps to the Mac. You may even have heard that it's "just one click". You might be excited for your favourite iPad apps to come to the Mac. Before you get too excited though, some things to be aware of.

It's never that straightforward in real life. For a start, to develop these iPad-on-Mac apps requires macOS 10.15 "Catalina", which isn't out yet, and the beta is... apparently giving some people serious issues

Another Ferrite update rolls out on a Saturday when no-one will notice 🙄 Ah well. This one focuses on import/export enhancements, and should bring significant speed-ups to MP3 export on modern devices, by taking advantage of the many processor "cores" they have. Other improvements include support for .WAV file "markers", customising the export format for projects (or better yet, templates, so you can always use a particular export setting for a particular podcast), and splitting multiple audio tracks out of a video.

Since there seems to be another squall of #swiftlang hate passing overhead (e.g.

https://twitter.com/daringfireball/status/1006268593170984961

) I just want to take a moment to thank the Swift devs & say how much I like the language. Contrary to the linked article, it’s made my business _more_ tenable, not less. Are there changes I’d like to see? Of course! No language is ever perfect — but that’s why there’s a community process for enhancements.

have spent the past fortnight or so buried under iOS 11 drag & drop APIs.

not surfaced yet, but can see cracks of daylight somewhere above. the APIs themselves are (mostly) pretty good! but if you want to support them _properly_, it really unleashes the shoggoths with a vengeance

When proposing changes to #SwiftLang every time you think “It’s okay, we’ll write a migrator to handle the changes automatically”, remember it’s not actually true for production code, because the underlying compiler isn't reliable enough in the face of type errors. SEG11 all over

Wondering if #SwiftLang 3 migration was really handled the right way. I get there are advantages to "ripping off band-aid" in one go, but… I suspect combining certain changes increases migration difficulty exponentially, not linearly. Multi small migrations might've been better?