Category Archives: Links

The Mac Open Web

These days, as the giant social networks behave more and more reprehensibly, many people are looking back to the “good old days” of the web, when self-published blogs were the primary means of sharing one’s thoughts.

Brian Warren has taken this enthusiasm, and combined it with his nostalgia for another classic resource: the links page. He’s created a new one called Mac Open Web:

A collection of open and indie Mac, iOS, and web apps that help promote the open web.

The solitary page is jam-packed with links to resources for creating and perusing content on “the open web,” that is to say “the web.” If you’re sick of Facebook and Twitter owning your experience of what is still a hugely diverse and free global network, then spend some time investing in writing and reading on the web “the way we used to do it.”

Mac Sandboxing: Privileged File Operations

At WWDC 2018, Apple announced with great fanfare that two beloved Mac apps, Transmit and BBEdit, would be returning to the Mac App Store.

Each of these apps had departed the App Store years ago, citing various reasons, but chief among them the limitations of the Mac App Sandbox, which restricts the functionality of apps in the Mac App Store.

I was curious whether Apple made any specific concessions to these developers, and whether those concessions would be opened up to “the rest of us” or not.

Today, Panic launched Transmit 5 on the Mac App Store. It’s a free download, and costs $24.99/year after an initial 7-day free trial.

I downloaded Transmit even though I own a copy of the direct-purchase version. I wanted an answer to my question, which I got, at least partially, by dumping the application binary’s “entitlements”, which represent the sandboxing exceptions that the app has received.

New to me among the entitlements is “com.apple.developer.security.privileged-file-operations”, which is a boolean value set to true for Transmit. I don’t see any Google results for this key, so I’m assuming it’s something new that was added for Panic (and maybe BBEdit), and which may or may not be documented in the future for use by other developers.

Another interesting entitlement is “com.apple.security.automation.apple-events”, which is documented by Apple, but only in the context of the new “Hardened Runtime.” This technology is aimed primarily at developers who are not developing for the Mac App Store, but who want to provide enhanced security for their customers. In that context, I believe this entitlement provides unfettered access to sending AppleEvents, excepting that in Mojave and later the app is still subject to fine-grained system alerts that require user approval for each application that is targeted.

In short: it appears that Transmit possesses at least two “official” entitlements that could be made available, or are perhaps already available, to other developers. One way to find out: add them to your app and submit it for approval!

Update: Thanks to Jeff Nadeau for alerting me to the pertinent API that correlates with the privileged file operations entitlement. NSWorkspaceAuthorization can be used to request privileged file access from the user, and Apple includes a link for requesting access to the entitlement.

Update 2: It turns out my intrigue around “com.apple.security.automation.apple-events” was ill-founded. I assumed that a sandboxed app could use this entitlement to gain unfettered access to automating other apps, but in the case of a sandboxed app it turns out to work in conjunction with the existing “com.apple.security.temporary-exception.apple-events” entitlement, which requires enumeration of specific targets. Thanks to Jeff Johnson and Paolo Andrade for talking me through my misunderstanding of the situation.

Saying Goodbye to NetNewsWire 3

In case you haven’t heard the news, Brent Simmons recently regained the rights to NetNewsWire, the groundbreaking Mac news reader, which also happens to be the progenitor of MarsEdit.

I have been a fan of NetNewsWire since before Brent sold it to NewsGator. Since before NewsGator sold MarsEdit to me. Before they sold NetNewsWire to Black Pixel. For a long time.

After Black Pixel took the reins, they put a lot of effort into a massive overhaul of the app, modernizing the look and feel and adding a robust, in-house syncing mechanism. When they released NetNewsWire 4 in 2015, it seemed as though the future for the app was bright.

As nice as NetNewsWire 4 was, it also differed a lot from NetNewsWire 3. They pared back the feature set a lot, in ways that made switching inconvenient to me. So I soldiered on with 3.3.2, thinking that I would update to 4.x eventually.

I never did. For whatever reason, work on NetNewsWire seemed to stall, and I never found the updated version of the app to fit my needs. NetNewsWire 3 worked just fine.

The meaning of “just fine” started to shift as macOS changed underneath the app. Subtle bugs emerged, the app’s lower-resolution graphics started to look fuzzy, and the networking infrastructure of the app is from an older era that is failing to connect to some SSL servers. In short, it’s no longer the great app that it once was. One particular bug with the size of the “Clippings” folder icon has been bugging me for years:

Screenshot of NetNewsWire showing blurry icons and a missized Clippings folder icon.

Over the years I considered other news readers such as Reeder (which is free for a limited time, by the way), but none of them scratched that NetNewsWire 3 itch. I rely upon some arcane features of the app including “scripted feeds,” which allow me for example to run Python scripts on my Mac that connect to Twitter and generate RSS feeds from search results. That’s not possible in most feed readers.

I used to fantasize about getting access to the NetNewsWire 3 source code and sprucing it up. I wondered how things might have turned out differently if, in addition to acquiring MarsEdit from NewsGator, I had acquired both? I can’t say I would have done a better job than Black Pixel, but I would have preserved the features I care about, and that Clippings folder icon would be the right size!

Because Brent and I are still close friends, we have been in conversation about NetNewsWire and the various options for moving it forward into the future. I’ve also been contributing to the NetNewsWire open source project, which is based on an entirely new code base unrelated to NetNewsWire 3.

Since I’m not the only stalwart NetNewsWire 3 user, one of the things Brent was curious about was whether he could give that version “one last hurrah,” so to speak. Fix a few of the most glaring bugs, build against a modern SDK, and not only create an artifact for history to more accurately judge the app’s virtues, but to give long-standing users something to tide them over while development continues on NetNewsWire 5.

I was honored when Brent handed me the keys to the castle, so to speak, by sending me a copy of NetNewsWire 3’s source code. To heavily paraphrase what he said, it was basically “let me know if it’s worth saving.”

I got the app building with Xcode 10 on macOS Mojave beta 9. There were some major glitches. The sidebar was pure black, fonts were rendering wrong. Probably whole subsets of functionality were not working, or working unreliably. I sent the source base back to him with a report that it builds and runs, but would probably take some work to get into shippable shape.

Brent made the pragmatic choice not to release an updated NetNewsWire 3. Putting the bugs aside, he recognized that any time invested in that old version is an investment in older technology that does not have a viable future. It’s a distraction from the New World NetNewsWire.

To be honest, the decision doesn’t sting at all. I’ve switched most of my news reading to development releases of NetNewsWire 5, and only use NetNewsWire 3 for a handful of those geeky script-based RSS feeds I am still relying on.

I was grateful to have the opportunity after all these years to take a peek at the source code to the app, and to get a feel for what it would take to salvage what’s left. I couldn’t resist fixing at least one bug before I passed it along though:

Screenshot of the NetNewsWire window with Clippings folder icon restored to normal size

If you’re curious: the Clippings icon is obtained from the Mac operating system. At one point in history it must have come from the system at just the perfect size to fit the source list in the app, but as Apple modernized and adapted to higher resolution Macs, they must have updated the icon to support drawing at much larger sizes. NetNewsWire 3.3.2 doesn’t manually set the size to the expected 16x16pt size, but 3.3.3j (for Jalkut!) does.

Goodbye, NetNewsWire 3. You were a great app, but your time has passed. Long live NetNewsWire 5.

Gus Mueller on Extra Intuition

Manton and I just published the second episode of our members-only Extra Intuition podcast: I Know it was 15 Years Ago. We’re joined by Gus Mueller of Flying Meat to chat about … whatever comes up! Many thanks to Gus for taking the time to do the show.

It’s fun to have a chance to deviate from the usual format of Core Intuition. In some ways it’s more relaxed, like the show was in the early days. We are looking forward to mixing it up with interviews and other conversations that we don’t think are as suitable to the main show.

Our first episode, We Did Meet in Person features our recollections of meeting each other and starting to podcast together.

Core Intuition Membership

Today Manton and I released the 300th episode of Core Intuition. We published the first episode on May 30, 2008, and every episode since has been completely free for our listeners. Starting with Episode 301, that’s … going to stay completely the same. Except…

Core Intuition is now offering a membership program. We have been lucky over the past several years to have the financial support of many great sponsors, but we also want our enthusiastic listeners to have the option of supporting us directly. In the long term, we don’t know if we can count on our sponsorship luck to continue indefinitely, and would like to be able to continue doing the show regardless of how those fortunes shift.

