Category Archives: Links

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.

Call To Action

Twitter just announced two new features aimed at facilitating customer service across the service:

      A custom link format for inviting customers to initiate a direct message.
      A method for soliciting feedback from customers about quality of service.

Of the new features, only the first is available immediately to all Twitter users. I was intrigued by the feature because I imagined it eliminating the uncomfortable process of businesses either having to ask customers to follow, or setting their direct messages to be “open” to anybody. Unfortunately, the feature does nothing to empower direct messaging between two consenting parties. It serves only as a shortcut for initiating a DM that would already be permitted:

Using this new feature is easy. It requires that your Twitter account settings are set to “Receive Direct Messages from Anyone”…

I guess being open to “direct messages from anyone” is a viable approach for some businesses, and maybe it is even the right choice for any business wanting to remain completely accessible to customers. But my experience turning the feature on for my private account was that it led to unwanted solicitations. Although I generally want to remain accessible to people, it was an invitation for nuisance inquiries.

I hoped upon seeing the news of this feature, that it might have been a feature that allowed a temporary, targeted permission to DM. This would be useful for businesses but also for individuals who are hesitant to either follow a person or open up DMs completely, but nonetheless wish to communicate privately for a short time.

My vision for the feature is close to what Twitter has announced: you would still tweet a “magic URL” to somebody empowering them to open up a DM conversation, but the very act of sending that URL to a person’s (@-messaged) account would open a hole in your DM permissions allowing them to reach you even if you neither followed them nor had completely open DMs turned on.

I imagine a scenario where the presence of such a link implied consent to DM for 48 hours or so, and where every response by DM to that user would extend the consent for another interval of time.

This would facilitate more direct, nuanced conversation between Twitter users, without forcing them to choose whether to be completely vulnerable to the world, to establish unwanted, short-term follower connections, or else more likely, avoid the interaction altogether.

Medium Permalinks

I was intrigued to read that Basecamp’s (née 37 Signals) Signal v. Noise blog has moved to Medium. David Heinemeier Hansson argues that Medium is “just the right mix of flexibility and constraint,” celebrating its web-based editor, the network of users, Medium’s demonstration of concern for its customers, and Basecamp’s admirable desire to get out of the business of maintaining their own blog-hosting software.

Hansson lists the ability to use one’s own custom domain among the user-friendly changes Medium has made. “By offering custom domains, we’re ensured that no permalink ever has to break, even if we leave the platform.” Indeed, this is a valuable improvement. But it got me thinking: for a blog like Signal v. Noise, with hundreds of posts spanning more than a decade, how would Signal v. Noise’s existing permalinks be preserved? Does Medium offer some fancy permalink customization for imported posts? Is there some ability to upload static HTML content to reside alongside newer, Medium-native posts? Surely a company as obsessed with the web as Basecamp would be concerned about this. How did they solve it?

It took a little poking around and scratching my head to realize that solved the problem in a novel way that doesn’t exactly get them out of the blog-hosting business. Signal v. Noise is now hosted on two domains:

  1. https://signalvnoise.com/ – The previous home of the blog, hosted and managed by Basecamp themselves, continues to host the backlog of archived posts.
  2. https://m.signalvnoise.com/ – The new home, hosted by Medium.

So when any new Medium post is linked, it points directly to the “m.signalvnoise.com”, and is handled by Medium. When any older post is linked, it goes directly to “signalvnoise.com” and is handled the same as ever. The one change? When the main page at signalvnoise.com is visited, it redirects with a “302 Found” response to the Medium site, getting a casual visitor on track to viewing only the latest posts.

I continue to admire a lot of the work Medium is doing. I agree with the Basecamp that their web editor is among the best I’ve used. For my tastes, it can’t touch the experience of a native Mac app, but of course I’m biased. Hopefully Medium’s API will continue to evolve and make Medium a more viable platform for folks who share my preference for a desktop editor.

Surviving The Work Week At Home

I was honored when Serenity Caldwell of iMore asked me to contribute a column to The Network. I was racking my brain to come up with a topic for the article, but I found inspiration in my MarsEdit drafts folder, with an article I had loosely speculated writing, but never followed up on. The article went live at iMore today: “How to survive working at home“.

My working title for the article was “Surviving the Work Week at Home,” but they changed it at iMore, probably for the better! I’m a sucker for the passive voice.

The staff at iMore also added helpful headings, and restructured paragraphs where I had simply rambled on. I love the freedom of writing fast and loose for my own blogs, but it’s a nice break to collaborate with a publication that will add the finishing touches to one’s writing to bring it to a higher level.

