This is a talk I gave at SRUG (@SurreyRubyists) on Tuesday 6th May 2014, on how to get started building Mac OS X apps with RubyMotion fast. It includes a little bit of background on RubyMotion, some general points and information about RubyMotion dev, and a look at how iOS and OS X dev with RubyMotion compare. The last section of the presentation was me stepping through a simple OS X utility built in RubyMotion, demonstrating adding various features - you can follow along by clicking the link on each of those slides which will take you to the relevant GitHub commit. Any questions or feedback is welcome, tweet it to @ejdraper or @kickcode!

1. How to get started
building Mac OS X apps
with RubyMotion fast

2. A little about me
• My name is Elliott Draper
• 10 years of experience working on the web
• I’ve been using Ruby for 8 years
• I’ve been working for myself for 5 years
• I’ve been working with RubyMotion for 2 years

3. A little about me
• I run my own company, KickCode
• Mainly building apps for clients
• I also have a few apps of my own

4. except.io
error tracking and
notifications for Rails, and
now RubyMotion
!
https://except.io/

5. AlbumAlert
A simple iPhone app built
with RubyMotion to let you
know when new albums are
coming out from your
favourite artists
!
http://kickcode.com/case-
studies/album-alert/

6. WordTarget
A productivity application to
track word count across
applications, and to help you
work towards a daily writing
goal

7. Wonderment
An open-source example
application, using the
fantastic Marvel Comics API,
updating your desktop
wallpaper with comic book
covers, based on your
favourite character
selections!

8. I’m also writing a book
• Building Mac OS X applications
with RubyMotion
• Available for early access very
soon
• Will be finished in a couple of
months
• This probably won’t be the last
plug for the book

9. This talk is all
about RubyMotion

10. What is RubyMotion?
• It was released in May 2012, and was for iOS only to
begin with
• It was based on work already done on MacRuby, for
OS X
• It’s not a platform, or a framework, but a toolchain

11. What does this mean?
• It’s not a platform like iOS itself
• It’s not a framework like Ruby on Rails is for building
web apps
• It's a toolchain allowing you to use the Ruby
language to create apps that compile into native
executable applications for iOS (and now OS X)

12. But what does this mean?
• The resulting applications are the same as if they’d
been built with Objective-C in Xcode
• They are native apps, and they don’t have any
additional performance or security concerns as a
result of being built with RubyMotion

13. Cool… I guess?
• Your apps can interop nicely with the standard Cocoa
libraries, and the vast majority of user written
Objective-C code in Xcode projects
• Everything gets compiled together - so long as the
compile order is correct, code written in Ruby and
compiled by RubyMotion can access classes and
methods defined in Objective-C libs
• This includes CocoaPods, the Objective-C equivalent
of RubyGems

14. • OS X support was added midway through last year
• You can abstract away some code so that it works on
both platforms in certain cases
• This means being able to ship a library or gem that
can provide utility through Ruby code to both iOS
and OS X apps written in RubyMotion

15. Joybox
• One gem
• Works with both iOS and OS X
• Has specific platform related
features
• Core code works on both
• https://github.com/rubymotion/
joybox

16. motion-kit
• Just released, still has that brand new gem smell
• Looks like a much better way to layout your UI
• Designed to work with iOS and OS X
• https://github.com/rubymotion/motion-kit

17. Cocoa and Cocoa Touch
• Different standard libs
• On iOS, you have UI*
• On OS X, you have NS*
• Core concepts are very similar, but the platforms are
also very different

18. Similarities
• NSApplication.sharedApplication.delegate (OS X)
• UIApplication.sharedApplication.delegate (iOS)
• If you know how to do something on iOS, simply
changing UI for NS in the class names will quite often
point you in the right direction

19. Similarities
• The overarching delegate pattern used when
responding to events for objects and controls is
much the same on OS X
• objectDidDoSomething(object, withOption: option,
andAnother: another)

20. Differences
• Less restricted on OS X, even if you’re aiming to put
an app in the Mac App Store (which requires
sandboxing)
• A lot more to play with in terms of user interaction
and your app - status bar, global event handlers and
hot keys, dock etc

21. Differences
• Laying out a user interface can be done
programmatically in a similar way, and yet the x and y
position co-ordinates work entirely differently
• [0,0] is top left on iOS
• [0,0] is bottom left on OS X

22. Differences

23. Differences

24. Frameworks
• If it's not a framework, then is there a Rails-like
equivalent for building RubyMotion apps?
• For iOS there is ProMotion
• There are a lot of libs too to help with specific areas
of app building, such as models and data storage
• http://rubymotion-wrappers.com/ is incredibly useful

25. Landscape
• The landscape is similar to when Ruby on Rails first came
about, in as much as there were then a lot of plugins and
extensions for Ruby on Rails, and in the beginning there wasn't
always a clear front runner as to which was the best one to
use, but each one had benefits and drawbacks
• Often even when there was a “favourite” plugin or gem for a
common feature, it’d change a few weeks or months later
• The key as always with any OSS code is that when choosing
what to use in your app, look for code that is regularly
maintained, and where the project owner(s) are responsive to
issues

26. Landscape
• In some cases a library, gem or framework that is
regularly maintained, even if it doesn't yet do everything
you need, might be a better choice than something that
appears to have everything you need, but hasn't been
updated in years
• You'll almost certainly not build any apps of any real
complexity without requiring something on top of what
the lib offers, and a framework or library that is constantly
growing and maturing, not to mention accepting of
contributions, is a better bet for the future of your app

27. Stability
• RubyMotion is now very mature and stable
• It had some teething issues, but less than you might think for
something as complex as a toolchain for compiling Ruby into
native code for iOS devices
• Nowadays it's very stable, on iOS and OS X, and the pace of
development seems to have increased, making it a very well
maintained toolchain to use, with any issues that do crop up fixed
in short order
• The team behind it are also very active in fine tuning the toolchain,
and responding to critical issues in very quick hotfix releases

