Redwood is a super-fast search bar for your cloud data. The search bar for the public web is Google: whether it’s a restaurant address, the weather forecast, or the current time in Buenos Aires, Google is our first stop. But what about your growing library of cloud data that’s beyond Google reach?

If you want to search across your cloud data, you need to keep a browser tab open for each web application (ex: Gmail, Google Docs, Basecamp, Pivotal Tracker, etc). Who wants to keep four or more browser tabs open just for quick access searching?

Redwood takes cloud search out of the prehistoric age: it’s a single search bar for your entire cloud. It sits on your Mac desktop, just like Spotlight.

Redwood is lightweight, fast, and always within easy reach because it’s a desktop app, not a web page. You can view your cloud data right from Redwood – just click on a search result:

Redwood currently supports Gmail, Google Docs, Basecamp, and Pivotal Tracker.

Key Features

• Always in sync. Redwood conducts live, parallel searches across your cloud services. So, there are no resource-heavy processes to keep gigabytes of data in sync. What you see in Redwood is what you see online.
• Secure & Private. Redwood operates from the privacy of your own computer. There is no intermediary service. Usernames, passwords, and content are never transmitted to us or anyone else.
• Faster as you use it. Any search result you view in Redwood is cached locally. From then on, the result shows up “as-you-type” – giving you even quicker access to those items you return to often.

Free 30-Day Trial, purchase for $14

You can download a full-featured trial from the Redwood website and purchase it with a one-time payment of $14. Unlike the cloud, there are no subscription fees! Note that Redwood requires OSX 10.6 or greater.

The future: search anything from your desktop

Searching your cloud data shouldn’t be painful. It should be like using Google. We’ll soon be adding a plugin system so you can easily extend Redwood to search your own internal web apps right from the desktop. If you have a cloud service suggestion or wish to develop a search plugin, ping us.

Initially, we developed Redwood for our own needs. We can’t imagine life without this search bar. We think you’ll feel the same: download it today.

We were writing Objective-C when we started building Redwood. When we released Redwood this week, almost all of our code was written in Ruby. There were there areas that prompted this shift:

1. Verbosity

Before Redwood, Andre and I hadn't written a line of Objective-C. While we've spent the last five years coding in Ruby and were aware of MacRuby, we decided to start writing Redwood exclusively in Objective-C. We wanted to build a decent Objective-C knowledge foundation.

The more Redwood matured in pure Objective-C, the more we missed Ruby. Working in a different language highlighted how many lines of code just manipulate primitives (Strings, Arrays, Hashes, Integers, etc) and how Ruby makes operations on these primates so concise. It wasn't that Objective-C code wasn't readable (Obj-C has extremely descriptive method signatures). It took significantly more work to write and read Objective-C because of these lengthly method signatures. Knowing how effortless Ruby code is to write and read made the experience painful.

For example, let's say you want to strip new lines from an NSString, the Ruby String Objective-C equivalent. It looks like this:

In Ruby?

It's not just lines of code. Ruby is the Twitter of programming languages, capable of expressing its purpose with little dialogue. Take appending strings in Objective-C:

In Ruby:

While stringByAppendingString is descriptive, even a non-programmer would have a pretty good idea what a + symbol between two strings does. Additionally, there are six NSString methods that begin with stringByAppending…. When scanning code, this forces you to read the entire method name to understand the operation.

When working with primitives, we prefer Ruby.

2. Don't Repeat Yourself - DRY

When creating an Objective-C class, you'll have a header file and an implementation file for each class (example: User.h and User.m). The implementation file (User.m) contains the implementations of the methods defined in the header file (User.h). This means every time you modify a method signature or add a property to a class, you need to make a number of changes across two different files.

For example, lets say we have a Lion class:

We want to add an age property. To do that, we'll need to add the instance variable and declare its associated getter and setter methods in the header file. Then in the implementation file, we'll need to implement these methods:

While you are making these updates, you'll see a number of XCode warnings displayed:

These warnings are like a nagging mother telling you to put your dishes in the dishwasher as you're walking to the dishwasher.

How do you add an instance variable and its associated reader and writer methods in Ruby?

3. Prototyping

Based on data from one year ago, there are 13 times more GitHub Ruby repositories than Objective-C repositories. That's a lot of free code at your disposal. Additionally, we had decent success using Ruby gems in Redwood: this includes Nokogiri, GData, and Gibberish.

It was great having the large number of Ruby libraries at our disposal - we could focus on the end result rather than the plumbing.

So, why just prototyping? Currently, you can't precompile Ruby gems in a MacRuby application. This can have a dramatic impact on the application launch time. If you're working on an internal application or just getting started, this might not be a big deal. However, if you're like us and building an application that you want people to pay for, the initial experience is really important. A slow-launching application gives a bad impression.