Thanks to Serenity and the entire team at iMore for helping me get my article polished up, and for sharing it with your audience!

Microsoft WinObjC

Microsoft appears to be following through on its promise to provide resources to iOS developers that facilitate the porting of apps to Windows.

The project, identified by the code name “Islandwood” earlier this year, has been renamed to Windows Bridge for iOS, and the company is making the source code available.

I had a surprisingly hard time finding the GitHub sources for the project. No news on Microsoft’s developer home page, nor on the Interoperability Bridges blog (oops, not updated since January, 2014). I even searched Microsoft’s GitHub repositories but couldn’t find anything matching “windows bridge ios” or variations.

Finally, I searched Twitter for related news until I found a link to a story that actually linked to the GitHub project.

The project’s famiilar name is WinObjC. And yes, it is on GitHub.

Update: If I knew The Verge’s format a bit better I might have noticed they credit the source, Microsoft’s own Windows blog, which in fact links to the GitHub project and includes the WinObjC.

WWDC Video Downloader

It’s great that Apple has, for years now, made videos of most WWDC content available free of charge on the web. A problem arises though, when you realize that you want to quickly check the content of some specific session, only to realize you are either offline, on a slow internet connection, or just don’t have the time or patience to connect to Apple and download the video.

I’ve found it useful to use Olivier HO-A-CHUCK’s wwdc-downloader script, which he has recently updated for the 2015 URL conventions.

Essentially you just download the script to a disk with a ton of free space, run it, and you’re left with a permanent archive of all the videos and PDFs from a given year’s WWDC.

I’ll be waiting until I get home to run this script, since by then all of the videos should be available, and I’ll have easy access to that aforementioned big hard drive. It’s great though that he has updated it so promptly this year.

Keeping Up With WWDC

Each year, WWDC kicks off with a keynote address chock full of the company’s tentpole announcements for the coming year. I always find it difficult to keep in mind even these, ahem, key points. But it gets “worse” as the day goes on, and then as the week goes on, as nuanced announcements are indicated by revelations in the Platforms State of the Union, and the extensive, in-depth sessions that fill out the remaining days of the week.

It’s all too much. Exciting, but still, too much.

Fortunately, master information compilers like Michael Tsai swoop in to help organize links to the most significant download points and technical summaries, as well as pertinent pages from non-Apple sources such as one explaining the process for using VMware to create a standalone test version of OS X El Capitan.

Michael Tsai: WWDC 2015 Links.

Michael’s blog continues to serve as a great argument for the value of RSS and blogging. Subscribing to it is a great way to keep your finger on the pulse of a great number of pertinent issues to Mac and iOS developers, both during WWDC week and a throughout the year.

The Risks And Rewards Of Criticism

Marco Arment responded to speculation by Eli Schiff that he and other Apple developers hesitate to criticize Apple for fear of retribution.

I was particularly surprised by the section of Schiff’s post that described Shifty Jelly developer Russell Ivanovic’s experience of being cut off by Apple from what had previously been a well-supported position. The way it’s described in the post, Ivanovic’s close marketing ties to Apple were severed when he decided to launch a version of his app on the Android Play store before Apple’s App Store. I haven’t listened to the podcast yet, but it sounds great, and may provide slightly more details about the situation.

Ivanovic’s experience sounds devastating, but it doesn’t strike me as treatment that many developers should live in fear of also suffering.

As a company, Apple doesn’t care about individual developers. This works both ways of course: they don’t go out of their way to help, but also don’t go out of their way to harm. When a developer benefits or suffers at the hands of Apple, I believe it’s always thanks to either a wide-sweeping corporate policy that affects all developers, or to an individual at the company whose everyday choices on the job can have a profound impact. An editor who chooses to feature an app on the store, for example, or a reviewer who chooses to notice and raise a fuss about a slightly non-compliant behavior in an app.

I’m confident that at the level of individuals within Apple, efforts are almost always in the spirit of helping developers. You don’t have to meet many Apple employees to form an opinion that, on the whole, the company is made up of good people. So, naturally, the majority of folks there are working to cause good outcomes for people both inside and outside of Apple. The culture at Apple leans towards building people up rather than tearing people down. This is, incidentally, why their products tend to be so great. And why in spite of some truly confounding decisions, the company tends to promote stellar third party products through its App Stores.

