Thursday June 12, 2014

The Paradigms of Swift

Rob Napier on why Swift is not a functional language:

Swift is a multi-paradigm, but it’s not OOP/functional. It’s OOP/generic. Generic programming is primarily concerned with general purpose algorithms that can be applied to arbitrary types. It has some similarities with functional programming, and there are certainly languages that are both functional and generic, but generic programming doesn’t care if the algorithms are functions (things that take and return immutable values) or processes (things that mutate state).

Sunday June 08, 2014

New O'Reilly Videos For iOS (with Yours Truly)

If you’ve ever wanted to peek over the shoulders of Josh Smith and me to watch how we build iOS applications, check out these brand new videos published by O’Reilly. We cover a range of stuff from the paper prototyping phase to how we approach building transitional animations, debugging, testing, and more.

We are quite proud of how these videos turned out. We had a chance to be among the first batch of O’Reilly’s new video content initiative. Josh has even gone on by himself to do a video on Core Data and security (should be out soon). It’s been an honor and a lot of fun to work with the O’Reilly team. They have a professional video crew that did all the dirty work with lighting, framing, and editing. We just brought the content.

If you’re interested in doing videos of your own content with O’Reilly then get in touch with Amy Jollymore. They are looking for new authors.

Friday June 06, 2014

Unit Testing with Swift

Tuesday June 03, 2014

Where The Metal API Could Be Headed

For those who (like me) were curious to know more about the reasoning beind the new Metal API Apple announced at WWDC 2014, Ryan Smith at AnandTech describes why the graphics industry wants to strip away the higher layers like OpenGL and DirectX for better performance. He also speculates about use beyond graphics:

The low-level nature of Metal on the other hand means that it’s a good (or at least better) fit for GPU computing, as the lack of abstraction for graphics makes it more capable of handling the workflows and data types of compute tasks. This is one area in particular where the Metal shader language being based on a subset of C++11 is a benefit to Apple, as it provides a solid foundation for writing compute kernels.

Wednesday April 30, 2014

✦ Announcing KeyGrip: the Pasteboard Presentation Tool

Josh Smith and I have been busy building a tool to help us tell a story while live coding in our presentations and workshops. We’ve decided to open source it and we’re ready to share it with you.

Behold: KeyGrip.

KeyGrip quick screencast

A while back Apple wrote a Mac app called Demo Monkey that gave you a list of things you could click on to put them on the pasteboard. It made presenting code a little bit easier since you could break up what you wanted to show into chunks, weave it into a narrative, and paste as you go to demonstrate.

But that required having a window visible on your Mac with a list of clips. And if you’re like me, you still needed script notes somewhere near by to stay on track and remember what clip goes where in the flow.

That’s why we wrote KeyGrip. After iterating on a few different ideas, we settled on a Mac server and a Universal iOS client. Run the client on an iPad Mini and it shows your presenter notes interspersed with code snippets—all generated from a Markdown file. If you tap on any of the code snippets, it instantly shows up on your Mac’s pasteboard.

The Mac and iOS apps communicate seamlessly over Bonjour. All you have to do is make sure they have the same string identifier so they can find each other. The Mac server also live pushes changes to the iOS client while you work on the Markdown script. You can get into a slick editing workflow where you adjust your notes and try out your code examples.

Yeah, I’m biased. But I gotta say…this thing is like magic.

You can download a binary of the Mac server right from the README. You can download the source and build the iOS app to install it on your favorite device. Enjoy!

Oh, and special thanks to Derek Briggs for the icon. He’s got plans to help us polish up the interface a bit over time, too. :)

Friday March 14, 2014

✦ UI Screen Shooter - Now Simpler and More Robust Since Xcode 5.1

The UI Screen Shooter scripts have been updated for Xcode 5.1! I’m quite pleased with the results. The instruments command line tool now lets us specify the simulator device directly from the command line. I’ve cleaned up the scripts and they are much easier to follow. Kudos to Apple on this! And thanks to Christoph Koehler’s issue that brought all this to my attention.

If you’d like more details on what changed, read on.

The Old Way of Hacking Things

You no longer have to force Xcode to pick the iPhone architecture with the TARGETED_DEVICE_FAMILY configuration parameter. Previously, the instruments command line tool would not let you pick whether you wanted to run on the iPad or iPhone simulators. If an app was marked as universal, Instruments would always launch the app in the iPad simulator. The hack to get around that was to set the TARGETED_DEVICE_FAMILY to 1 which would force Xcode to build the app as iPhone only. Instruments would then oblige and only launch the iPhone simulator.

