MacKuba

This is the first part of a new (hopefully) longer series of tutorial-like posts. I’m planning to write shorter posts now but more often, based on specific things that I learn while working on my current projects. Let’s see how long I manage to keep this going… :)

Let’s say you have an iOS app that was build for iPhone 5S and earlier. Now that the new iPhones are out, you want to make it work on them too.

If you don’t change anything and just build your app with the latest Xcode and iOS SDK, you’ll see that the app runs on the new iPhones scaled up: the views are rendered on a standard iPhone 5S sized screen and then resized to a bigger resolution like you would resize a static image, together with the top/bottom bars and everything (which obviously doesn’t look good).

To make the app render on the new iPhones natively, you need to let iOS know that it supports them. There are two ways to do that:

⭐️ This post has been rewritten in December 2021 for Xcode 13 & macOS Monterey. (old version here)

Note (Oct 2023): The names of the buttons have been changed again in the SDK in macOS Sonoma - I will update this post once I have Sonoma on one of my Macs :)

When you’re building a native Mac app and you want it to feel like a part of the system, to have a UI that users who care about design will appreciate, it’s important to use the right kind of controls in the right places. Some features could be implemented visually in a lot of different ways, but only a few of them will “feel right”. This is even more important these days - with the influx of Electron apps that don’t even pretend they’re native, and not always well written Catalyst apps that often feel like something is missing there, an AppKit app written with care and attention to detail stands out from the crowd more than ever.

The macOS SDK has quite a lot of different controls available, and while this gives you a lot of built-in functionality for free, using them in the right way might be a bit more tricky than on iOS. This is especially true in case of the base button class, NSButton, which lets you choose from as many as 15 different styles, not counting the subclasses.

I originally wrote this post 7 years ago, shortly after OS X 10.10 Yosemite was released, changing the design significantly since the previous versions. The latest version of Xcode was 6.1, and if you were working on a Mac app interface and looked at the selection of available buttons there, you would see something like this:

I’ve read a post comparing Backbone to AngularJS recently, and another that ended with similar conclusions about Backbone, and since I’ve been working with Backbone for the last year or so, I thought it would be a good idea to share my own experiences with it.

In 2012 I’ve been working with a few other developers at Lunar Logic on a new webapp. We’ve decided from the beginning to build it as a single page application, based on an API that was being developed for an existing mobile app. We have considered EmberJS for a moment, but we’ve decided it probably wasn’t stable enough at that point, so we went with Backbone instead.

Looking back I think we made the right choice back then – EmberJS has changed a lot since then (some important parts were still being changed a couple of months ago in 1.0-pre versions), and they still haven’t released a final 1.0, though it seems it’s getting close to that. I’m also glad I had a chance to learn Backbone and get to see its pros and cons. Still, if I was starting the same project right now, I’d probably choose Ember instead.

So what have I learned about Backbone during this year?

Here are my notes from the Mobile Mobile Conf that took place in Kraków this week. I just wrote down what I heard, so it might not be completely correct, but I figured it will still be useful.

This post is mostly based on a presentation I’ve done on the last CocoaHeads meeting in Kraków. (If you’re a Cocoa developer and you’re in Kraków on a 2nd Thursday of a month, come say hi!)

Thea idea was basically to collect all the things that have changed in ObjC in the recent years in one place. There were quite a few of these (which is a great thing!) and it’s sometimes hard to remember all of them, especially if you’re trying to update the code of an older project to newer coding style. Hopefully you will also find something here that you didn’t know about before.

The beginning of 2013 was a really bad time for the Ruby community. In the first few weeks of the year a few separate security issues were found that made everyone run to their SSH consoles to update their Rails apps. Rails itself had to be updated 4 times so far because of this, and even the rubygems.org gem repository has been hacked.

And we aren’t talking about a minor “someone with enough luck and determination can use this for some malicious purpose one day” kind of issue; some of these were the nastiest security holes we’ve seen in years. Check out this article by Patrick McKenzie about what can happen (or rather: will happen) because of these vulnerabilities.

The worst part: it’s probably not the end. The general nature of these bugs – see another article by Aaron Paterson analyzing all the ways in which you can do harm to a Ruby app – means that it’s quite likely that there’s more where that came from.

Now, I don’t know about you, but for me it’s starting to get hard to keep track of all these issues. I know Rails should be updated, but which version was that, 3.2.10 or 3.2.11? Is 2.3.17 OK or was there something newer? And what else was there, json, rack, or was it rake?

If you’ve read the Rails 3.1 asset pipeline docs, you’re probably aware that you can add preprocessors to your asset files by appending extra file extensions. For example, to write your JS files in CoffeeScript you need to add the suffix .coffee, and if you also want to pass something from Rails to those files, like paths to image files, you also need to add the .erb suffix. All the extensions are added together, so you end up with e.g. profile.js.coffee.erb (it’s simpler with stylesheets, because by adding a Sass preprocessor you get a bunch of asset path helpers for free).

What the docs don’t tell you is that Sprockets can also be configured to include preprocessors implicitly based on a content type.

Last month I read a great book from the Pragmatic Bookshelf – “The Passionate Programmer”, another book in the not-directly-technical series of their books started with the original “Pragmatic Programmer”, which deal not as much with specific technologies and languages, but rather with programming and programmer’s life in general.

The book, written by Chad Fowler, a well-known Ruby expert, is a second edition of a book that was previously titled “My Job Went to India: 52 Ways To Save Your Job”. The first edition’s main idea was helping US developers find a new place for themselves in the globalized world where more and more projects are outsourced to some remote countries. The second edition is more of a redesign than an update, and instead of showing you how to be good enough not to be fired, its aim is to show you how to be awesome: how to become an expert in your field, a well-known, respected developer, and how to have fun on the way.

I’ve found a lot of great ideas and made tons of notes, but if I shared everything that would be definitely TLDR, so instead I’ll try to sum it up in a few points which were repeated in various forms throughout the book. (If some of these seem too obvious to you, I’m pretty sure you’ll find some other tips that will make more sense for you in the book.)