On the other hand, the company is huge, and you simply can’t have that many thousands of people in varying positions of power without having at least tens or hundreds of spiteful, angry, petty people in positions of power. Oops, that sucks. While I was trying to make sense on Twitter of Ivanovic’s unfathomably petty experience, another slighted developer chimed in. Matthew Drayton, who like Ivanovic lives and works in Australia, pins his own similar experience on an individual:

I can’t quite tell if the implication is that the same individual is likely to be responsible for the “blackballing” that both Drayton and Ivanovic say they’ve felt. But for the sake of Apple, I hope it is indeed down to one person. One person can often be fired, reprimanded, or simply decide to move on. It would obviously be much worse if there were a systematic policy of suppressing developers who fail to “walk the line,” to to speak.

The risks of being critical are usually not on the scale of upsetting an entire company and suffering its wrath. Instead they are on the scale of possibly upsetting, or merely frustrating, or even just vaguely losing attractiveness to an individual whose help you would otherwise have enjoyed. This is true both in the context of Apple and outside of it. For example, an off-hand remark about the bitterness of the coffee at your local shop might earn you a less professional effort on your next visit.

On the other hand, an astute barista may take the criticism to heart and become hell-bent on ensuring your next cup exceeds expectations. This is what happens when well-formed criticism meets the ears of a confident, competent individual: the facts are taken to heart and studied, perhaps grudgingly. But upon reflection and determination that there was merit in the complaint, respect for the source of provocation goes through the roof.

These are the risks and rewards of criticism: depending upon how far your opinions reach, you may garner either immense respect or massive disdain from the individuals who consider it. In that light, is it risky to be publicly critical of a company upon which you base your entire livelihood? Possibly. But it could be just as risky to remain meekly under the radar while the thoughtful professionals at that company go out of their way to reward the people whose meaningful criticism they value.

The Functional High Ground

Marco Arment laments his perception that Apple’s software quality is in such a rapid decline that the company has “completely lost the functional high ground.” I like this turn of phrase, even if I don’t agree with the extremity of the sentiment. Marco expands:

“It just works” was never completely true, but I don’t think the list of qualifiers and asterisks has ever been longer. We now need to treat Apple’s OS and application releases with the same extreme skepticism and trepidation that conservative Windows IT departments employ.

I myself am particularly paranoid when it comes to Apple’s future. I spent the earliest years of my professional career working for the company, and to this day I consider the education I received at Apple to have been equal parts technical and philosophical. I learned not only how to build quality software, but why it should be done: to not only serve customers, but to delight and surprise them.

For years, my concerns about Apple’s future have been largely to do with my worry that those philosophical values are decreasingly shared by Apple’s engineering staff and management. And yet, over the years, I have been surprised and delighted by the steady stream of new, quality products that Apple releases.

The current state of Apple’s software does not particularly concern me. Are there embarrassing blemishes? Yes. Does the annual schedule for major OS updates seem rushed? Of course. Are there Apple employees in positions of power who do not share Marco’s and my enthusiasm for software that “just works?” I regret to surmise that, indeed, there are.

But I’ve indulged these doubts about Apple since shortly after I was hired … in 1996. The mysterious, seemingly magical nostalgic components of Apple’s past success have always seemed threatened by the rapid waves of change that undo and reconfigure the company’s priorities. After the NeXT acquisition in late 1996, many of my colleagues and I feared the influx of new engineers would spell the end of the Mac as we knew it. In fact it did, but the new priorities of Mac OS X meshed well with the old priorities of Mac OS 9, yielding what I believe is an undisputably better, more Apple-like operating system than Apple was likely to have come up with on its own. There were many fits and starts along the way, including questions about arcane matters such as filename extensions and case sensitivity. These were but a few of many questions that would seem to make or break the legacy of the Mac. Choices were made, hearts were broken, and the Mac lives on.

Since I left Apple in 2002, I have been no stranger to criticizing the company for its flaws. The mistakes they ship in hardware and software are sometimes so glaringly obvious, it’s impossible to imagine how any engineer, manager, or executive could suffer the embarrassments. And yet, sometimes these defects linger for years before being properly addressed.

The problem has also been a focus of popular geek culture at many, many times in history. Way back in 2005, Dan Wood of Karelia was so frustrated by persistent flakiness in Apple’s software that he encouraged developers to report an Apple bug on Fridays. It worked: myself, Brent Simmons, Wolf Rentzsch, Sven-S. Porst, and countless others were moved to file bugs not just that Friday, but for many weeks to follow.