In order to get screenshots on both iPad and iPhone, you had to build twice with different TARGETED_DEVICE_FAMILY settings. It was a real pain, but it worked.

You also no longer have to muck with the simulator preference files to force the simulator to launch in a specific language. Previously, I hacked together a shell script that used PlistBuddy to alter the preference files, forcing the simulator to think only a specific language and locale was available. But thanks to a post by Ole Begemann on NSUserDefaults, I realized that I can force the simulator to pick a locale by just passing special command line parameters.

And that’s not all! You also no longer need to force the simulator to a specific device model with AppleScript! Previously (you can see a theme here), I used an AppleScript that launched the simulator and picked the proper device type from the Hardware menu. When Instruments next launched, it would use the previous simulator setting. Again, it worked but it was a horrible hack.

Update: Brad Grzesiak just pointed out to me that there’s no longer the need for my pty/tty hack in the unix_instruments wrapper since the Instruments command line tool no longer buffers it’s output when piped. We still need the wrapper script, though, because Instruments doesn’t return a non-zero status code on JavaScript failure, but hey, I’ll take every opportunity I can get to remove my workaround code.

The New, Glorious Way

All that changed in Xcode 5.1 because Instruments now supports specifying the simulator hardware type and iOS version all from the command line! To find out what options you currently have you on your machine, just type the following:

instruments -w help

And then you’ll see something like this:

iPhone Retina (3.5-inch) - Simulator - iOS 7.1
iPhone Retina (4-inch) - Simulator - iOS 7.1
iPhone Retina (4-inch 64-bit) - Simulator - iOS 7.1
iPad Retina - Simulator - iOS 7.1
iPad Retina (64-bit) - Simulator - iOS 7.1

Finally! It doesn’t matter what you put after the -w flag. You just need to pass something invalid and instruments gives you the valid options. Pass one of these strings in like so to use it:

instruments -w "iPad Retina - Simulator - iOS 7.1" ...

Note that you need the quotation marks because of the spaces in the full name of the simulator hardware type and version. Also, the -w flag must come at the start of the command line, before any other flags. Otherwise you get strange errors.

Check out the full screen shooter repository for more details. Use this as the basis to write your own screen shooting scripts. Enjoy!

Wednesday March 05, 2014

Our Sprite Kit Book Now In Beta

Josh Smith and I have been working on a Sprite Kit book with the Pragmatic Programmers for the past few months. It’s now released in beta!

Thursday February 27, 2014

Yes, *that* Brent Simmons

I’m quite enjoying Brent Simmons’ series of posts on his conversion back to Core Data from raw SQLite in the Vesper app. Yes, that Brent Simmons. In each post he states his latest concerns, asks questions, makes decisions, and follows up as he gets more information. It’s generated some heated discussions, yet he reacts graciously. Watching his design decisions change as he gets real time feedback is a treat. It’s like a case study for productive dialog.

Update: And thus far, he’s decided to abandon Core Data and return to raw SQLite with FMDB.

Wednesday February 26, 2014

NSUserDefaults - Not Just For Persistent Settings

Ole Begemann just wrote a nice article on NSUserDefaults. It’s a good overview for newcomers to the platform, but it also highlighted a feature that I hadn’t considered before—domains.

Different configuration data can come from, or be stored, in different domains. What surprised me most was the NSArgumentDomain. It’s a volitile storage space (won’t be persisted across app runs) and is populated at app launch from command line parameters. Remember the strange command flag syntax to turn on Core Data’s SQLite debug logs? It sets the values in the NSArgumentDomain of the app’s NSUserDefaults.

Tuesday February 25, 2014

Don't Write Off Tinkering In The Garage

Andy Arvanitis, of eero language fame, is at it again and experimenting with Idris, a Haskell like language with a simple interface to C. Which, of course, means he’s experimenting with bridges to Objective-C classes.

Idris fascinates me because it not only has a flexible syntax, but you can define your own syntax rules on the fly1. Andy shows off how he builds the same bracket and parameter list syntax you’re familiar with in Objective-C. It’s like programming language putty.

