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).

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.

Brad Grzesiak wrote up some of his findings while trying to unit test Swift code.

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.

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!

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.

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.

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 fly¹. 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.

Apple’s Secure Coding Guide. Linked non-ironically.

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 gate io.

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

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.

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.

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!

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.

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.

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. ;)

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.

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!

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.

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. ;)

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.

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.

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.

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.

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.

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.

OMG!!1!

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.

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)

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.

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.

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

Like resources like this? Support them.

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.

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.

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 going¹. 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. :/

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.

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.

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 authentication¹.

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

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.

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.

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)

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.

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?

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.

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.

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.

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.

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 way¹.