We think that many of our listeners would support us without an incentive, but what’s the fun in that? That’s why we decided to start a second podcast, exclusively for members. Extra Intuition will feature extra discussions, interviews, and frankly, we’re not sure what. We’re just excited to have an outlet for some of the stuff we want to talk about, but doesn’t exactly fit the format of the main show.

Our first episode of Extra Intuition is already live, and it features a discussion about the early days of our friendship, and how we decided to start Core Intuition. If that sounds intriguing, please consider becoming a member so you can check out the show!

Progressive Disclosure In Swift

In his excellent interview with the Accidental Tech Podcast, Chris Lattner defended the goal of Swift being suitable to both beginner and advanced programmers. He cites progressive disclosure, a design philosophy that is often employed in GUI applications, to make otherwise intimidating interfaces appear approachable. From episode 205 of the show:

The secret to Swift in being easy to learn, easy to use as a teaching vehicle, but also powerful enough to solve the problems that need to be solved, is that the complexity in the language needs to be progressively disclosed.

This resonates particularly with me not only because I strive to make the same kinds of design tradeoffs in my own software, but because this concept is particularly important to the history of the Macintosh. Progressive disclosure as a user accommodation is intrinsic to most Mac and iOS interface design.

An example that anybody who uses a Mac can relate to is the process of deleting files by way of the Trash. There’s a file on your Desktop, and you want to get rid of it. A naive user who has never used a Mac before will soon learn how to drag the icon onto the trash, and how to empty it through a variety of discoverable UI buttons and menus. This is the Mac, it’s easy to use.

After gaining some experience the same user might start to find all that clicking and dragging tedious, so they’ll be delighted to learn that the cryptic symbols on commonly-used menu items represent keyboard shortcuts. To throw away a file and empty the trash, just select the file, press Cmd-Delete, and then Cmd-Shift-Delete. This is the Mac, it’s streamlined for productivity.

When the standard menu items and shortcuts don’t cut it anymore, the same user will be inspired by the variety of nuanced variations that are unlocked by holding the Option key while selecting menu items, and that the incorporation of the Option key into existing keyboard shortcuts often maps perfectly to the same menu item that appears when the key is held down. “Move to Trash” becomes “Delete Immediately,” and “Empty Trash…” becomes “Empty Trash”. The omission of the ellipsis, they have come to discover, indicates an action that will take place immediately, without additional interaction. This is the Mac, it’s kind of complicated, but great for power users.

Finally, finding cause to delete a variety of files from a directory selectively, based on pattern-matching, they discover the Terminal app. They teach themselves the basics of a decades old interactive shell scripting wildcard notation, and are off to the races invoking the “rm” tool with wild abandon. This is the Mac, it’s got god-awful, nasty interfaces for accomplishing just about anything.

I worked at Apple from around 1995 to 2002, so I had the pleasure of witnessing reaction both within and outside the company as we transitioned from Mac OS 9 to Mac OS X. The Terminal, as it happens, was one of the most contentious new features. Mac OS 9 had standalone command-line developer tools such as MPW (Macintosh Programmers Workshop), but it was a sort of point of pride that it didn’t ship with a Terminal app. This wasn’t DOS, for crying out loud! Many people complained that Mac OS X was too complicated, and that the inclusion of a Terminal app was the beginning of the end for the system’s famous usability.

Fifteen years later, people are still performing incredibly simple, incredibly complex tasks with macOS Sierra. It ships with a Terminal and it ships with a Trash icon. This is the Mac, it spans the spectrum from simplicity to complexity. Apple’s turns out to be pretty good at this, so they deserve the benefit of the doubt that they’ll achieve the same type of goal with Swift. It seems like they’re off to a good start.

The Price Of GPL

Matt Mullenweg, the founder of Automattic, downloaded his competitor Wix’s iOS app. It looked eerily familiar, and he confirmed it contains source code stolen from WordPress. He called them out on his blog, getting right to the point in addressing the problem:

Your app’s editor is built with stolen code, so your whole app is now in violation of the license.

Wix’s CEO, Avishai Abrahami, responded with a round of non-sequiturs that carefully evade the point that his product is built from source code for which they have not paid. One of his engineers equally misses the point, focusing on the circumstances surrounding the violation, rather than taking responsibility for the theft.