I love this kind of stuff. I know, I know, this adds to the complaint fodder about the creaking husk of Objective-C. I applaud work like what Andy is doing precisely because it charges our imagination with what’s possible—borrowing useful solutions in other arenas to experiment at the intersection of Objective-C/Cocoa’s history and today. I’m all for what happens when someone hermits up, thinks hard, and designs a language with specific goals. But, don’t write off the tinkering in the garage.

  1. And you thought Ruby’s metaprogramming possibilities were frightening!

Monday February 24, 2014

Apple's Secure Coding Guide

Monday February 24, 2014

Security Is Code Formatting

What a weekend. Apple released iOS 7.0.6 to plug a hole that let’s an attacker “capture or modify data in sessions protected by SSL/TLS”. Vague and ominous.

Then Adam Langley wrote up an excellent summary of the problem after code spelunking through the open source bits of iOS and OS X. W. T. F.

It’s all because of a goto statement that skips proper TLS verification under some circumstances. It was missed because of indentation that made it look like it was part of the if statement above. But because the if statement lacked curly braces, only the immediately following statement was covered by the conditional. The second goto always runs and skips the rest of the critical verification code. If an attacker knows how to cause this sequence of events, they have free reign with a man-in-the-middle attack.

<hindsight type=”shameless” scope=”20/20”>
Check brace-less conditionals and formatting, please. And write tests for security code wherever possible.

By the way, Golang’s code formatter would have enforced curly braces for these if statements and reformatted indentation to expose the lone goto automatically. Compiler enforced formatting rules for the win, eh?

For even more details, read Dave Farber’s write up of the situation.

Wednesday February 12, 2014

DTrace - Lightning Stolen From The Unix Gods For Use By Mere Mortals

After linking to the enjoyable read on strace by Chad Fowler, Mark Dalrymple enticed me to point out DTrace, which you might have heard of as the magic engine running under Apple’s Instruments monitoring and debugging tool. Personally, I’ve spent more time in Instruments than down in the bowels of DTrace, but I’ve bookmarked Mark’s posts as my starting place for when I need it.

Monday February 10, 2014

strace - Tool of The Unix Gods

Chad Fowler wrote up his experiences using strace to debug Lotus Domino problems back in the day. It’s a great story and a nice introduction to a useful tool for anyone using a language bolted on top of C and the Unix subsystems—like, say, Objective-C programmers!

Wednesday February 05, 2014

Solving The Huge View Controller Problem

Brad Grzesiak wrote a thoughtful piece on following the single responsibility principle when building view controllers in storyboards. His take challenged me since I had always thought the single responsibility principle was just a good guideline for making sure a class doesn’t do too much right now. But, as Brad points out:

By focusing on why the class might have to be changed, the Single Responsibility Principle allows us to think of how we interact with the code in the present instead of requiring us to project our minds onto the software’s future running environment. This, I believe, is an important, and freeing, distinction.

In other words, separating out the responsibilities clarifies where we need to look when requirements change. And the requirements always change. Software shares much in common with living organisms that must adapt to their environment. That adaptation is quite messy. The organism could get sick or sprout cancerous growths. It’s quite different from the process to build a finished structure, like a bridge, that only changes as it degrades according to the properties of the materials it was built with.

Brad demonstrates how he tries to minimize those cancerous growths in his software. It’s good to see more examples of breaking apart the responsibilities of a view controller into collaborating objects that all live together in a storyboard scene.

Monday January 27, 2014

The Failures of Teaching Test Driven Development

My fellow frozen Ohioan, Justin Searls, just wrote a great piece on the frustrations when learning how to unit test software. Justin’s been doing test driven development for some time now and has tons of practical experience in non-trivial software projects. I love his approach and if you saw my talk on using Xcode’s new unit testing toolkit and would like to know more about strategies to write unit tested code, definitely check out this post.

Monday January 27, 2014

The Early Bird Gets The CocoaConf

Just so you know, this Friday (January 31st) is the last chance to get a CocoaConf early bird ticket. It’s a great lil’ conference to connect with other iOS and Mac devs. I’m quite honored for the opportunity to participate with them. If I could, I’d give it a five star review in the App Store. ;)

Thursday January 09, 2014

TaskPaper Source Code Released

Jesse Grosjean just released the source code to the fine TaskPaper app with a very generous license.

Current status: Spelunking for stuff I didn’t know about Objective-C.

Thursday January 09, 2014

Generate Screen Shots Compatible With iTunes Metadata Uploader