28. Community
• RubyMotion has a very active community, and again it has
the “early days of Rails” feel to it
• RubyMotion Dispatch newsletter for keeping up to date
with the latest happenings: http://
rubymotiondispatch.com/
• MotionMeetup online monthly meetups: http://
meetup.rubymotion.com/
• RubyMotion #inspect conference: http://
www.rubymotion.com/conference/2014/

29. A note on syntax
• When interacting with Cocoa/Cocoa Touch, and other
Objective-C written libs, you’ll find you’ll need to use
camelCase syntax for method names
• As Rubyists, we generally use snake_case
• You can continue to use snake_case for your Ruby
code, and camelCase for calling into Obj-C libs
• Or you can use camelCase across the board for
consistency

30. Usage
• So, what can we do with it?
• The bottom line is, anything we can do in Objective-C
- there are no limits
• But this talk is focusing on OS X, and specifically, how
we can delve into building an app quickly

31. Building Mac OS X
apps

32. Getting started
• I found the easiest way to get started was to start
with menu bar apps
• They require minimal UI
• They can provide very useful functionality or controls,
or expose some information or data to the user in a
prime spot
• They are quite straightforward to get started with!

33. osx-status-bar-app-template
• RubyMotion now supports templates, for spinning up
apps with similar structure and skeletons quickly
• My gem provides a barebones for a status bar app
!
• Voila, a status bar app!

34. Let’s make it more interesting
• We can configure what we show in the status bar itself, as
well as the menu shown underneath it
• We can hook it up to a system service, to show some stats
• Or hook it up to a web API to keep connected with a third
party
• Our menu can provide controls for doing different things
• Or we can even lose the menu, and show a custom window
pane underneath the status bar, for maximum customisability

35. motion-popup
• Used to provide custom window panes to show
under menus
• Now supports free floating custom windows too
• Can customise how it looks
• Looks nicer than a basic menu underneath the status
bar item

36. motion-popup

37. Project time
• A great way to get started building apps with
RubyMotion is to write a little utility
• Utility and productivity apps are generally a good fit
for status bar apps

38. NoteMeNot

39. Simple note tracking
• Let’s break down a simple RubyMotion app to track
notes
• Think of these as post-it notes, little tiny bits of info
you want to remember for a short period of time
• We’ll have a status bar item to show how many notes
you have currently, and to allow you to view them
• We’ll have a hotkey-enabled floating custom window
for note entry

40. Skeleton
• We’ll start with our app skeleton generated from
using the template gem for status bar apps
• http://kck.io/1f2w2u1L0V46

41. Incrementing note counter
• We’re going to add a menu item that simply
increments a counter, which updates the status item
in our status bar with the latest total
• http://kck.io/021j3a381v0T

42. Custom entry window
• We’re going to use the
motion-popup gem to
make building our popup
window a lot easier
• It should look like this, a
very basic, custom
floating window to enter a
note in
• http://kck.io/101w213n3e2s

43. Hotkey for hiding and
showing
• Next up, instead of the window just showing when
we run the app, let’s make it so we can hide and
show it with a global key combination
• http://kck.io/3v1W0D142G0k

44. Storing notes in memory
when entered
• When we hit return on our note editing window, we
want it to be automatically stashed in memory
• It should also update the note count in the status bar
• http://kck.io/3n1s1g0z1L3w

45. Listing notes in menu
• We should add the notes to the status bar drop down
menu
• When we click them, they should be removed
(reducing the note count in the status bar)
• http://kck.io/1O2T422n2A0V

46. Custom window pane for
status bar item
• Let’s switch to something more fancy, using a custom
popup pane below the status bar item
• It should list out the notes in a scrolling view
• http://kck.io/053x3J2d362t

47. Button besides each note
for removal
• Let’s add a nice button for removing the notes
• http://kck.io/031I3I3H300U

48. Editing notes
• And then when we click on the note, we should be
able to edit it using the same entry window as we use
to create the notes
• http://kck.io/0E0f3U2a0F1H

49. Showing context menu
• We don’t have any way to access the about or quit
menu options now though, so let’s add a new button
to access a context menu for those
• This keeps them accessible, but out of the way
• http://kck.io/3b0h2B3K2y0n

50. What happens when we
quit the app?
• All our notes are lost!
• Not very good for an app that is supposedly helping
us to remember things

51. Local storage, to a file
• For very simple data storage, you can write files to
the application support directory for your app
• This works even on sandboxed applications
delivered through the Mac App Store
• http://kck.io/1E211c2H2s0P

52. Other storage options
• Local storage, to a database
• Remote storage, using a file in iCloud (could then
allow syncing between devices)
• Remote storage, using an API, or a PaaS providing a
data storage API such as Parse

53. Let’s review
• We’ve built an OS X application
• It has a menu bar item, with a custom popup pane
• It uses hotkeys to hide and show a customised
floating window
• We’ve looked at how to implement multiple data
storage options

54. That’s enough of me…
• …for now
• That’s how to get started building Mac OS X apps,
but my forthcoming book goes beyond that…

55. Building Mac OS X apps
with RubyMotion
• Goes into depth on more advanced functionality
• Different types of app windows and UI elements
• Integrating with system services
• Logging and error tracking
• App submission and distribution options, sandboxing
your app for the Mac App Store

56. Building Mac OS X apps
with RubyMotion
• Early access will be out this month
• Will be about 1/3rd of the book or so
• Full thing should be finished July/August
• http://kickcode.com/building-mac-os-x-apps-with-
rubymotion/

57. Q & A
• Send questions or feedback to @ejdraper or
@kickcode!