Summary

MacRuby isn't a framework: it's not the lightning-in-a-bottle productivity enhancer than Rails was to web development. It doesn't abstract away the confusing bits of OSX application development. What MacRuby does is make building an OSX application far more enjoyable. Instead of building an OSX app because you need it, you're going to be more likely to build an OSX app because you enjoy it. That's a productivity enhancer that proved itself over the long-haul when creating Redwood.

While MacRuby isn't available as a public framework on Snow Leopard, there's nothing that prevents you from embedding the framework in your application and publishing it on the Mac App Store. Below are three examples of MacRuby apps available on the App Store:

Timey

Simple timer to help time box and maximize productivity.

Timey On the App Store

Zero2Nine

Learning the numbers from zero to nine has never been more fun! Entertain and educate young children with this colorful counting game.

Zero2Nine On the App Store

QuickAlarm

QuickAlarm provides a quick and easy way of setting alarms on your Macintosh.

QuickAlarm On the App Store

How do you embed MacRuby in an app?

See our blog post: MacRuby & Xcode 4: Build a Self-Contained MacRuby Application

What about iOS?

You can't use MacRuby in a iOS app. Laurent Sansonetti of Apple tweeted that work has started on MacRuby for iOS, but no promises yet.

It's exciting times for MacRuby developers. MacRuby 0.10 was recently released, and Xcode 4 is finally out. And while Apple has announced that MacRuby will be included in Lion, it will be a private framework, not a public one. For now, you need to include the MacRuby framework inside your application bundle. This post shows you how.

1. Create a new project in Xcode 4, and select the MacRuby template

2. Name your application, and select an app store category

After this, you'll save your project, and you'll get the Xcode 4 main window.

3. Two things you need to change to package your application

While you can build and run your application now, you can't package it for archiving/distribution. You need to make two changes first:

A) Change the Valid Architectures to X84_64 only:

If you don't make this change, you get this error when archiving: 

ld: warning: ignoring file /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks//MacRuby.framework/MacRuby, file was built for unsupported file format which is not the architecture being linked (i386)

B) Add a build target to the Deployment scheme:

Add the default target to build before the Deployment target. When done, It should look like this:

if you don't make this change, you get this error when archiving:

Path does not exist `/Users/andre/Library/Developer/Xcode/DerivedData/Alpha-duvzaijhkvprmzdhkzkydcudwljf/ArchiveIntermediates/Deployment/BuildProductsPath/Release/Alpha.app'

4. Select Product => Archive to build for distribution

Xcode's organizer will pop up when the build is done (or select Window => Organizer). If you just want the .app file, click Share, then select Application:

Save the .app file wherever you like. It should be about 28MB. Yes, it's large because it includes the MacRuby framework. Adding additional code to your application won't increase the bundle size much -- it's all overhead from the MacRuby framework. You can expect your application to zip to around 10MB -- a reasonable size for distribution.

You now have a self-contained MacRuby desktop application. What about gems?

One thing we didn't cover here: using Ruby gems in your MacRuby application, and bundling the gems with your application for distribution. I'll cover gems in an upcoming post.

Further reading

• The Xcode chapter in Matt Aimonetti's online MacRuby book
• Apple's What's new in Xcode 4
• MacRuby 0.10 Released: XCode 4 Support and App Store Submissions

1. MacRuby in Lion: Apple is including MacRuby as a private framework in Lion. While MacRuby is not yet a public framework, its inclusion is a powerful signal of Apple's endorsement.
2. Framework embedding. Distributing the MacRuby framework as part of your .app bundle is getting more efficient: Our application is 10.9MB GZIP'd, including the embedded MacRuby framework and several Ruby gems. That's a big improvement form 18MB+ in previous versions of MacRuby.
3. Distribution of commercial apps: you can compile your MacRuby code prior to distribution -- no need to reveal your source code. If you're developing a commercial product, this is a pretty key feature.
4. Xcode 4: Xcode 4 works with MacRuby! Xcode 4 is a joy compared to Xcode 3.
5. Community: developing in MacRuby reminds me of developing in Rails in the early days. People are beginning to see how productive it can be. There's a small but passionate group of advocates. There's a great energy and vibe in the community.
6. Timing: there are many talented Ruby programmers who are going to discover and embrace MacRuby on the desktop soon. As momentum builds, there will an influx of great Mac apps from these folks. I think this will be another wave that is -- like Rails -- both profitable and fun to be a part of.
7. Ruby Gem compatibility: Ruby has an amazing ecosystem of gems, and you get it for free with MacRuby. Compatibility is growing all the time. We've used Nokogiri, SQLite, and more.

Curious what we're building with MacRuby? Redwood is "Spotlight for your web apps." Feedback & bug reports welcome! Download here (free).