Big thanks to William Entriken for doing the leg work to get my UI Screen Shooter example to generate the proper format that works with Apple’s iTunes Metadata Uploader. Check the README for more info.

There’s still a bit of manual legwork involved to get your app’s current metadata package and merge these new screenshots into it, but this will save a ton of time if you have localized apps in the store.

Thanks, William!

Wednesday January 08, 2014

So, You Want To Write A 2D iOS Game?

I’m pleased to announce that Josh Smith, James Dempsey, and I are planning a 2D game development workshop in Chicago on February 10th, 11th, and 12th. Through the course of those three days we’ll go over the basics of iOS for anyone who’s new to the platform, come up with and prototype ideas, and dive straight into Sprite Kit—one of Apple’s newest frameworks introduced in iOS 7.

But that’s not all. A ticket to the workshop also gets you three weeks of followup through office hours and mentoring to help move your game from prototype to App Store.

Three days and three weeks. We call it 3x3. We think you’ll call it awesome.

Check out the information page for more details and the syllabus. We’re running an early bird special. Buy a ticket before January 17th and it’s $2,000. Regular price is $2,500.

Feel free to email me if you have any questions!

And just so you know, this a Rubber City Wizards event.

Friday January 03, 2014

My CocoaSlopes Talk On XCTest

I completely forgot that a talk I gave at CocoaSlopes in Ogden, Utah on XCTest was to be recorded and posted on Youtube. Thanks to BJ Miller for pointing it out.

It’s a great overview of strategies as it relates to the new testing tools in Xcode 5. I walk through a demonstration of test-first development and dare to do some on-the-fly coding during the Q&A at the end—a great talk.

If you’re curious what tool I’m using to coordinate the demos and paste the snippets into Xcode as I tell the story…well, you’ll just have to wait a little bit longer. My colleague and I have something up our sleeve to announce soon. ;)

Tuesday December 24, 2013

"It Might be Good, But It Might Not Be Good Enough"

Graham Lee, on the failings of the iPad:

If the iPad is the Knowledge Navigator, it is not the Dynabook. A Dynabook is a computer that you can use to solve your problems on, but it’s also one on which you can create solutions to your own problems.

The promise of the Dynabook is that if you understand what your problem is, you can model that problem on the Dynabook. You model it with objects-either your own or ones supplied for you. You can change and create these objects until they model the problem you have, at which point you can use them to compute a solution.

Watch this video by Alan Kay on the Dynabook. The future hasn’t caught up with the past, yet.

Tuesday December 24, 2013

Since You Can Compile Anything to JavaScript...

Francis Chong released a CocoaPod that lets you run Ruby scripts in your iOS and OS X applications. Quite clever. Using Apples fast JavaScriptCore framework, and a Ruby to JavaScript compiler (written in JavaScript, of course) you have a simple Ruby runtime to embed in your Objective-C apps without going to all the trouble of linking in the real thing.

Yes, yes, you shouldn’t write a full Ruby application this way. Please, don’t. But, hey, we’ve already jumped the shark.

Monday December 23, 2013

Properties vs. ivars: Final Round

John Gallagher over at the Big Nerd Ranch Blog dishes out the last word on the properties vs. ivars battle:

Using properties has some very tangible benefits, particularly when it comes to debugging: they provide a single place to set a breakpoint on access or change, they can be overridden to add logging or other functionality, etc. Many of the answers that give some preference for ivars express concerns about the performance overhead of properties. We believe that the overhead is insignificant for most applications, but thought it would be fun to prove it.

It’s full of benchmarks and discusses how the ARM NEON Engine changes the future of this debate.

Saturday December 21, 2013

Running Quartz Composer Patch Files on iOS

Speaking of Quartz Composer, a while back Joriz Kluivers started building a Quartz Composer playback framework for iOS. It doesn’t have feature parity with the OS X version yet, but it’s a great place to go if you have the itch to try and get .qtz files to run on your iPhone.

Saturday December 21, 2013

Design UI Interaction With Facebook's Origami

The Facebook design team just released Origami, a marvelous set of additions to Apple’s hidden gem, Quartz Composer. Origami lets you prototype all sorts of user interactions and visual effects without writing a single line of code. It gives you a bunch of pre-made patches you can use in Quartz Composer’s flowchart interface to wire up slick demos. A great way to test out an idea on before building.

I’m a big fan of Quartz Composer. I hope this project breathes new life into the patch community.

Wednesday December 18, 2013

