Archive for June 2, 2020

Tuesday, June 2, 2020

Exploring Hearing Aid Integration in iOS

Klaus Wirtz:

I learned that besides normal hearing aids, there are “Made for iPhone” (MFi) hearing devices that are directly recognized and controlled by iOS. An Apple support document lists manufacturers and products that have earned the MFi label. Of course, as an Apple user, I had to get an MFi pair. After trying several different devices, I finally settled for a pair of Pure 312 3Nx by Signia. In this article, I describe my experience in setting up and using these devices.

Why doesn’t macOS support these devices?

Clario’s MacKeeper

Howard Oakley:

Several weeks ago, I expressed surprise that MacKeeper had now been notarized. Following discussions with the good folk at Clario who now own and develop this product, and in the spirit of fairness and objectivity, this article looks at the current version of MacKeeper, at what it does, and how it has changed.


The most obvious question is why, under its new ownership, anyone would want to continue selling a product, however good it might be, under a name which to many of us is synonymous with PUP.

It’s a good question. It sure seems suspicious that the notarized installer package is just a shell that downloads an encrypted binary and sends your Mac’s serial number to their server over an unsecured connection. However, I verified that the final .app file that you end up with is notarized.

Alun Baker has explained that Apple wasn’t prepared to let MacKeeper simply undergo its normal notarization checks, and looked thoroughly at historical issues such as Clario’s business associates and marketing methods as well.

What does this mean? I thought we were told that notarization was a purely automated system, not a way of extending App Review outside of the Mac App Store. Baker seems to be saying that Apple wouldn’t notarize the binary without first investigating historical non-code aspects of the business. That’s really scary. But then, if that’s the standard, how did an app with MacKeeper’s history pass? If Apple was concerned about the history, Clario’s argument would have to be that they’ve changed their ways. Regardless of their intentions, Clario would say that they have. Yet that can only be assessed after the app becomes available and we see what they do with it. So what did this extra review accomplish?


Update (2020-06-03): See also this thread with Jeff Johnson.

Update (2021-11-26): Lance Whitney:

The new owner has pulled back on the aggressive marketing schemes and rid itself of dubious affiliates. The software itself received a good grade from AV-Test as well as ISO 27001 certification and notarization from Apple. Assuming the company and product have learned from past mistakes, is it worth giving the suite another shot at this point?

Thomas Reed:

Calling Clario a “new owner” is a bit of a stretch. Look at the C-level execs of Clario, and you’ll notice they were once the C-level execs of Kromtech. Clario is nothing more than a whitewash to cover up the past.

Jeff Johnson:

Ask yourself why any legitimate company would acquire a product with a super scummy reputation. It would be insanity.

BBEdit 13.1

Bare Bones Software:

The Markdown custom language preferences (via Languages -> Language-specific settings) provide control over the default Markdown renderer, used for Preview in BBEdit as well as exporting to HTML.


There’s a new command on the Text menu: “Run Unix Command”. This opens a sheet into which you can enter a Unix command line, and choose where the output goes (either replacing the front document’s selection/contents as a text filter would, or to a new document).

This can be extremely useful for quick (or simple) “one shot” Unix commands that aren’t worth the effort of writing a filter.


Added a new text transformation: “Convert Escape Sequences”. […] This command transforms text by replacing various commonly used character escape sequences with their actual characters[…]


Rebuilding Slack on the Desktop

Mark Christian and Johnny Rodgers, writing last year (also: Hacker News):

Today, after more than half a decade of hyper-growth, Slack is used by millions of people with larger companies working with more data than we ever could have imagined when we first started. Somewhat predictably, a few internal cracks were starting to show in the desktop client’s foundation. Additionally, the technology landscape had shifted away from the tools we chose in late 2012 (jQuery, Signals, and direct DOM manipulation) and toward a paradigm of composable interfaces and clean application abstractions. Despite our best efforts to keep things snappy, it became clear that some fundamental changes would be required to evolve the desktop app and prepare it for the next wave of product development.


However, moving to a multi-workspace architecture was quite the undertaking. We couldn’t expect every function call to pass along a workspace ID, and we couldn’t just set a global variable saying which workspace was currently visible since plenty of things continue to happen behind the scenes regardless of which workspace the user is currently looking at.

The key to our approach ended up being Redux, which we were already using to manage our data model. With a bit of consideration and the help of the redux-thunk library, we were able to model virtually everything as actions or queries on a Redux store, allowing Redux to provide a convenient abstraction layer around the concept of individual workspaces. Each workspace would get its own Redux store with everything living within it — the workspace’s data, information about the client’s connectivity status, the WebSocket we use for real-time updates — you name it. This abstraction created a conceptual container around each workspace without having to house that container in its own Electron process, which was what the legacy client did.

Ben Sandofsky:

Rather than write two separate native apps, Slack has now written a cross-platform app four different times.