Some will take issue with the use of strong words like “stolen code,” and “theft,” with respect to a GPL violation. But that’s exactly what it is: software has been taken and deployed in Wix’s product, but the price for doing so has not been paid.

Many developers (and CEOs) seem to prefer remaining willfully oblivious to the consequences of using GPL code. They loosely interpret the terms of GPL to suit their own wishes for what they implied:

  • “It’s OK for us to use GPL code anywhere, as long as we contribute back changes.”
  • “It’s only a small amount of GPL code, so the license doesn’t apply.”
  • “We contributed to this GPL code, so we have special rights to use it.”
  • “We give back to the community in other ways, so it balances out.”

All false, yet all common interpretations of GPL, and echoes of the poor arguments presented by Wix’s CEO and engineer.

The price of GPL is fairly obvious and easy to understand, even if there is some bickering about what constitutes “linked code.” You don’t have to be a legal expert to get the gist of it: if you want to link your software with GPL code, you must also make your software’s source code available. Specifically, you must make your software’s source code available to customers who install your software, under a GPL-compatible license. You have to give your code away. That’s the price of GPL.

Many developers understand, and view the price of GPL as perfectly justified, while others (myself included) find it unacceptable. So what am I supposed to do? Not use any GPL source code at all in any of my proprietary products? Exactly. Because the price of GPL is too much for me, and I don’t steal source code.

The Apple

MacRumors pointed out that Apple seems to be dropping “Store” from its store branding. The new flagship store in San Francisco, for example, is “Apple Union Square.” This has led to some criticism and guffawing from friends who now jokingly refer to any Apple Store as simply “The Apple.”

John Gruber thinks it makes sense to drop “Store” from branding, and compares Apple with other major brands whose stores do sound ridiculous with the appendage:

The “Store” branding only made sense when the concept was novel. Now that Apple’s stores are well established, it makes sense to drop the “Store”.

And:

No one goes to the Tiffany Store or Gucci Store, they just go to Tiffany or Gucci. It’s not even just a premium thing — you say Target and Walmart, not Target Store and Walmart Store.

The difference between these brands and Apple is that Apple’s identity has long been independent from the notion of a store. Calling it the “Apple Store” was not only important because the stores were a novelty, but because Apple is a brand that transcends retail. This may be true as well for Tiffany or Gucci, but when you think about these brands, I suspect you think of them in their retail context. Target and Walmart? They’re stores to the core of their being, so of course it would sounds strange to brand them as such.

Apple is a company whose products, hardware and software, have historically been sold separately from its own retail presence. Going to “Apple” will never make sense the way it does to go to “Target” or even to “Tiffany’s.” Where “Store” has been dropped, it’s essential that some other qualifier takes it place. Going to “Apple Union Square” makes sense. Asking a hotel concierge whether there is “an Apple nearby” makes as much sense as asking where the nearest “Ford” or “Honda” is.

Of course, the vast majority of people will probably still refer to any of Apple’s stores as “the iPhone store.”

When Worse Is Better

On the latest episode of John Gruber’s The Talk Show, guest Ben Thompson tries to identify the ways in which Amazon’s Alexa speech recognition is better than Apple’s Siri.

One of his key points was that Alexa, by being theoretically less capable than Siri, manages to avoid the heightened expectations and subsequent disappointment that users feel when Siri fails to listen as well as it promises to. It may be less competent overall, but what it does do it does predictably and well.

A comparison that came immediately to my mind was Apple’s mid-1990’s failure with the Newton handheld computer. The ambitious handwriting recognition was pure magic when it worked, but failed to work a significant amount of the time. Meanwhile, Palm took a more pragmatic approach with Graffiti, an overtly limited interpretation of the Roman alphabet, Arabic numerals, and a few other widely used symbols. By dramatically diminishing the magic of its handwriting recognition technology, Palm dramatically increased its reliability. Users seemed to appreciate this compromise, as Newton sputtered, and Palm Pilots went on to define the whole genre of hand-held digital assistants.

As much as I like this comparison, I don’t think Siri is doomed in the same way Newton was. Handwriting recognition was a primary interface on Newton, while with iOS devices it’s usually considered an augmenting interface. You can, and many people do, get plenty of use out of an iPhone without ever relying upon Siri. Siri is also nowhere near as unreliable, in my opinion, as Newton handwriting was. I use Siri on a daily basis and, perhaps because I’ve rarely tried anything better, I still find it an overall boon to productivity.