If Only We Had The Smalltalk IDE...

Graham Lee teased us with his yet-to-be-released ClassBrowser for Objective-C. It’s an implementation of the Smalltalk class browser complete with live REPL. Yes…a REPL that compiles Objective-C code and executes it within the browser app.

A real REPL. For Objective-C.


Thursday December 12, 2013

"But if it’s a year or two, you need to be making a different game."

Chris Kohler at Wired interviewed John Carmack for the 20 year aniversary of the seminal game, Doom.

I have fond memories hacking at on custom WAD files and learning about binary space partitioning. id Software defined so much about the game industry, not just in style and format, but in development practices, too. That’s why I found this quip at the end of the interview so interesting:

If I could go back in time and change one thing along the trajectory of id Software, it would be, do more things more often. And that was id’s mantra for so long: “It’ll be done when it’s done.” And I recant from that. I no longer think that is the appropriate way to build games. I mean, time matters, and as years go by—if it’s done when it’s done and you’re talking a month or two, fine. But if it’s a year or two, you need to be making a different game.

Wednesday December 11, 2013

Because Garbage Collection Is Still A Thing Elsewhere

Robert Nystrom wrote up a sharp walkthrough to build a simple mark and sweep garbage collector in C. I think it’s a great place to start wrapping your mind around the game of illusions we call memory management.

Why read this in the day and age of ARC, you ask? History is important, and the shallows of monoculture spoil the mind. Besides, you’d miss out on quips like this:

It was invented by John McCarthy, the man who invented Lisp and beards, so you implementing it now is like communing with one of the Elder Gods, but hopefully not in some Lovecraftian way that ends with you having your mind and retinas blasted clean.

(Via Aaron Brethorst)

Tuesday November 12, 2013

Computer History Museum Releases Apple II DOS Source

Oh, this is fun. The Computer History Museum got permission to publish the Apple II DOS Source code as part of their library to document the history of classic software. They have text files for part of it, but some of the code is provided as PDFs from scanned sheets of the green-white printer paper—complete with feeder holes. I loved tearing those things off.

This brings back so many memories of hacking the Apple IIgs as a teen. I learned how to do assembly and C programming by picking apart whatever I could find in a few dozen magazines at the local library, all while dreaming about the day when we could find all this information instantaneously in “cyberspace”. Good times.

Tuesday October 22, 2013

✦ MVC, MVVM, FRP, And Building Bridges

With the release of Ash Furrow’s new book on Functional Reactive Programming in iOS, I’ve seen a lot of debate about whether or not this whole paradigm shift is a good idea. Why do it? Isn’t what Apple provides with their specific flavor of Model-View-Controller sufficient? What the heck is Model-View-ViewModel?

OMG! The acronyms! It burns us!1

That’s what leads me to this post. I would like to build a bridge that stretches across the divide between the traditional way to build iOS applications and the strange new world with MVVM, Reactive Cocoa, RXCollections and the like.

You Are Not Stupid

First off, you are not stupid if you have trouble groking the README and documentation of Reactive Cocoa. It’s a very different paradigm than what grew up around Objective-C. It’s a clever abuse of the C preprocessor—a layer on top of Objective-C, which itself is a layer on top of C, etc.

All this extra syntax makes it hard to just jump in and read the code. It helps to know how and why the syntaxes grow into what they are today. After all, we’re quite forgiving when it comes to the block syntax Apple gave to us, right? Right?!?!

The hacked and layered nature of things like Reactive Cocoa have downsides, for sure. But I’m excited to see experiments giving us new primitives with which to compose our application logic. And it’s not just academic. Github is behind Reactive Cocoa and applies it to real world problems in their Mac and iOS applications.

You’re Already Closer To View-Models Than You Think

So, back to view-models.

Think about what a table view data source does in your application. It’s not your “model” layer in a classic MVC sense. Your models might be, say, NSManagedObjects as part of a Core Data store. These models have validation rules, transformed properties, and relationships that construct what the core of the application does.

A table view data source is none of these things. It’s purely a layer between the table view and the model. The model defines lists of things, but the table view data source transform those lists into sections and rows. It also returns the actual table view cells, but that’s not what I’m focusing on here. The key is its role as a middle-tier data transformer.

By default, because of Apple’s templates and documentation, we typically use table view controllers as the data source. There’s nothing wrong with that in itself, but it can lead to very large view controllers that both manage representations of screen state (navigation, transitions, and so forth) and feed data to the table views.

