Today we are releasing the free Try Objective-C course to our Kickstarter backers and anyone else who wants to learn Objective-C, the language that powers iOS and Mac OS X apps.

When I first launched this Kickstarter project, I wasn’t sure what kind of response we would get. But after the first couple of days, it was clear that there were many, many people who wanted to learn how to build iOS apps. We were quickly met with a ton of requests for content for absolute beginners, people who had never coded before in their life but who desperately wanted to learn how to make iOS apps. I started work on an Objective-C Primer to give beginners a chance at learning the language before starting on iOS.

But Objective-C is a pretty complex beast of a language. And so we made it a “stretch” goal of the project to produce a full blown, free, Objective-C course.

I didn’t know what I’d gotten us into.

Being experienced programmers, sometimes it’s easy losing sight of how hard this stuff can be. We make too many assumptions and end up alienating a bunch of determined learners who feel like they aren’t being told the whole story. The problem is, the story is HUGE. Especially for a language like Objective-C. It’s an old language with a lot of power, but with that power comes a high level of complexity. Luckily, recent advances of the language (like auto-synthesized properties, object literals, and most of all ARC) have brought that complexity down to a level where it has become much easier to learn.

The rise of the popularity and use of the App Store has resulted in an interested phenomena: tons of people are entering programming for the first time by trying to learn an incredibly hard language and framework. We were reminded of this when we ran a private beta 4 weeks ago in our offices to help us with some feedback on the course and the content. We do private betas for all of our courses, and the beta for Try Objective-C had by far the most beginners of any beta we’ve had.

And unfortunately at that point our content was failing the true beginner. So we started over. We rewrote the entire course. The course we are releasing today gives the true beginner a really good shot at actually learning this language. It’s not perfect, and it’s definitely not easy, but it’s the most approachable course we could have written. And even though someone with experience in programming will most definitely start down the path of learning Objective-C and iOS with this course, it was written with someone else in mind. It was written for my brother the T-shirt printer, for my fiancée the scientist, for my friend who is a single mom, for my neighbor with all the crazy app ideas, for my dentist, for my friends, and for all the people who messaged me on Kickstarter, wanting desperately to learn a new skill, to make something meaningful, to feel like they too could become a programmer.

Ruby 1.9.3 has a handy standard library called SecureRandom that you can use to generate random base64 and hex encoded strings of varying length.

1
2

p SecureRandom.base64 #=> "BSosm7R3qpzxb+julERofA=="
p SecureRandom.hex #=> "0748834731ab0c35efd44610161f0ee3"

If you are already using Ruby, and you need to generate random strings, go ahead and use SecureRandom. But what if you aren’t using Ruby? Well you don’t have to go searching for a similar library in your language, because SecureRandom is built on top of OpenSSL, and if you have Mac OS X or linux, chances are you already have access to the openssl command line tool.

1
2
3
4

$ openssl rand -base64 16
t1nkx6lFae7s7dyGDuzgiw==
$ openssl rand -hex 16
809420e83e80ebae689e814b1861bf5c

This way you can quickly generate secure random strings without worrying about running Ruby.

Square released a pretty neat Integration Testing library called KIF last year and we have been using it to test the challenges for our upcoming Try iOS course on Code School. The instructions in the KIF README on setting up an Xcode 4 project are missing a couple of crucial steps, and after much Googling and Stackoverflowing I finally figured out how to get it to work, so I figured I’d share the process we are using for setting up KIF projects.

I’m assuming you already have an Xcode 4 (version 4.5.1) project that you want to add KIF to. First, if you aren’t already working with an Xcode workspace, you will need to create one for this project. To do so, choose the “Save as Workspace” menu item:

You need a workspace so you can manage both your original project (in my example InstagramClone), and the KIF project we are about to add the the workspace. For more on workspaces check out this Apple doc.

Next, you’ll want to download the KIF project from their downloads page, and copy the files inside of a “Frameworks” directory under the Project Root.

Next, go back to Xcode and command-click on empty area in the Project Navigator (⌘1), and choose “Add Files to Project”:

Navigate and select the “KIF.xcodeproj” file under Project Root->Frameworks->KIF. Now the Project Navigator should look like you have two projects on equal footing:

This is important, at this point it should not look like the “KIF” project is under the “InstagramClone” project.

Next, select your project in the Project Navigator and you should see information about Projects and Targetings in the main content area. Command-click on your app target and choose “Duplicate”:

Then choose “Duplicate Only”:

You should see a new target named “PROJECTNAME Copy”. Select the target, press Enter, and change the name to something like “Integration Tests”:

With the “Integration Tests” target selected, go to the “Build Phases” panel, expand the “Link Binary With Libraries” section, and click the little “+” button. Select the “libKif.a” binary from the list and add it:

Still with the “Integration Tests” target selected, go to the “Build Settings” panel. Make sure you have “All” and “Combined” selected:

Search for the “Header Search Paths” and edit the setting to add $(inherited) and $(SRCROOT)/Frameworks/KIF, like so:

Search for the “Other Linker Flags” setting and edit to add these flags:

Next, add the RUN_KIF_TESTS=1 Preprocessor Macro to both the “Release” and “Debug” targets, like so:

Now that we’ve configured the “Integration Tests” target correctly, we need to make sure that before Xcode builds the target, it also builds the KIF project. To do this we need to do a couple of things (this is what you won’t find in the instructions provided by Square).

First, we need to edit the “PROJECTNAME Copy” Xcode Scheme to tell it to build KIF. To do that, go to “Edit Schemes” and select the “PROJECTNAME Copy” scheme. Choose the “Build” phase. You should see something like this:

Click on the little “+” button right above the “Manage Schemes” button, and Add the “KIF” target:

Close the “Edit Schemes” dialog and go back to the Project Navigator. Click and Drag the “KIF” project to under your App project. In the dialog that appears, select both your app target and the “Integration” Tests target in the “Add to targets” section:

After clicking “Finish” your Project Navigator should look like this:

.

Now you should be able to follow the rest of Square’s instructions for adding the Controller, Scenario, and Step files to test your app in the “Example” section of their README

Flash, the once poster-child of the mobile cross-platform cabal, is finally dead on android. A little over 2 years ago Steve Jobs wrote down his Thoughts on Flash, a reasonable attempt to explain to the programming world why the iPhone and iPad did not ship with Flash. And looking back, he was right: Flash wasn’t ready. It never become “ready”, even 2 years later.

Jobs wrote down six reasons why iOS didn’t have Flash, and much ink was spilled by tech writers at the time over the first five. Whether or not Flash interfaces worked with touch screens, the use of Flash for video, whether Flash drained battery, security, performance, the “openness” of Flash, etc.

But the sixth reason, by Jobs’s own admission, is the most important one. Apple didn’t want developers on their platform to use Flash to build apps. Here, in his own words:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

This still holds true today. Whether you use PhoneGap, AppCelerator, or even RubyMotion, you are relying on a third party to supply you with the developer tools for a platform they don’t control. In RubyMotion’s case, you can take some comfort that they only support iOS and thus won’t fall into cross-platform least-common-denominator purgatory. But you can still find yourself in the situation where RubyMotion, or whatever framework you use on top of RubyMotion, falls behind the APIs developed by Apple.

But the tug of the iOS platform is strong, and it’s tempting to take the PhoneGap or AppCelerator shortcut, and just write your App in HTML+CSS+Javascript. Don’t. Take some time learn how to write iOS applications using Objective-C.

It’s not as hard as you think. Don’t let your overzealous pattern-matching reflex blind you to the fact that just because smartphones are computers, people will be okay with sub-standard, cross-platform web apps. They are slow and don’t take advantage of the richness of the phone’s capabilities and speed. You sit down at your computer, so a few hundred milliseconds here and there are no big deal. People expect more out of the computer that goes everywhere with them (even to bed). It needs to be an extension of themselves. A couple hundred milliseconds of lag is not acceptable on a smartphone. Facebook found that out the hard way:

So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.

This is why I want to create awesome iOS development learning resources so there will be no excuse left not to create native applications for iOS.

I’ve wanted to do a Kickstarter project ever since I backed my friend Doug’s first attempt at funding the rest of his movie (a deserving project if there was ever one). Today, because I work with the best team, and because we are lucky enough to work on something people love, I was able to launch a Kickstarter project to build a Code School course to help people learn iPhone Development.

In the recently released 1995 “Lost Interview” with Steve Jobs, Robert (X?) Cringely asks Steve what kind of things people were using his Apple II’s for. His answer:

Much more importantly, it had nothing to do with using them for anything practical, it had to do with using them to be a mirror of your thought process, to actually learn how to think. I think the greatest value in learning how to, I think that everybody in this country should learn how to program a computer, should learn a computer language. Because it teaches you how to think…I view computer science as a liberal art.

We’re not there yet Steve, but we’re close.