Thursday, December 18, 2014

Git Case-Insensitive File Systems Vulnerability

Junio C Hamano:

We have a set of urgent maintenance releases. Please update your Git if you are on Windows or Mac OS X.

Git maintains various meta-information for its repository in files in .git/ directory located at the root of the working tree. The system does not allow a file in that directory (e.g. .git/config) to be committed in the history of the project, or checked out to the working tree from the project. Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker).

Unfortunately, this protection has been found to be inadequate on certain file systems:

  • You can commit and checkout to .Git/<anything> (or any permutations of cases .[gG][iI][tT], except .git all in lowercase). But this will overwrite the corresponding .git/<anything> on case-insensitive file systems (e.g. Windows and Mac OS X).
  • In addition, because HFS+ file system (Mac OS X) considers certain Unicode codepoints as ignorable; committing e.g. .g\u200cit/config, where U+200C is such an ignorable codepoint, and checking it out on HFS+ would overwrite .git/config because of this.


Repositories hosted on cannot contain any of the malicious trees that trigger the vulnerability because we now verify and block these trees on push. We have also completed an automated scan of all existing content on to look for malicious content that might have been pushed to our site before this vulnerability was discovered. This work is an extension of the data-quality checks we have always performed on repositories pushed to our servers to protect our users against malformed or malicious Git data.

Mac Document Model: Don’t Lose My Data

Glenn Reid:

I was editing an important file, but left it open (commonplace, and usually not destructive). Meanwhile, I edited the same file on another computer, with different changes, and saved it to my shared (Dropbox) location, so it sync’ed out from under TextEdit.

This has happened countless times in the past, and TextEdit was smart enough to notice it, and tell me not to save over the other file. This dialog box purports to do the same thing, BUT WITH A CRITICAL DIFFERENCE. It does not allow me to Save As… to preserve my changes (because Save As… is not a feature any more!).

My two choices are [LOSE CHANGES] and [LOSE OTHER CHANGES]. How is that a good choice?

I still find the new document model confusing. If I open a file in TextEdit and start typing, the indicator in the window’s close box shows that there are changes. This used to mean unsaved changes, but now it means something like changes since opening the document. Viewing the file with Quick Look or BBEdit shows that TextEdit has already saved the changes to disk. The file on disk does not match my last explicit save point, which is the way Macs worked for nearly 30 years. Instead, if I close the TextEdit window and elect not to save changes, TextEdit then fetches the last explicitly saved version of the file and writes it on top of the newer version on disk.

In short, the contents on disk always match the contents in the window, but you have the opportunity to revert if you want. This is inconsistent with history and with applications that don’t or can’t use the new document model. And it causes confusion in situations like the one Reid describes.

I’m glad to see Reid blogging again. His new post about Safari is also good.

Wednesday, December 17, 2014

Duet Display

Duet Display (via Kif Leswing):

Duet is the first app that allows you to use your iDevice as an extra display for your Mac using the Lightning or 30-pin cable.

Sounds great, though it’s not yet approved by the App Store. I’ve been using Air Display for this, but due to Wi-Fi it’s slower and doesn’t always work.

Update (2014-12-18): Rob Griffiths:

Those two options also reveal my only real complaint about Duet Display as of today—it can be a real CPU hog. When set to display in retina mode at 60fps, the CPU usage on my 13-inch Retina MacBook Pro with attached retina iPad mini exceeds 120 percent. With this much CPU going to the extra display, I noticed some lag when switching between apps and launching new programs.

Setting the frame rate to 30fps and disabling retina mode drops that figure to around 30 percent, which is still quite high.

Juli Clover:

Along with the Retina issue, potential buyers should be aware of some other small issues that we ran into. Even in non-Retina mode, on a 2012 Retina MacBook Pro, there was some slight cursor lag, and we also had problems with visual artifacts on some apps. When watching YouTube videos, for example, there were some occasional performance blips.

Farewell, Dr. Dobb’s

Andrew Binstock, enearly six years after the end of the print edition:

This year, our website will deliver almost 10.3 million page views, which is an unprecedented number for Dr. Dobb’s. It’s up from 9 million last year and 8 million three years ago. That kind of growth is somewhat unusual for a site that has not changed its look or its mission, nor indulged in tawdry tricks like click-bait headlines or slideshows promising 9 quick tips for choosing a coding style. The numbers confirm that there is a deep thirst in the programmer community for long-form technical content featuring algorithms and code, as well as strong demand for explanations of new developer technologies and reliable reviews of books and tools.

If I were so inclined, this might be the right time for me to move on, and so leave, as they say in sports, “at the top of my game.” And indeed I will be leaving Dr. Dobb’s at the end of the year. But it would be more accurate to say that it is Dr. Dobb’s that is leaving: Our parent company, United Business Media (UBM), has decided to sunset Dr. Dobb’s. “Sunset” sounds like a marketing euphemism to avoid saying “closing down,” but in this context, it has a specific meaning that “closing” does not convey. That is, that there will be no new content after year end; however, all current content will be accessible and links to existing Dr. Dobb’s articles will continue to work correctly. It is the equivalent of a product coming to end of life. It still runs, but no new features will be added.

Michael Swaine:

I never gave up on #DDJ. Just started doing the same thing under a different banner.

Matt Rosoff:

Brutal times for tech trade publications. 10.3m pageviews/year not enough to keep Dr Dobbs alive.

On the other hand, one-man operation Daring Fireball gets 4–5 million page views per month, so it’s totally believable that less than 1 million per month would not be enough to fund a whole magazine.

Monday, December 15, 2014

NSPPL: Persistent Property Lists

David Smith notes that in 1998 Apple removed the NSPPL class from Foundation and open-sourced it. Today, property lists can be serialized in XML and binary formats. In both cases, these are chunks of data that are read and written atomically. The old NeXT system supported ASCII plists as well as a lazy binary format and a persistent property list (PPL) format that supported incremental access and caching in memory:

You can store a property list in three different ways: as an ASCII file, in a serialized binary format, and as a persistent property list (PPL). Each of these approaches has its advantages. For example, an ASCII property list is human-readable, but access is slow. Serialization, which stores property lists in a binary format, offers faster access than an ASCII property list and it’s also lazy, meaning that you can read parts of files without accessing the whole thing. But serialization doesn’t allow you to modify your data and then only re-serialize the part that changed.

Like serialization, a persistent property list stores data in a binary format, provides fast access, and is lazy. It also allows you to make incremental changes to an PPL (even one that contains tens of megabytes of data), while still ensuring that your data is never corrupted. In this sense, an PPL is analogous to a database. Because of their ability to incrementally store and retrieve data, PPLs are particularly well-suited for working with large amounts of data (that is, data that has several elements, that occupies a large number of bytes, or both).

After creating an NSPPL, you could read or write to it by using the -rootDictionary method to get a mutable dictionary proxy object (with its own lazy NSEnumerator).

Persistent property lists are atomic, meaning that if a save operation fails, the PPL reverts to its previously saved state. An PPL is never left in an intermediate state. Changes to an PPL are applied incrementally (in memory, but not to disk) as you make them and are reflected in the store and log files. A save operation has the effect of committing the changes you’ve made to disk.

The file extension for the store was .ppl, and there was a ppl command-line tool for converting between persistent and ASCII property lists.

Hopper + lldb for iOS Developers

Bart Cone:

Have you ever wondered how people get pseduo-code of some private API like the image below? It’s actually very simple and is a great way to chase down those annoying bugs in UIKit or some other binary you don’t have source code for. Getting this pseudo-code can literally be accomplished in just a couple clicks with a tool such as Hopper. What’s even cooler though, is we don’t have to stop there. With the Obj-C runtime and lldb we can make the pseudo-code even more readable if not syntactically correct!

The Dawn of Trustworthy Computing

Nick Szabo:

On the Internet, instead of securely and reliably handing over cash and getting our goods or services, or at least a ticket, we have to fill out forms and make ourselves vulnerable to identity theft in order to participate in e-commerce, and it often is very difficult to prohibitive to conduct many kinds of commerce, even purely online kinds, across borders and other trust boundaries. Today’s computers are not very trustworthy, but they are so astronomically faster than humans at so many important tasks that we use them heavily anyway. We reap the tremendous benefits of computers and public networks at large costs of identity fraud and other increasingly disastrous attacks.

Recently developed and developing technology, often called “the block chain”, is starting to change this. A block chain computer is a virtual computer, a computer in the cloud, shared across many traditional computers and protected by cryptography and consensus technology. A Turing-complete block chain with large state gives us this shared computer. Earlier efforts included state-machine replication (see list of papers linked below). QuixCoin is a recent and Ethereum is a current project that has implemented such a scheme. These block chain computers will allow us to put the most crucial parts of our online protocols on a far more reliable and secure footing, and make possible fiduciary interactions that we previously dared not do on a global network.

Aperture Exporter

Aperture Exporter:

There are plenty of guides on the internet detailing how to get your images out of Aperture and into another photo manager such as Adobe Lightroom. It’s a multistep and complicated process that is easy to get wrong. Aperture Exporter consolidates the process into just a few clicks and provides features not possible with any manual process.

Aperture Exporter is also a great way to back up your Aperture Libraries in a format that is not reliant on the future use of Aperture.

Exporting will always generate files for your originals without adjustments. Versions with Aperture adjustments baked-in can be generated optionally.

Hack Transpiler


Today, we’re proud to announce a first, experimental release of h2tp, or the “HH (Hack) Transpiler,” a tool which allows projects that have converted from PHP to Hack to still make releases that target the PHP language.


But transforming Hack code using collections is not merely about using equivalent constructs from the hacklib library. For example, on HHVM, empty Hack collections universally convert to false when used in a boolean context, something a standard PHP object can never do. This means that any arbitrary expression or statement that involves a boolean comparison, or any cast, might invoke this special rule if it involves a collection. So unless the expression being treated as boolean is trivially not a collection, we have to treat it as if it might potentially contain a collection. Hence, we have to be very cautious when making transformations.


In a few rare cases we actually have to choose not to support a feature. For instance, we do not support Instance variables using literal syntax in the class declaration.

Software Subscriptions

Alex Tyagulsky:

Every successful software product in the world is subscription based. It might sound wrong, but it’s true and I am going to prove it.


Whatever the case may be, the fact is that if you rely on a certain software, you’re paying for it regularly, not just once. And this in and of itself is a kind of subscription.


Subscription-based models in a competitive market are a rare example of a win-win situation for both consumers and companies. Any product you use single day requires you to pay in some way, whether with your money or personal data. We are just being honest with you and aim to create the best in class software that will save your time and money.

How Broken is Discovery on the App Store?

Gedeon Maheux:

The following list was generated by a manual App Store (iPhone) search on Nov 15th, 2014 for the term “Twitter”. To make the list easier to parse, I’ve called out all apps that allow a user to directly read AND post to Twitter in bold. Everything else is either a game, a utility, or some other social network enhancement. The official app from Twitter is naturally the first result, but the next actual Twitter client (Hootsuite) doesn’t appear on the list until #20 and the next one after that comes in at #62. Even the mega-popular Tweetbot isn’t returned in the results until position #81 and even then, the older v2 of Tweetbot (for iOS 6) comes first. Where’s Twitterrific? Although it contains the word “Twitter” in the app’s name, Twitterrific isn’t seen in the list until you scroll all the way down to #100.


Every app in bold on this list should precede every other app (save the official client) in the results. This is especially true of apps that are not optimized for iOS 8, yet some apps built for iOS 6 (not iOS 7, 6!) come first. Why? Why games appear on this list at all is a mystery, they are by far the least relevant and don’t even get me started on #18 “Alarm Clock HD” and #93 “Jedi Lightsaber” (really?). Twitter’s own Vine app doesn’t appear here until #34 and some would argue it should be result #2, and rightfully so. It’s obvious that Apple’s search algorithm needs adjusting so it’s weighted not towards downloads or popularity, but relevance.