I’ve found great success creating separate NSObjects that implement the UITableViewDataSource protocol and dedicating those as data sources of table views. We end up with more focused objects, they’re simpler to test, and it leads us this realization…

We’ve just made a bunch of view-models!

Yes, the people who work with MVVM all the time will rightly criticize that statement. I’m overgeneralizing a bit, but bear with me. My point is that the table view data source is a “model” layer between the actual list of data and the table view that displays it.

I bring this up to show that the core of MVVM isn’t as foreign a concept on iOS as it seems. If you read Ash’s book, you’ll get a heavy dose of all the other things that MVVM brings with it, but you can at least get a head start in your understanding by thinking of the way the data source sits as a transforming layer between your model and your view.

Why Stop There?

Imagine this same mechanism generalized to other areas. Instead of bogging down your NSManagedObject subclasses with extra methods to display data in different formats, you build intermediate view-model objects that your views could consume and watch. If you update a primitive integer on your model, the view-model sees that change and updates the formatted NSString representation. And the view sees that change and updates the text label on the screen.

Next, imagine you had some sort of syntax to describe the bindings between the model, the view-model, and the view. If you’re still tracking with me then you’re ready to take a look at things like Reactive Cocoa. It’s a syntax built on top of Objective-C through which you bind subscribers to producers of events. It’s like KVO but with broader implications.

I hope this helps a bit if you’ve been curious about the Reactive Cocoa craze on iOS. I don’t think it’s above critique, but don’t write it off just because it isn’t the traditional way. We need more experiments like this that help us describe problems with primitive structures.

Count me in.

  1. You know, if we wanted to order the acronym based on the flow of data it would be Model-ViewModel-View…but that’s just cruel.

Thursday October 10, 2013

Just Because Some CEO Said So

Graham Lee bringing down the hammer:

Fundamentally I fear a world in which programmers think JavaScript is acceptable. Partly because JavaScript, but mostly because when a language is introduced and people avoid it for ages, then just because some CEO says all future websites must use it they start using it, that’s not healthy. Objective-C was introduced and people avoided it for ages, then just because some CEO said all future apps must use it they started using it.

Wednesday October 02, 2013

NSHipster, The Novel

You’ve read the site. Now buy the book.

Like resources like this? Support them.

Tuesday October 01, 2013

Mike Ash's Final Word On ARM64

If you liked the tidbit last week on why the isa pointer changed under 64-bit ARM, then you’ll love Mike Ash’s trademarked deep dive into precise tradeoffs faced all over the new 64-bit iOS world. Marvelous work. Must read.

Monday September 30, 2013

A Simulation Of Newton's Cradle With UIKit Dynamics

Sam Davies of ShinobiControls wrote up a nice tutorial of UIKit Dynamics, walking through how to recreate the iconic Newton’s Cradle with very little code. Between this and Sprite Kit’s physics engine, I’m quite impressed with these new APIs. But please, don’t overdo it when using this in your application. The last thing we need is an uproar declaring physics engines as the new skeuomorphism, right? Right?!?!

By the way, this is the first part of Sam’s daily series, iOS 7 Day-by-Day, and it looks like it’ll be a great resource to catch up on all the changes.

Tuesday September 24, 2013

Modifying The isa Pointer on 64-bit ARM, or, I Didn't Have Enough Headaches This Morning

Greg Parker of Sealie Software explains what Apple is up to with the extra bits of the object isa pointer:

If it’s not a pointer anymore, what is it?

Some of the bits still encode the pointer to the object’s class. But neither OS X nor iOS actually uses all 64 bits of virtual address space. The Objective-C runtime may use these extra bits to store per-object data like its retain count or whether it has been weakly referenced.

This reminds me of a conversation I had on Twitter with Graham Lee about what the “_” prefix on ivars means to an Objective-C developer. It doesn’t mean anything to me, other than Apple says we should do it—and so we should. Apple’s been telling us not to modify the isa pointer on objects directy for a long time. If you thought, “Surey, I’m able. This is just C!”, then you’re in for a world of pain on 64-bit ARM.

Apple’s style and usage guidelines may seem capricious, but they are often subtle hints about where the language and platforms are going1. I’m all for being clever, but a long lived iOS or OS X project have much less friction over time if it avoids mucking with unofficial parts of the Objective-C runtime.