Over the years I have never been at a loss for identifying problems big and small with Apple’s products, or with the way it conducts its business. I’m sure I had plenty of complaints starting in 2002, but I didn’t start blogging in earnest until 2005. Here are some highlights to remind you that things have never been fine with Apple:

  • 2005 – Keychain Inaccessibility. I lamented the poor behavior of Apple’s Keychain Access app, even after improvements that came in Mac OS X 10.4.3. Nearly ten years later, to the delight of the folks who make 1Password, this embarrassment remains largely uncorrected.
  • 2006 – We Need a Hero. I shined a light on the difficulty of implementing AppleScript support in applications. Things have steadily improved, but are still very frustrating and error-prone. At least now we have two automation languages to pull our hair out over.
  • 2006 – All Work and No Play… Apple’s first Intel portable computer was a sight for sore eyes, but a cause of sore ears. The maddening “CPU whine” persisted through several iterations of the hardware design until the machines finally became more or less (to my ears) quiet.
  • 2007 – Leopard Isn’t the Problem. Speaking of annual software release schedules, here’s my nearly 8-year old reaction to Apple’s failure to meet the planned release schedules for both Mac and iOS in parallel. Is Apple suddenly more fixated on marketing than on engineering? Not by my assessment that their statement way back then was “bluntly crafted, sleazy marketing bullshit.”
  • 2008 – NSURLConnection Crashing Epidemic. Wouldn’t it be embarrassing if Apple shipped a bug so pervasive that it could crash any app that uses Cocoa’s standard URL loading mechanism? That’s what they did in Mac OS X 10.4.11, and it took them months to fix it. When they finally did, I ended up receiving a security update credit!
  • 2009 – Is Apple Evil? Speaking of embarrassments, how pathetic is it that nearly 7 years after the iOS App Store debuted, capricious rejections are still a mainstay of iOS tech journalism? In 2009, I reacted: “Alongside the stubbornly perfected refinement of its products, marketing, and public image, the company has always worn blemishes such as these.” Some things truly never change.
  • 2010 – Surviving Success. From the midst of “antennagate,” in which Steve Jobs accidentally coined the famous anti-advice “you’re holding it wrong.” I fretted that Apple was losing its marketing cool, and that Jobs should chill out:

    He spins the truth in that barely plausible manner that used to be celebrated as the “reality distortion field,” but now comes off as purposefully dishonest and manipulative.

    We don’t have Jobs to blame any longer for Apple’s less tasteful distortions of reality.

  • 2011 – Huh. I couldn’t find any particularly cogent complaints in my archives. Maybe I was too busy reacting with panic to Apple’s new Mac Application Sandbox. I did complain in an interview with The Mac Observer about “having to come to terms with the vast amount of stuff that Apple’s doing,” but that “it’s been a persistent, joyous complaint … that Apple is doing too much.”
  • 2012 – Fix the Sandbox. Having fully digested the impact of the Sandbox on shipping apps, I drew attention to the many problems I saw in Apple’s approach to (allegedly) enhancing user security:

    Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished.

  • 2013 – Respect the Crowd. Oh, right, Maps. Remember when Apple used to have reliable driving directions, place data, and even public transit directions?

    It’s all about the data. It doesn’t matter how beautiful Apple’s maps are, or how quickly they load, if they consistently assign wrong names and locations to the businesses and landmarks that customers search for on a daily basis.

    Apple has made significant improvements to their mapping data, and there are rumors, based largely in their acquisition of transit-oriented companies, that they may restore transit directions at some point. But to this day, Google Maps remains my go-to app for transit directions, while Google’s other directions app, Waze, gets my business for driving directions.

  • 2014 – Breach of Trust. We’re getting so close to modern times by now that Apple’s tactless imposition of a U2 album on everybody’s iPhone, whether they wanted it or not, could be considered part of Marco’s current diagnosis of what ails Apple. The nut of my take on the incident:

    It doesn’t matter much that Apple inserts an unwanted music album into your purchased list. But even a little move in a direction that threatens the primacy of users is a relatively big move for companies like Twitter or Apple, whose track records have inspired us to trust that we retain more authority over the personalization of these products than perhaps we do.

And now it’s 2015, and in the immortal words of Kurt Cobain: “Hey! Wait! I’ve got a new complaint.” Don’t we all. A company like Apple, moving at a breakneck speed, will undoubtedly continue to give us plenty to obsess about, both positively and negatively. I’ve been following the company closely since my hiring in 1996. Since that time, the company has consistently produced nothing short of the best hardware and software in the world, consistently marred by nothing short of the most infuriating, most embarrassing, most “worrisome for the company’s future” defects.