Finding apps for a small niche category like Twitter clients is relatively easy. Imagine how hard it must be to find a particular game in the vast wilderness that is the App Store if you don’t know exactly what you’re looking for. Until Apple decides to take definitive steps to improve search results, either via human curation, or by lowering dependencies on popularity, easy discovery in the store will continue to be a major problem. Unfortunately for small developers who need paying customers to survive, time is quickly running out.

Update (2014-12-17): Marco Arment:

You can see similar ranking problems with almost any common search term. I searched earlier today for an iPad Instagram client — the iPad App Store search list for “Instagram” is just as spammy and unhelpful as this. I was only able to find what I was actually looking for by searching Google and asking people on Twitter.

Nick Heer:

It’s so bad that it‘s almost as if it’s programmed to be deliberately obtuse. If the App Store were a barista, it would bring you a wrench instead of your coffee and then come around to your house a few weeks later to take it back for unclear reasons.

Update (2014-12-18): John Gruber:

It has always been the case that a Google web search for “whatever iPhone app” provides far superior results to searching the App Store for “whatever”. Sometimes the difference is as vast as perfect (Google’s results) and useless (the App Store’s), as we can see searching for “Twitter iPhone client” in Google and “Twitter” on the App Store.

Lucien W. Dupont:

This is how bad App Store search is. 3rd in search for TurboTax [is Turbotax, below Blackjack Domination].

Saturday, December 13, 2014

Fox: a QuickCheck-Inspired Testing Framework

Jeff Hui (via Ole Begemann):

Test generation can provide better coverage than example-based tests. Instead of having to manually code test cases, Fox can generate tests for you.

What is Fox?:

Property-Based Testing Tools, especially ones inspired from QuickCheck, are test generators. These tools allow you to describe a property of your program that should always hold true instead of writing hand-crafted test cases.


In the mathematical sense, Fox is a weak proof checker of a property where the tool tries to assert the property is valid by randomly generating data to find a counter-example.


The benefit of Fox over purely random data generation is Shrinking. An informed random generation is done by size. This allows the tool to reduce the counter-example to a smaller data set without having a user manually separate thes signal from the noise in the randomly generated data.

We Need a “Safari View Controller”

Bryan Irace (via Marco Arment):

It’d be wonderful if Apple provided a “Safari view controller” that developers could present directly from within their applications. This controller would run out of process and work almost exactly like MFMailComposeViewController and MFMessageComposeViewController already do for composing emails and text messages respectively. The app would provide the controller with a URL (and optionally, a tint color), but otherwise what the user does in it would remain secure and isolated from any third-party code, yet fully integrated with and Safari controllers presented by other applications.

What Happened to NSMethodSignature?


Bringing the Cocoa frameworks to Swift gave us a unique opportunity to look at our APIs with a fresh perspective. We found classes that we didn’t feel fit with the goals of Swift, most often due to the priority we give to safety. For instance, some classes related to dynamic method invocation are not exposed in Swift, namely NSInvocation and NSMethodSignature.

We recently received a bug report from a developer who noticed this absence. This developer was using NSMethodSignature in Objective-C to introspect the types of method arguments, and in the process of migrating this code to Swift, noticed that NSMethodSignature is not available.


With a combination of protocols and generics, we have written Swift code to elegantly create and register HTTP handlers of varying types. This approach also lets the compiler guarantee type safety, while ensuring excellent runtime performance.

David Owens:

Seriously, someone asks for the functionality for dynamic dispatch and you say you can do the same thing with static code! No, you cannot. You can mimic the behavior.

Instead, you showed someone how to build a static registration table. Then you make the statement that it’s “type-safe” while using Any as the arguments to the public API for dispatch and using type coercion… that’s not type-safety. And let’s be honest, it’s really not that different then the validation one does for dynamic dispatch either.


You see, and this is the trade-off that you never mention. You paint an extremely biased position without covering the full gambit of what is really needed to build and maintain a system like you are proposing. The reality, it sucks.

Not to mention the other things you can do with NSInvocation that can’t be mimicked with static code.

Update (2014-12-13): Daniel Luz:

I can only infer the use case from what was presented, but it seems to me you solved the wrong problem here

Friday, December 12, 2014

CodeRunner 2

CodeRunner 2 has better syntax coloring and code completion, among lots of other improvements (via Gabe Weatherhead):

If you have purchased CodeRunner on the Mac App Store, you can choose to pay if you want, or you can get a copy of CodeRunner 2 for free. To get a free license, make sure you have the Mac App Store version on your computer before downloading CodeRunner 2. Then simply download CodeRunner 2 and follow the instructions in the licensing window. Don’t replace your Mac App Store copy of until after you’ve migrated.

Because of new Mac App Store restrictions, CodeRunner 2 is currently only available outside of the Mac App Store.

Drive Genius 4

Prosoft Engineering:

Get faster performance from your Mac while also protecting it with Drive Genius 4. The award-winning and improved DrivePulse® feature alerts you to hard drive issues before they become major problems. Optimized for OS X Yosemite, top features like Defrag and DriveSlim® will help keep your Mac running fast. The all-new BootWell™ tool lets you create a special bootable secondary drive to Defrag or Repair your main hard drive. You can also personalize and organize your Mac hard drive icons with IconGenius™.

The best new feature I see is that you can now run tools simultaneously on multiple drives—important because, with today’s drive sizes, simply checking for bad blocks can take more than a day. MacUpdate has a more complete list of the changes.

Papers, Please and App Content Ratings

John Gruber:

This case highlights the way Apple holds games (and apps in general) to a different standard than other iTunes content. Movies, music, and books are not held to the same PG-13-ish standards that apps are. I can buy A Clockwork Orange from iTunes, but if I made a game that showed the exact same things that are depicted in that film, it’d have little chance of being approved. Conversely, an R-rated movie version of Papers Please could depict this scene without a hitch when it comes to iTunes.

This has never made much sense to me. Apple has a more extensive system for rating the content of apps than it does for movies. And all apps must have ratings and be reviewed by Apple, whereas some movies are not rated at all. Yet, even with age-appropriate ratings, there are some types of app content that won’t be accepted at all.