I’m looking at you, JSON Kit. :/

  1. For another data point, consider Apple’s strong encouragement toward certain method naming conventions. At the time, they were just conventions. Now, these conventions (like starting a method with the name “new”) have actual runtime meaning to ARC!

Tuesday September 24, 2013

Full Text Searchable Transcript Of WWDC Sessions, Seriously

As if Mattt Thompson didn’t give us enough reason to feel like the rest of us mere mortals can’t ship anything, he’s outdone himself again and somehow published a transcript of all the WWDC 2013 Sessions to a fully searchable site.

This is perfect timing for me because I was just about to sit down and try to wade through the MultipeerConnectivity sessions.

Update: It turns out Apple provided an electronic form of transcript that Mattt consumed with a script. I knew he wasn’t a magical beast.

Monday September 16, 2013

That's All It Took To Weaken The Encryption

Paul Ducklin wrote up a fascinating story behind a vulnerability in the secure messaging app, Cryptocat. His summary:

And that, my friends, is why PRNGs [Pseudorandom Number Generators] are important, and why they should be tested thoroughly every time you build and ship the latest version of your software. A PRNG which passes the Chi-squared test may very well still be deeply flawed, but one that fails, and which produces such clear visual regularities, is definitely unfit for purpose. Random number generators, as the joke goes, are far too important to be left to chance.

The number generator had a bug that generated zeros at slightly higher frequency than other digits. That’s all it took to weaken the encryption.

Monday September 16, 2013

A Fingerprint Is Still Just A Single Factor

Excellent overview by Rich Mogull on the security of Apple’s new Touch ID on the iPhone 5s. Summary: More secure than a pass code, but still only as secure as any single factor authentication1.

  1. If you think that’s not a big deal, you might want to consider that your fingerprint may not be protected under the fifth amendment.

Friday September 13, 2013

Bwoken 2 - Command Line Workflow For UI Automation

The Bendyworks bunch just released the first beta of Bwoken 2, the slick command-line runner for UI Automation scripts. Boom.

Thursday September 05, 2013

How Dropbox Resolves Conflicts, Or Not

Guido van Rossum, now at Dropbox, is starting a series of posts that describe how the Dropbox data store syncs arbitrary tables of data across clients. Of note to me is how they resolve conflicts. In short, they don’t:

If you’re familiar with the theory of Operational Transformation (OT), you might be surprised that the server doesn’t even attempt to resolve conflicts. We use OT-style conflict resolution on the client, but leave the server to simply serialize requests. This allows conflict resolution to be defined by the client — your app — giving you more freedom than traditional approaches (which usually require that the rules for conflict resolution be fixed). As you will see next time, a Datastore API client may customize conflict resolution to fit its own requirements.

Quite reminiscent of git. You try to apply your batch of changes. If Dropbox says you are not up to date with other changes, it’s your job to replay your set of changes on top of the current state of truth. Then you try to apply your freshly rebased batch of changes back to the server again.

General purpose syncing is hard, hard, work. This series will be useful not just because it shows off Dropbox’s forethought, but because it shows how much engineering is necessary to solve the really useful problems we have today.

Wednesday September 04, 2013

First Time Users

Steven Wittens on the experiences of first time users:

You hear a lot about “first time user experience” for example. But it’s not about wrapping up your product like a present. It’s about creating a connection of trust through empowerment and a little bit of emotional appeal: “This is for you, you can do amazing things with this.” And that means “first-time” shouldn’t refer to the first time you turn on the device, but the first time you use a device for a particular purpose and context. Traveling to Another Country should definitely be treated as a “first time” experience, same with How Do I Work This Camera, I Don’t Have an App For This, I Don’t Have Data Right Now, I Dropped It Down The Stairs, I Should’ve Cached This Map But I Didn’t, My Friend Has a Windows Phone, etc. Throwing in more obnoxious tutorials is not the answer, creating affordance is.

Yes this article is a rant against specifics of Android, but don’t let that distract from useful and critical thinking about user interfaces in general.

Thursday August 22, 2013

What's With The Crazy Objective-C Block Syntax

Thanks to Nils Hayat, the mysteries of the Objective-C block syntax are laid bare before my eyes:

As convoluted as it may seem, blocks syntax in Objective-C is built upon standard C syntax. A block in Objective-C is nothing more than a pointer to a function that captures its scope. Once you understand that and practice writing and reading a few blocks declaration, you’ll find it much easier to apprehend.

