Archive for July 3, 2019

Wednesday, July 3, 2019

SummerFest 2019 for Indie Mac Apps


Your inspiration doesn’t come from a factory. Neither does artisanal software.

For a limited time, we’re offering you a great price on great software, right at the workshop door. No ridiculous bundles, no silly gimmicks. Great software, great support, great (but sustainable) prices.


These are terrific tools for thinking, writing, organizing, and delivering your ideas. Sure, you can manage with less – but why would you want to? Each of these tools is carefully crafted and maintained by a small, dedicated team with vision and determination.

A great list of quality apps for ~25% off, including ones I’ve used a lot like BBEdit, TextExpander, PDFpen, and my own SpamSieve.

altool 4.0

Rosyna Keller:

Xcode 11.0b3 includes a major update to altool (used for notarization), altool 4.0, with some awesome new features.


First, altool actually has a man page now (man altool) accessible after new Xcode 11b3 is installed.

altool supports a new --verbose argument that’s my type of verbose (it’s overly verbose to the MAX!) that’s useful in debugging issues, filing radars, and watching progress.


Another new argument (as seen in the previous screenshot) is the --transport argument that allows you to specify the upload method order altool/Transporter tries.


The DAV (WebDAV) method is extremely slow but explicitly specifying it will prevent altool from attempting the other transport methods doomed to fail if UDP is blocked.


altool 4.0 now supports concurrent uploads from the same host. You no longer have to wait for a submission to return a RequestUUID before starting another submission in a new Terminal window.

A lot of third-party developers were having issues creating a keychain item for use with -p "@keychain:<Keychain Item>" so altool 4.0 has a new convenience command, --store-password-in-keychain-item <New Item Name>, that will create it in the iCloud Keychain for you!

These sound like great improvements.


Superhuman Embeds Tracking Pixels in User E-mails

Mike Davidson (via Hacker News):

It is disappointing then that one of the most hyped new email clients, Superhuman, has decided to embed hidden tracking pixels inside of the emails its customers send out. Superhuman calls this feature “Read Receipts” and turns it on by default for its customers, without the consent of its recipients. You’ve heard the term “Read Receipts” before, so you have most likely been conditioned to believe it’s a simple “Read/Unread” status that people can opt out of. With Superhuman, it is not. If I send you an email using Superhuman (no matter what email client you use), and you open it 9 times, this is what I see[…] A running log of every single time you have opened my email, including your location when you opened it.


They’ve identified a feature that provides value to some of their customers (i.e. seeing if someone has opened your email yet) and they’ve trampled the privacy of every single person they send email to in order to achieve that.

This has long been common with spam and mass marketing tools like MailChimp. But adding tracking—which the sender can’t turn off—for personal e-mails takes this to a new level. The only recourse for the recipient is to turn off automatic display of all remote images, as I describe in the SpamSieve documentation.


What bothered me the most about tracking pixels in emails (when using Apple Mail) was false positives:

I would occasionally have someone ask me why I opened their email 20+ times before responding (I didn’t).

After a while, I realized that when using the “arrow down” key to scroll through your inbox in Apple Mail (with split view enabled), Apple Mail will open and render every email in the split view when attempting to open an email further down in the inbox. This would result in every tracking pixel being loaded/rendered dozens of times, even when the email was open on the screen for < 200ms.

See also: David Heinemeier Hansson.


Update (2019-07-05): Rahul Vohra (tweet):

We are making these changes:

  1. We have stopped logging location information for new email, effective immediately.
  2. We are releasing new app versions today that no longer show location information.
  3. We are deleting all historical location data from our apps.
  4. We are keeping the read status feature, but turning it off by default. Users who want it will have to explicitly turn it on.
  5. We are prioritizing building an option to disable remote image loading.

Walt Mossberg:

This is a good first step. Better than doing nothing. But it’s not enough. I read the full blog post. It makes no mention of disabling tracking how often the recipient opens the email. It’s also full of the rationalization that secret tracking is ok in “business” software.

Michael Rockwell:

Maybe content blockers for email apps should be a thing.

See also: Nilay Patel.

Update (2019-07-10): David Heinemeier Hansson:

Microsoft understood years ago how to offer ethical read receipts in email.

Update (2019-07-24): John Gruber (The Talk Show):

Once we allowed email clients to act as de facto web browsers, loading remote content from servers when messages are viewed, we opened up not just a can of worms but an entire case of canned worms. Every privacy exploit for a web browser is now a privacy exploit for email. But it’s worse, because people naturally assume that email is completely private.


I think Superhuman should be ashamed of themselves for building this feature in the first place — particularly the geo-tracking. But ultimately, email clients should defend against this. The fact that this nonconsensual tracking is even possible should be treated as a serious bug in all email clients. Apple Mail — both on Mac and iOS — allows you to disable loading of remote images as a preference, but that breaks most graphically rich emails. Mail clients should allow remote images but load them anonymously, through a proxy server perhaps. I’m sure it’s a tricky problem to solve, but I’m convinced it can be solved.


I feel like people are a little undereducated on this whole email tracking read receipt thing (Superhuman is but one example), so here’s something to consider: not only images can track you, but also DNS itself: unique domain + DNS server that logs queries == tracking.

Look up “DNS prefetch” to see why you don’t actually have to click anything or contact the domain itself to have your interest logged.

UIStackView and NSStackView

Reda Lemeden:

The UIStackView class provides axis-specific properties to define the layout: distribution for the main axis, and alignment for the cross axis.


Unlike NSStackView, UIStackView doesn’t support gravity-based distribution. This solution works by defining gravity areas along the main axis, and placing arranged items in any of them. One obvious upside of this approach is the ability to have multiple alignment rules within the same axis. On the downside, it introduces unnecessary complexity for most use cases.


The automatic layout calculation that stack views do for us come with a performance cost. In most cases, it is negligible. But when stack views are nested more than two layers deep, the hit could become noticeable.


Stack views are a lot more versatile than they get credit for. Their API on iOS isn’t always the most self-explanatory, nor is it the most coherent, but once you overcome these hurdles, you can bend them to your will to achieve non-trivial feats — nothing short of a Michelin star chef boasting their plating prowess.

This is probably the best overview I’ve seen.