Archive for December 9, 2014

Tuesday, December 9, 2014 [Tweets] [Favorites]

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.