He walks through the basic C declaration syntax and describes the history of the block declaration modifier, the beloved caret: ^. I finally understand why the name of the block has to go within the first set of parenthesis, as in int (^blockName)(int argument). I’ve used C for a long time but never had to think about the precedence rules for declarators. After reading through Nils’ excellent summary, I don’t think I’ll need to look up the syntax again.

(via @orta)

Wednesday August 21, 2013

UIAuto - Simpler CLI Interaction with UI Automation

Mike Enriquez read my book and decided to write up a RubyGem that makes it easier to use UI Automation from the command line. It’s a slick wrapper that uses sensible defaults to find your app bundle and know where to put trace results. But the best part is the way he lets you snapshot and reuse the state of the application as it exists in the simulator for your tests.

By running this command:

uiauto simulator save uiauto/simulator_data/with_tasks

…you end up saving a snapshot that you can call up to reset the simulator in the same state that you left it, giving you a consistent state to re-run your tests. Or you can trigger different snapshots with a magic comment at the top of your individual test files, similar to the way I use magic comments to set environment variables in the sample code with my book.

Wednesday August 21, 2013

Long Live the King

Here’s a great post by Ian Bogost chiding Facebook for neglecting developers and pretending to build a “platform” for them. It’s a great read as is, but as a thought experiment, I’d recommend substituting Apple for Facebook in the paragraphs like the following and see how you feel:

But there’s another aspect of rapid, reckless change that few discuss: it helps create a sense of confusion and desperation that forces developers to devote more and more attention to the Facebook Platform. What better way to increase collective commitment to Facebook apps than to quietly extort incremental time out of its creators, time that might otherwise be committed to competing products or—gasp—to their own businesses or personal lives?

Tuesday August 20, 2013

Feeding a Map View With NSFetchedResultsController

BJ Miller shares his insight feeding Core Data objects to a map view using an NSFetchedResultsController, just like you normally would with a table view. If you’ve been confused on how the fetched results controller works on it’s own then this is a good example to study.

Tuesday August 20, 2013

Ben Scheirman's iOS Developer Tools List Extravaganza!!!

If you’re new to iOS development then you’ll want to browse this long list of tools to help with all sorts of tasks, from asset optimization to Core Data store editors. Even if you’ve been around a while you’ll find something in this list you haven’t seen before.

Tuesday August 06, 2013

The Future of Programming

In relation to the last post filled with useful critique of both iOS and Android app development, you should stop what you’re doing right now and watch this talk by Bret Victor on the future of programming.

Bret is the genius known for his ground breaking talks such as Inventing on Principle and essays like Up and Down the Ladder of Abstraction. He knows his stuff and he’s appropriately pissed that we settle to reinvent the wheel in software development while patting ourselves on the back as if we’ve innovated. Bret’s talk is quite a clever nod to the innovators of the past.

The best part: He gives this talk with an overhead projector. With a straight face.

Tuesday August 06, 2013

On Comparing iOS and Android Development

Cameron Henneke wrote up an excellent comparison of the challenges to build native versions of his app, GQueues, on both iOS and Android. It’s a good case study by a solo developer. There’s no trolling here, just an honest critique.

More like this, please.

Monday August 05, 2013

Why Use CGRectMake and Friends?

Update: Apparently CGRectMake does not standardize coordinates like the other CGGeometry functions. Now I’m even more confused.

While browsing the freshly released Objective-C style guide from Matt Bischoff of the New York Times, I did a double take when I reached the part about the CGRect. Matt’s citation of Apple’s documentation on the CGGeometry functions surprised me:

The height and width stored in a CGRect data structure can be negative. For example, a rectangle with an origin of [0.0, 0.0] and a size of [10.0,10.0] is exactly equivalent to a rectangle with an origin of [10.0, 10.0] and a size of [-10.0,-10.0]. Your application can standardize a rectangle—that is, ensure that the height and width are stored as positive values—by calling the CGRectStandardize function. All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.

In summary, Apple recommends using the CGGeometry functions because they want to ensure all rectangles are “standardized” with the dimensions always expressed in positive values. It makes me wonder if there aren’t some special optimizations that happen under the hood if CGRects are guaranteed to be standard in this way1.

  1. For contrast, Github’s style guide intrigues me because they chose to prefer C99 struct initializer syntax, which obviously does not guarantee “standardized” CGRects.

Want more? Check out the article or linked archives.