Lucas Pope:

Just talked to Apple. The initial rejection for porn was a misunderstanding on their part. They suggested I resubmit with the nudity option.

Tearing Down Swift’s Optional Pyramid of Doom

Colin Eberhardt:

With Swift, pyramids become an issue when you have to unwrap multiple optional values before performing some logic […] In the above code, the println statement will only be executed if all three of the optional variable a, b, and c are non nil. The more optionals your code relies on, the deeper the nesting becomes.


It is actually quite a straightforward task to move the nested if-let statements into a utility function, where a given function is only invoked if all the optional parameters are non nil […] The above function unwraps the optional parameters and invokes the given function with the unwrapped results. Notice that the unwrapped variables have the same name, and shadow, the optional parameters, a naming convention proposed by Sam Davies, which I quite like.

This is still less than ideal, though, because now your code is running inside of an anonymous function. You can’t, for example, return out of the original scope. This is an example of where it would be helpful if Swift had macros, although I think this particular use case is important enough that the language should have a built-in syntax.

Update (2014-12-13): Tim Schmitz:

I think it's worth making some tweaks to how optional unwrapping works, and I have two suggestions.

Building Google Maps

Greg Miller (via John Gordon):

On a recent visit to Mountain View, I got a peek at how the Google Maps team assembles their maps and refines them with a combination of algorithms and meticulous manual labor—an effort they call Ground Truth. The project launched in 2008, but it was mostly kept under wraps until just a couple years ago. It continues to grow, now covering 51 countries, and algorithms are playing a bigger role in extracting information from satellite, aerial, and Street View imagery.


And as the data collected by Street View grew, the team saw that it was good for more than just spot-checking their data, says Manik Gupta, group product manager for Google Maps. Street View cars have now driven more than 7 million miles, including 99 percent of the public roads in the U.S. “It’s actually allowing us to algorithmically build up new data layers from information we’ve extracted,” Gupta said.


Yet satellites and algorithms only get you so far. Google employs a small army of human operators (they won’t say exactly how many) to manually check and correct the maps using an in-house program called Atlas. Few people outside the company have seen it in use, but one of the most prolific operators on the map team, Nick Volmar, demonstrated the program during my visit. (There’s also a fascinating demo in this video from Google’s 2013 developers conference).

Twitter Clients in 2014

Federico Viticci:

But 2014 Twitter is bigger than Twitterrific and Tweetbot. Today’s Twitter goes beyond text and a traditional display of the timeline – it encompasses native photos (and soon videos), interactive previews, advanced recommendation algorithms, photo tagging features, and a fully indexed search. I didn’t know how much I would come to rely on Twitter’s new features until I started using the official app and now, in spite of design details and advanced functionalities that I still prefer in third-party clients, I don’t feel like I want to switch back.

And that’s because the basic Twitter experience in 2014 is different. Twitter is split in Legacy Twitter and Modern Twitter, and it increasingly seems like users and developers of classic clients will have to stay in the past of the service. Perfectly functional (for now), beautiful in their delightful touches, but ultimately limited.

I’m perfectly happy using Legacy Twitter.

Why Digital Cameras Have a 30-Minute Video Recording Limit

Norman Chan (via John Gordon):

Back in 2006, the EU controversially decided to classify high-end digital cameras as video recorders, which attached a customs duty of 5-12% for digital cameras imported into Europe. The classification was decided not just based on digital cameras’ improving abilities to record video through its lens and sensor, but their ability to record direct input from external sources like televisions. A home video recorder tax would theoretically offset money lost from users recording movies off broadcast television or cable onto digital devices, though the EU has never been very clear on the tax’s intent. The tax’s consequence, though, has been felt in every digital camera user looking to use a DSLR in place of a camcorder, as camera manufactures would rather limit recording capability in software than raise the price of its cameras (or lower their margins).

Wednesday, December 10, 2014

Insecure Keyboard Entry

Daniel Jalkut:

I’ve been running my tool for a few weeks, confident in the knowledge that it will prevent me from accidentally typing my password into a public place. But its aggressive nature has also revealed to me a couple areas that I expected to be secure, but which are not.


The nice “•” is new to Yosemite, I believe. Previously tools such as sudo just blocked typing, leaving a blank space. But in Yosemite I notice the same “secure style” bullet is displayed in both sudo and ssh, when prompting for a password. To me this implies a sense of enhanced security: clearly, the Terminal knows that I am inputting a password here, so I would assume it applies the same care that the rest of the system does when I’m entering text into a secure field. But it doesn’t.


Apple makes a big deal in a technical note about secure input, that developers should “use secure input fairly.” By this they mean to stress that any developer who opts to enable secure input mode (the way Terminal does) should do so in a limited fashion and be very conscientious that it be turned back off again when it’s no longer needed. This means that ideally it should be disabled within the developer’s own app except for those moments when e.g. a password is being entered, and that it should absolutely be enabled again when another app is taking control of the user’s typing focus.

Design Comparison of Apple Maps and Google Maps

UX Launchpad (via Ole Begemann):

Google has decided, in many places in Android and their iOS apps, to feature search prominently. And that prominent placement puts the microphone to the right of the text field. Apple, on the other hand, puts their microphone in the keyboard itself.

Apple Maps doesn’t need to feature the microphone because, unlike third-party apps, it can use the hardware home button or “Hey Siri.”

Ok, it looks pretty abstract like that. But the big takeaway is that they’re doing the same thing, in the same order, but Apple uses five screens and Google uses six. But, again, fewer steps doesn’t necessarily mean better! We’ll analyze those screens in a moment.


Apple doesn’t have public transit or biking information. Maybe they’ll add it one day. But for today, that means their flow can be a lot simpler. The single feature they can match with Google is “Choose alternate paths, including walking”. So Apple featured it on their third screen with a label rather than using more complex and heavyweight controls.