I think we are still in the early days of speech recognition, which feels funny to write because back in the mid-1990’s when Apple was failing to perfect handwriting recognition, they were doing the very same thing with speech recognition. But as John and Ben said on the show, none of the existing technologies, whether from Apple, Amazon, Microsoft, Google, Nuance, or others, is even close to perfect. There is so much interest now in the technology, that it’s possible to at least imagine extremely fast, reliable, predictable speech recognition becoming the norm. Whether the standard ends up being a shorthand-based approach such as Amazon is taking with Alexa, or a more ambitious artificial intelligence, may depend on which company can close the gap faster using one approach or the other.

Paid App Store Search

Bloomberg set off a wave of fear, uncertainty, doubt, and skepticism with their report alleging Apple’s plans to offer paid placement in App Store search results:

Apple is considering paid search, a Google-like model in which companies would pay to have their app shown at the top of search results based on what a customer is seeking.

Putting aside the fact that such a move seems un-Apple-like, I don’t see how it would benefit Apple, either.

Google sells placement in search results because that is the core of their business model. When a user finds and clicks a non-sponsored link in search results, it may serve Google’s ambition to collect information about users, but it doesn’t earn them any money. Without paid placement in Google search results, Google probably wouldn’t exist.

Apple’s overall business model is selling hardware with high profit margins. The business justification for the App Store is multi-faceted: its purpose is first to enrich Apple’s hardware products with novel third-party functionality, and second to generate revenue in the form of that 30% cut that developers love to complain about.

To this end, it’s in Apple’s best interests to ensure that the intersection of the best and the most profitable software is presented to users in the App Store. This is probably why the tired old high-level charts are broken down by “Free,” “Top Paid,” and “Top Grossing.” Items that rise to the tops of of those categories are most likely to serve Apple’s business justification for the store.

Allowing third parties to pay for placement in the App Store would not contribute to Apple’s justifications for the App Store in any way. Who benefits from such a change? The businesses paying for the placement, presumably. It’s hard to see how paid placement would consistently benefit either Apple or its direct customers. It’s unlikely that paid listings would be used to highlight apps that are in line with Apple’s other goals for the store.

I hope that Bloomberg’s report indicates that Apple is indeed brainstorming many ideas for improving search and inventory presentation in the App Store, but count me among the very skeptical that paid placement will be among the ideas that the company actually follows through with.

Make Wooden Toys

Like many developers struggling to make a living in the increasingly price-sensitive, App Store-influenced market, I was somewhat discouraged by Rene Ritchie’s excellent “What no indie developer wants to hear about the App Store.”

Rene argues that the app economy is moving towards cheap, mass produced, bargain-priced software that is simply not suitable for sustaining small-time indie software businesses. He adopts a beautiful metaphor, borrowed from his own childhood: the classic wooden toy.

When I was a child, all my favorite toys were wooden, painstakingly carved by artisans who ran the store near my home. I cherished them. Today those kinds of toys are all but gone, and that business model is no longer viable in the mass market.

Ugh. He’s right. Everything is cheap plastic, nowadays. Or is it?

If I pull up a mental inventory of my own kids’ playroom, there are indeed a ton of cheap, plastic toys. But there are also a good number of, wait for it, quality wooden toys.

Wooden toys are still being made! Shout it from rooftops, my indie brothers and sisters! If your inspirations and ambitions were flayed by Rene’s dose of reality, perhaps this will serve as an inspiring salve: do a Google image search for “wooden toys“. Those aren’t antiques…

I remember when my kids were younger, marveling at the powerhouse of wooden infant toys, Melissa & Doug. If you have a baby and are part of a socioeconomic culture that can sustain it, you have seen these toys. They are everywhere. And they are far from cheap.

So? Make wooden toys. Metaphorically speaking, I mean. (Unless, like Gus Mueller, woodworking has been your backup plan all along.) Make software that is inspired by wooden toys. Although the market is dominated by cheap plastic, there is real money for thoughtful, careful developers in the market that favors charming, slightly overpriced throwbacks to another era. Make wooden toys.