Apple is clearly doomed. I think Apple is going to be okay.

Blockpass For Dummies

After I wrote recently about my tool for preventing accidental typing of my password into plain text fields, I received a large number of requests asking if I would open source the tool. I generally hesitate to open source my private tools, because I throw them together with understandably lower standards than the code that I ship to users, and because I often rely upon my accumulated convenience classes and frameworks to get the job done expeditiously.

But for some reason I’m deciding to share Blockpass on GitHub. I had to do some work to make using and running it a little more bulletproof. Rather than rewrite keychain access to avoid using my private “RSKeychain” class, I decided to just include that.

Details about how to configure and install the tool are detailed in the Readme file on the GitHub project page. You probably should not pursue the project unless you are comfortable using Xcode and building projects from scratch. I may consider building a standalone version of the tool someday, but today is not that day.

If you have any specific questions or feedback, feel free to open an issue on the project or drop me a line on Twitter.

Push Notification Traps

Recently Marco Arment bemoaned Apple’s use of push notifications for promotional purposes. Apple sent a notification promoting their project (RED) products for sale in the App Store, which Marco judged as user-hostile and in poor taste, even if it can be argued it was “for a good cause.” I tend to agree with Marco on this point.

In the latest episode of the Accidental Tech Podcast, Marco, along with co-hosts John Siracusa and Casey Liss, talked more about the problem of notification spam in general and the difficulty of enforcing it at app review time. They seemed to be in agreement that the only realistic tool at Apple’s disposal is to devise a crowd-sourced flagging system for inappropriate notifications, and to use that collective information to pinpoint the worst offenders, and then to use that information to impose consequences upon them.

They went on to lament that Apple is not very good at these kinds of crowd-sourcing solutions, and that in all probability the vast majority of iOS users are not concerned or aware that they should be concerned about notification spam. The lack of consumer awareness about the nature of the problem could itself be a limiting factor in any crowd-sourced solution.

But I propose that Apple does have tools at its disposal that could help flag the worst offenders immediately, without the cooperation of the public, and without violating any user’s privacy.

All remote push notifications are delivered from an app’s developer to an end-user’s device via the Apple Push Notification service. This is good, because it puts Apple in a position to intercept and e.g. immediately shut down a bad actor from delivering notifications to any of its intended recipients. However, the content of all these notifications passing through Apple’s service is encrypted. This is good, even required, because it protects developer and company data from being eavesdropped. But it’s bad from an enforcement sense because it thwarts possible solutions such as using a Bayesian filter on content to flag spam, similarly to the way an app like SpamSieve works on the Mac.

So Apple has complete control over the distribution mechanism, but zero ability (apart from metadata including the originating company and the target device) to examine the content passing through. Game over? I don’t think so.

Apple can still use its unique role as the center of all things iOS to devise a system through which they would themselves be virtually subscribed to all unremarkable notifications from a particular app’s developer. Think about the worst notification spam you’ve seen. In my experience it’s not super-personalized. In fact, it’s liable to be an inducement to keep using the app, to advance in a game, to become more engaged, etc. I think Apple would collect a ton of useful information about spammy developers if they simply arranged that every app on the App Store that is capable of sending push notifications included, among its list of registered devices, a “pseudo-device” in Cupertino whose sole purpose was to receive notifications, scan them for spammy keywords, apply Bayesian filters, and flag questionable developers.

Because Apple controls the namespace for device IDs, has access to the executables for all the apps in the store, and is technically equipped to run these apps in contrived environments, they could coax applications to perceive themselves as having been installed and run on a device with ID of Apple’s choosing. In fact, it’s probably simplest if this very thing happens while App Store reviewers are evaluating apps. It’s true that they won’t see the spammy notifications during review, but the mechanics of triggering an app’s registration for future notifications would ensure delivery to a “trap device,” actually a giant database against which arbitrary research could be conducted.

This would not be a violation of anybody’s privacy, because only the artificial App Store review team’s data (if any) would be involved. Most likely, it would not capture most bona fide useful notifications, because reviewers wouldn’t use the app to the extent that such notifications are generated. But it would capture all the “send a notice to everybody whose every launched the app” and “send a notice to folks who haven’t launched lately” type spam. That seems like a pretty big deal.

At the very least, such a system could serve as a baseline mechanism for flagging developers, and in the event that some future crowd-sourced solution was unveiled, it would layer nicely on a system in which Apple was already collecting massive amounts of data about the most humdrum, spammy notifications that developers send.