Once again, tapping the “directions” button changes the flow from three screens to two. Once again, they drop the user directly into a screen that assumes your starting location is where you’re standing. Once again the suggestions switch from general guesses to a search-while-you-type pattern.


I love this comparison. Google is optimizing for driving because everything is one tap away. Want to cancel the trip because you’re looking for parking? One tap. Want to figure out how to turn on the traffic map? One tap. Want to re-orient the map to the direction you’re facing? One tap. It’s a very flat system where everything is right there, even things like seeing what time it is our checking to make sure your battery is ok.

Apple is optimizing for driving because it’s tucking everything away. There’s far more canvas available to show the map. When you drag the screen with your finger, it snaps back into place rather than putting you in another mode. It doesn’t show the current time, but it does tell you how many more minutes you’ll be driving, and your estimated time of arrival. Apple is doing what Apple does, for better or worse. They’re cutting as close to the bone as they possibly can. Nothing is assumed to be necessary on this screen.

Tuesday, December 9, 2014

Date Formatters, Calendars, and Locales

Mike Abdullah:

This shows that setting the formatter’s locale passes that onto the calendar too, which suggests that maybe NSDateFormatter.locale is just a convenience.

But if you try setting the calendar’s locale directly, that leaves the formatter’s locale property alone. So the formatter does have its own direct locale reference (as in my diagram above). This potentially leaves you with a formatter and calendar that reference very different locales. Would that cause nasty things to happen? Who knows!

Better documentation needed. on Debugging

I already linked to one article of the December, but the whole issue is great. The other articles are:

+[NSLocale preferredLanguages] vs -[NSBundle preferredLocalizations]

Cédric Luthi:

Sometimes, you need to know which language your app is running in. Often, people will use +[NSLocale preferredLanguages]. Unfortunately this tells nothing about the language the app is actually displaying. It will just give you the ordered list as found in Settings → General → Language & Region → Preferred Language Order on iOS or System Preferences → Language & Region → Preferred Languages on OS X.

Imagine that the preferred language order is {English, French} but your app is German only. Calling [[NSLocale preferredLanguages] firstObject] will give you English when you want German.

The proper way to get the actual language used by the app is to use [[NSBundle mainBundle] preferredLocalizations].

DiskWarrior 5


Ships on a bootable flash drive to repair your startup disk. Flash drives start up much faster than DVDs and can be updated as needed.


Repairs partition table damage. Sometimes the damage is to the map that describes all your drive's partitions which makes all your partitions unavailable. DiskWarrior 5 can repair standard Mac GUID partition tables when started from the DiskWarrior Recovery flash drive.


Significantly faster. For many disks, directory rebuilding is twice as fast as the previous version.


Recovers more data from drives with hardware malfunctions. Recover your important files from most failing drives, possibly saving you thousands of dollars in professional recovery costs.


Drives containing Time Machine back ups can have enormous directories that were often too large for DiskWarrior 4. The 64-bit memory addressing of DiskWarrior 5 allows these drives to be repaired or recovered.

It’s compatible with Mac OS X 10.5.8 through 10.10.

Out of Touch

Ole Begemann:

Apple’s remarkable track record of bad decisions in the past few months makes me wonder if management has completely lost touch with reality.


If, instead of making capricious decisions for people how they can use their phones, Apple cracked down on Twitter for privacy violations, or had done so in the past with Path, for example, or the countless developers who use push notifications for spam, app review could actually help position the iOS platform in a way that’s consistent with company policy.

Joe Cieplinski:

This time it’s different, though. This time, there’s clearly a conflict within Apple going on. I simply can’t believe that Craig Federighi’s team built all those wonderful new APIs into iOS 8 and didn’t intend for us to do anything interesting with them.

Jason Snell:

As with the PCalc widget controversy—which recently reran as the Drafts widget controversy—the issue here isn’t that Apple is rejecting apps. Apple can make any App Store policies it wants.

The issue is that nobody (except perhaps someone at Apple) seems to understand what the rules are regarding what apps can and can’t do.

Adam Oram:

If Apple wants its ecosystem — perhaps its most valuable asset — to shine, it needs to nail down its policies from top to bottom. Every person in the chain should know what is and is not allowed and this information should be communicated clearly to developers.

Tim Schmitz:

As developers, we can’t afford to spend time building features that we won’t be able to ship. Good iOS and Mac developers want to obey the spirit of the law when it comes to the App Store rules. We want to build features that Apple will allow us to ship, and we want to take advantage of the newest features in the OS. As it stands, the company is making it riskier for developers to do so. Giving a window into the thought process behind enforcement of the rules would be a great start toward fixing that.

Pierre Lebeaupin:

The latest events, of which the Transmit iOS feature expulsion is but the most visible, have made me think and eventually reach the conclusion that the iOS (and Mac, to an extent) platform is not governed in a way suitable for a platform of this importance, to put it lightly; even less so coming from the richest company on Earth. Apple has clearly outgrown their capability to manage the platform in a fair and coherent way (if it ever was managed that way), at least given their current structures, yet they act as if everything was fine; the last structural change in this domain was the publication of the App Store Review Guidelines in 2010, and even then, those were supposed to be, you know, guidelines. Not rules or laws. And yet guidelines like those are used as normative references to justify rejections and similar feature removal requests. This is not sustainable.

Update (2014-12-10): David Sparks:

I’d argue they’ve always had warring factions over this issue but the battles have always been behind closed doors in Cupertino. Now it’s public. Now we actually see some really great functionality only to have the carpet yanked from under us. If Microsoft or Google were changing its mind publicly like this, all of us Apple geeks would be giggling about it.

There is no doubt in my mind who should win. I think the extensions mentioned above only make iOS better. They are all in applications that users must download and extensions that users must enable. I can’t see how the “this will confuse users” argument holds any weight since these all require action by the user to enable.

Update (2014-12-15): Adam C. Engst:

So let’s take score. Apple gets bad press and loses developer loyalty, though the company presumably prefers that to setting and following explicit guidelines. Developers waste vast amounts of time and money trying to please Apple. Users lose because useful apps are rejected, removed from the App Store, or never developed in the first place. In fact, the only player who wins is the media, which gets to publish story after story about how big bad Apple is grinding small developers underfoot.

But you know what? I don’t like publishing such stories. Call me old-fashioned, call me naive, or call me a Pollyanna, but I want iOS to be a platform upon which developers can write software that will astonish me and give me capabilities I could never have imagined. Instead, Apple has constructed a tightly controlled system where survival requires pleasing a capricious boss and gaming a system of artificial rules and regulations. As much as I appreciate Apple’s hardware and software achievements, I strongly disagree with the company’s policy management.

Update (2014-12-17): Federico Viticci:

The original Drafts widget was removed from the app after an Apple rejection two weeks ago. As with PCalc and Transmit before, Apple reversed their decision and the widget is back – and it’s even better than before.

Rewriting Robotics Software in Swift

Brad Larson (via John Siracusa):

At SonoPlot, we just undertook a full rewrite of our robotic control software from Objective-C to Swift. While at first it might appear crazy to rework a large, stable project in a brand-new language, we did so after carefully examining sources of bugs in our Objective-C application and determining that Swift would prevent a large percentage of them.


I found myself repeatedly saying to myself or Janie that a particular bug wouldn’t have even compiled under Swift, or would have thrown an immediate exception. When we totaled up bugs like this, we found that ~40% of bugs shipped to customers in the last three years would have been caught immediately by using Swift. The primary classes of these bugs were:

  • Silent failures due to nil-messaging
  • Improperly handled NSErrors, or other Objective-C error failures
  • Bad object typecasts
  • Wrong enum lookup tables being used for values

This is a great exercise, and of course I like that Swift makes these types of bugs impossible. On the other hand, although I certainly write my share of bugs, I can’t remember the last time one fell into one of these categories. I haven’t counted, but my guess is that it’s less than 1%.

Flare and Representations of an iPhone

Craig Hockenberry:

I guess today is the day for inexplicable App Store rejections. Just got one for Flare using an iconic representation of an iPhone…

Craig Hockenberry:

Now Apple is recommending that we remove the button to comply with trademarks with a link that says realistic images should be used.

Craig Hockenberry:

The iconic version of the iPhone was used because a previous one was too realistic (but it had been on the store since release.)

Craig Hockenberry:

It’s so frustrating that we have to cater to the whims of individuals who interpret the rules differently.

Activity Tracing

Florian Kugler:

This year’s WWDC had an excellent session about it, but we thought it would be a good idea to give another overview here, since it is not widely known yet.

The basic idea is that work done in response to user interactions or other events is grouped under an activity, no matter if the work is done synchronously or if it’s dispatched to other queues or processes. For example, if the user triggers a refresh in your app, you’ll know that this particular user interaction caused a subsequent crash, even if it happens on a different queue and several other code paths could have led to the crashing code as well.

Activity tracing has three different parts to it: activities, breadcrumbs, and trace messages. We’ll go into those in more detail below, but here’s the gist of it: Activities allow you to trace the crashing code back to its originating event in a cross-queue and cross-process manner. With breadcrumbs, you can leave a trail of meaningful events across activities leading up to a crash. And finally, trace messages allow you to add further detail to the current activity. All this information will show up in the crash report in case anything goes wrong.

Sounds terrific.

Monday, December 8, 2014

Launcher Followup and Thoughts on the App Store Review System

Greg Gardner:

I met my goal and Launcher was approved and went out on the App Store on September 17, the day iOS 8 was released. For the first 4 hours it was out, it was actually featured in the App Store and things were going really well. It wasn’t until 6 days later that I got the dreaded call from App Review where they explained to me that the executive team had met and determined that Launcher needed to remove its widget or it would be taken off of the App Store. For those unfamiliar with the story, I ended up submitting a new version that I felt was a decent compromise based on my understanding of the problem that Apple had with the widget, but Apple didn’t feel it was valid, so they immediately removed Launcher from the App Store.


Over the past couple of months I’ve had several conversations with people at App Review and the best way that I can explain the reason why they don’t want Launcher’s functionality to exist on iOS is because it doesn’t meet their vision for how iOS devices should work.


During one of my conversations with someone at App Review last month, I asked if they could tell me if some of these new apps being accepted slipped through or if their use of widgets was deemed acceptable. I heard what had come to be a popular refrain from them. They couldn’t discuss other apps with me, they would look into those apps, and if I submitted a new app with that specific functionality they would be happy to review it and let me know if it was acceptable or not by either rejecting or accepting my new app. They steadfastly refused to tell me if a certain use of a widget was acceptable or not ahead of time.


The Apple representative responded by saying that they prefer that the rules remain vague because that allows developers to come up with innovative ideas and also allows Apple to be flexible in case they change their minds later.


During this same conversion, I also asked specifically why Launcher was removed from the App Store after 9 days when other similar apps are still available weeks later. The answer to this question was the most interesting and informative response I had ever heard from them. They basically said that Launcher was a trailblazer in uncharted territories and that they felt that they needed to make an example of it in order to get the word out to developers that its functionality is not acceptable without them having to publish new specific guidelines. And they said that the fact that they aren’t seeing hundreds of similar apps submitted every day is proof to them that taking down Launcher was successful in this regard.

This was a pretty big revelation to me. After Launcher was rejected and the press picked up on it and started writing articles which painted Apple in a bad light, I was afraid that Apple might be mad at me. But it turns out that was actually the outcome they were looking for all along. They acted swiftly and made me the sacrificial lamb. And after that, removing other apps with similar functionality became a low priority for them.

Update (2014-12-09): Marco Arment:

This is a disgraceful, disrespectful, and cowardly way to create and enforce policies, and it’s burning a lot of developer motivation to work on iOS.

Tyler Hall:

It’s becoming harder and harder to justify the risk of building an app and launching it on the App Store. Developers bear all of the risk. And even after approval by Apple, there’s the looming threat that Apple could reverse their decision at any time.

Saturday, December 6, 2014

PDFpen 2 and Paid Upgrades via App Store Bundles

Michael E. Cohen:

To make upgrade prices possible, Smile has taken advantage of a new App Store feature for developers, the ability to sell software bundles (collections of multiple apps), along with another new App Store feature, the ability to offer older versions of their apps to purchasers who cannot run the latest versions of those apps on their devices.

Here’s how it works: By making PDFpen 2 require iOS 8, Smile can continue to sell the older versions of PDFpen for iOS (there is one such app for iPhone and another for iPad). And because developers can now offer software bundles, Smile has created two bundles for owners of previous versions of PDFpen. The first is a $19.99 bundle that contains both the old PDFpen for iPhone along with the new PDFpen 2 (a universal app that runs on both iPhone and iPad). The second bundle, for owners of the old PDFpen for iPad, includes both the old iPad app and the new universal app: this bundle costs $21.99.


Because the new PDFpen, from the point of view of iOS, is a new app and not an upgrade to an older app, you can install it on your iOS device without deleting the older version first. And, in fact, you want to do that because when you launch the new app it migrates whatever files the old app kept in its private document storage to the new app. Once that one-time migration takes place, you can delete the older app if you like.

This is a clever hack, but Apple should provide a real solution for upgrade pricing that’s friendlier for both users and developers.

Apple’s First Employee: Bill Fernandez

Jason Hiner:

Daniel Kottke, one of Apple’s first dozen employees, said, “[In 1976] the Apple II did not even work. Woz’s prototype worked. But when they laid it out as a circuit board, it did not work reliably… It was unacceptable. And Woz did not have the skills to fix that… But, it was even worse than that. They did not even have a schematic.”

Newly funded by investors, Apple had just hired Rod Holt as the company’s first engineering chief, and this was one of the big problems that Holt walked into when he took the job. At the time Woz’s Apple II prototype was a bunch of wires and chips in a cardboard shoebox. The tiny Apple team had to take this amazing concept machine and turn it into a product that could be manufactured and sold in stores.

So Holt handed the first task to Apple technician Bill Fernandez.

When it came to computers and electronics, few people knew the workings of Wozniak’s mind better than Fernandez. The two had grown up as neighbors and had known each other since the fourth grade. In high school, Fernandez told Wozniak that there was a kid he needed to meet because he was into electronics and practical jokes just like Woz. It was a kid named Steve Jobs. Later, Wozniak acquired a bunch of different electronics parts and took them to Fernandez’s garage, where the pair worked on assembling the stuff into their own working computer that was years ahead of its time.

Apple Makes Panic Remove Transmit’s Export Feature

Panic, introducing Transmit for iOS in September:

Then came the introduction of iOS 8. It’s an exciting update for users, and a really exciting release for developers, not least because of a little something called App Extensions. By utilizing App Extensions, Transmit could effectively provide standard file transfer protocols for any iOS 8 app. Overnight, this idea that made very little sense suddenly made all the sense in the world.


You’re probably already familiar with the Share button in iOS. If you’re, say, looking at a photo, you can tap the Share button and send the photo by email, iMessage, AirDrop, and so on. With Transmit iOS installed, you can also now send that photo (or other document) to any FTP, SFTP, WebDAV or Amazon S3 server, right from Photos.

In other words, any iOS app that supports the Share sheet magically gains support for these protocols when you install Transmit iOS.

This sounded like a great feature, finally a way to easily share files between iOS apps and other devices, using any of a number of protocols.

Nate Boateng, yesterday:

Ugh, Apple is messing with Transmit too.

Federico Viticci:

Apple now forcing @panic to remove iCloud Drive functionality. Why? Dozens of apps can “send” to iCloud Drive.

Federico Viticci:

Specifically, export feature removed. No more export to iCloud Drive, Dropbox, etc. Before and after.

Nick Heer:

The thing that PCalc, Drafts, and Transmit all have in common is that they’re power user tools. I’d wager heavily that their users are more likely to be longtime Apple supporters and very tech savvy. Never mind the silliness of going after developers who actually use the new APIs; the stupidity of taking on software used by Apple’s most ardent supporters is baffling to me.

Update (2014-12-08): Cabel Sasser:

Also, at Apple’s request, we had to remove the ability to “Send” files to other services, including iCloud Drive.

In short, we’re told that while Transmit iOS can download content from iCloud Drive, we cannot upload content to iCloud Drive unless the content was created in the app itself. Apple says this use would violate 2.23 — “Apps must follow the iOS Data Storage Guidelines or they will be rejected” — but oddly that page says nothing about iCloud Drive or appropriate uses for iCloud Drive.

If the issue is just iCloud Drive, why did we remove the other destinations? We had no choice.


We haven’t shared, and likely never will share, most of those stories. To be clear, we always work all of the angles available to us to keep our software great, and there’s no doubt there are countless great people at Apple who are doing wonderful work and want the best for all developers. But we have to remember Apple is now a massive organization with countless divisions — the App Review team isn’t even in Cupertino, for example — and sometimes that means the wheels turn slowly, or the car, well, drives backwards. It’s hard to describe the legitimate emotional toll we feel when we’re angry or frustrated with a company we love so deeply. But then we realize it’s never Apple we’re frustrated with. It’s always the App Store.

Marco Arment:

Another great iOS 8 feature crippled by capricious, unwritten, after-the-fact policies.


This sure feels like the ramifications of an internal turf war.

Federico Viticci:

The “Export to iCloud Drive” feature has become popular among apps that deal with files and user documents: it can be found in hundreds of apps updated for iOS 8 such as Pixelmator for iPad and Apple’s own GarageBand. Restricting the pool of similar apps to apps that can download files, the same feature can be found in popular file managers such as Documents 5, GoodReader, and FileApp – all of them updated for iOS 8 and available on the App Store.

John Gruber:

I thought the whole point of iCloud Drive, and iOS 8’s new sharing sheet for storage services like Box and Dropbox, was to allow users to do exactly what Transmit enabled.

Nick Heer:

There doesn’t appear to be a common understanding of what rules the app reviewers should be focusing on, or even what rules exist — as far as I can tell, there’s no written rule that prohibits what Transmit was doing here. The lack of consistency is especially frustrating for developers. They become increasingly unsure of how much effort they should invest in features that shouldn’t be controversial. They don’t know if they’re the next ones to be rejected for some feature while dozens of other apps remain on sale with a similar feature.

In this particular case, I don’t understand what Apple gains by having Panic remove their export to iCloud Drive feature. I don’t understand what Apple or their users would lose — financially, morally, ethically, or in any other way — by allowing Transmit to retain this feature. If anything, this entices people to use iCloud Drive.

Update (2014-12-11): Charles Arthur (via James Thomson):

The Guardian understands that Panic will be allowed to reinstate sharing - but that only raises the question of why it was stopped in the first place. Apple declined to comment to the Guardian on the banning or reinstatement of the functionality.


The Guardian understands that the reversal over PCalc was the result of internal discussions at Apple where the initial rejection by the App Store team was overruled by executives.

Cabel Sasser:

After a considerate conversation with Apple, Transmit iOS 1.1.2 has been released with restored “Send To” functionality.

Developing Keyboards for iOS

Norbert Lindenberg on what he learned developing his English IPA Keyboard (App Store):

Yes, some of these suggestions sound a little desperate, and for many keyboards you will at some point have to request full access. Things would be a lot easier if Apple allowed containing apps to write into their keyboards’s containers, similar to how the Mail app delivers attachments into an app’s Inbox directory, without the need for full access. This would let containing apps send dictionaries and configuration settings to the keyboard while protecting user input from being leaked out of the keyboard.


A number of keyboards have been rejected based on section 25.6, so it seems something is required. For the first version of the English IPA keyboard, I argued that the keyboard was designed as a supplementary keyboard, not as a user’s primary keyboard, and therefore shouldn’t have to support all the keyboard types, similar to Apple’s emoji keyboard. My keyboard was approved, but at least one other developer using similar arguments saw his app rejected.


It’s much better to design custom images for the function keys that your keyboard needs. There doesn’t seem to be any way for third-party keyboards to access the images that Apple’s built-in keyboards use.


Reading the documentation might lead you to expect that your input view controller’s textDidChange method will be called when “text has changed in the document”, or selectionDidChange when “the selection has changed in the document”. Reality as of iOS 8.1 is that textDidChange and its buddy textWillChange are called when the keyboard’s client view becomes or resigns as first responder and when the selection changes, and selectionDidChange and its peer selectionWillChange are never called. Of course, this might get fixed eventually, so don’t rely on this either.


The documentation for UIKeyInput.deleteBackward states that it deletes “a character”. Those familiar with Unicode, NSString, and Swift’s String type know that the word “character” is quite overloaded – it could mean a Unicode code point, a UTF-16 code unit, or an extended grapheme cluster. But that’s only where the trouble starts.


Implementing forward deletion as described in the API Quick Start for Custom Keyboards section of the Guide also does not work. It depends on the assumption that the increment used by adjustTextPositionByCharacterOffset matches what deleteBackward deletes, but in reality that’s not always the case.


It seems unlikely that you could invade the user’s privacy by playing click sounds when she taps a key, but the method in charge of these sounds, UIDevice.playInputClick, hangs for several seconds rather than doing its job when called without full access.

Friday, December 5, 2014

Five Fixes for OS X 10.10 Yosemite


It’s common advice to wait for the X.Y.1 release of a new version of OS X before upgrading, since Apple often fixes bugs that crop up at launch quickly. OS X 10.10.1 Yosemite has been out for a bit now, though, and while it is working fine for many people, there are still a variety of complaints making the rounds on the Internet. Here then is a collection of five problems and solutions (or at least workarounds) that we’ve either experienced or had reported to us.

Probably the most annoying bugs for me are crashes (mainly Mail, Safari, Spotlight, the Dropbox extension, and codesign), Notification Center not remembering hidden applications, and my DYMO label printer not working reliably.

Objective-C Debugging Cheat Sheet

Tim Ekl:

After some nudging from coworkers, I took some time and scraped together all the various private methods I could find (as well as a few suggested on Twitter) and combined them into one debugging cheat sheet, which I’m making available right here. Download it today, and suggest more!

Core Graphics Logging Input Data to /tmp Directory

Mozilla (via Jacob Garbe):

Security researcher Kent Howard reported an Apple issue present in OS X 10.10 (Yosemite) where log files are created by the CoreGraphics framework of OS X in the /tmp local directory. These log files contain a record of all inputs into Mozilla programs during their operation. In versions of OS X from versions 10.6 through 10.9, the CoreGraphics had this logging ability but it was turned off by default. In OS X 10.10, this logging was turned on by default for some applications that use a custom memory allocator, such as jemalloc, because of an initialization bug in the framework. This issue has been addressed in Mozilla products by explicitly turning off the framework's logging of input events. On vulnerable systems, this issue can result in private data such as usernames, passwords, and other inputed data being saved to a log file on the local system.

I have been using Firefox 33.1 and did not see any CGLog_ files on my Mac.

Xcode Consolation

Daniel Jalkut:

Those are the basics, but another trick, I believe it was called ret in Gdb, comes in handy often:

  • thread return – return immediately from the current stack frame

You could use this if you are stuck in some function that is crashed, for example, but you know that returning to the caller would allow the process to continue running as normal. Or, you could use it to completely circumvent a path of code by breaking on a function and bolting right out, optionally overriding the return value.


In fact, mucking about with system symbols is one of the great tricks of the console, and lldb’s built-in “breakpoint” command brings with it superpowers that can’t be touched by Xcode’s dumbed down GUI-based controls. For example, what if we wanted to set a breakpoint that would catch not only +controlTextColor, but any similar variation? Using lldb’s support for regular expression breakpoints, it’s a snap[…]

I fall into Group 4: appreciate the console for occasional tricks but mostly avoid the debugger entirely, in favor of logging and assertions added directly to my code. I am usually more concerned with figuring out what’s happening on a customer’s Mac than my own. So an interactive debugging session is usually not an option.