Ada Lovelace

Posted in Inside TFG

Today Oct 14th is Ada Lovelace Day.

440px-Ada_Lovelace_portrait

Ada Lovelace, an English mathematician born in 1815 is often described as the world’s first computer programmer. Through her accomplishments in a male dominated era, Ada has become a powerful symbol for women and their success in the modern world of STEM fields. This day is a celebration of challenging mindsets that may be resistant to the idea of equal opportunity and capability.

Matt Lambie (co-founder of TFG) raised our awareness of Ada Lovelace Day and mentioned had his son actually been a girl, Ada was a name he was keen on specifically because of Ada Lovelace. Through discussion he also pointed me further to a talk by Ashe Dryden discussing Programming Diversity. This talk touched on many aspects of diversity including women and their role in STEM fields. A point raised by Ashe that resonates with Matt and I is that diversity can have a positive impact on the workplace in numerous ways. For us a diversity in cultural backgrounds, skills, interests and genders makes for a great team dynamic and a powerful problem solving crew. More importantly we have found diversity as a side effect of our search for skilled designers and developers.

Through Ashe’s talk I have been exposed to a more complicated world and one with some concerning numbers. As the father of a young girl and boy I hope that as they reach education and employment, they are driven purely by their interests and abilities, not social pressures.

A look at Cayley

Posted in Code, Inside TFG

Recently I took the time to check out Cayley, a graph database written in Go that’s been getting some good attention.

Cayley Logo

https://github.com/google/cayley

From the Github:

Cayley is an open-source graph inspired by the graph database behind Freebase and Google’s Knowledge Graph.

Also to get the project owners disclaimer out of the way:

Not a Google project, but created and maintained by a Googler, with permission from and assignment to Google, under the Apache License, version 2.0.

As a personal disclaimer, I’m not a trained mathematician and my interest comes from a love of exploring data. Feel free to correct me if something should be better said.

I’ve seen Neo4j.. I know GraphDB’s

Many people exploring graph databases start with Neo4j and conceptually it’s similar but in usage terms there is a bit of a gap.

Neo4j has the Cyper query language which I find very expressive but also more like SQL in how it works. Cayley uses a Gremlin inspired query language wrapped in JavaScript. The more you use it the more it feels like writing code based interactions with chained method calls. The docs for this interface take some rereading and it was only through some experimentation that I started to see how it all worked. They can be accessed via the Github docs folder. I worked my way through the test cases for some further ideas.

Another major difference is that in Neo4j it’s a bit of a gentler transition from relational databases.  With Neo4j you can group properties on nodes and edges so that as you pull back nodes it feels a little more like hitting a row in a table. Cayley, however, is a triple / quad store based system so everything is treated as a node or vertex. You store only single pieces of related data (only strings in fact) and a collection of properties that would traditionally make up a row or object is built through relationships. This feels extreme at first as to get one row like object you need multiple traversals but over time for me it changed how I looked at data.

unnamed0_-_yEd

As an example (ignoring the major power of graph databases for starters) we might have the question “What is user 123’s height”. In Neo4j we can find a person with id 123, pulling back a node with that person’s name and height. We can then extract the height value. In Cayley you could find the persons id node and then move via the height relationship to the value 184. So in the first case we are plucking property data from a returned node. In the second we collect the information we want to return. This is more a conceptual difference than a pro or a con but it becomes a very clear difference when you start to import data via quad files.

What is an  n-quad?

As mentioned Cayley works on quads / triples which are a simple line of content describing a start, relationship and finish. This can be imagined as two nodes joined by an edge line. What those nodes and relationships are can be many things. Some people have schemas or conventions for how things are named. Some people are using URLs to link web based data. There is a standard that can be read about at www.w3.org:

http://www.w3.org/TR/n-quads/

A simple example might be from the above:

"/user/123" "named" "john" .
"/user/124" "named" "kelly" .
"/user/124" "follows" "/user/123" .

When is a database many databases?

One of the tricky parts of a graph database is how to store things. Many of the graph dbs out there don’t actually store the data but rather sit on an existing database infrastructure and work with information in memory. Cayley is no different as you can layer it upon a few different database types – LevelDB, Bolt, MongoDB and an in memory version.

An interesting part of this is the vague promise of scaling. Most graph databases start off the conversation with node traversal, performance, syntax but they almost all end in scaling. I think Cayley is now entering this territory. As it moves from a proof of concept to something that gets used more heavily, it’s acquiring backends that can scale and the concept of layering more than one Cayley instance in front of that storage layer.

One think to keep in mind is performance is a combination of how the information stored and accessed so put a fast graph db in front of a slow database and you’ll average out a little in speed. For my testing I used a built in leveldb store as it is built in and easy to get started with.

Show me the graph!

One of the first issues I had with Cayley was not 100% knowing how to get graph to page. Neo4j spin up was a little clearer and error handling is quite visual. Cayley you have to get syntax and capitalisation just right for things to play nicely.

Lets assume you have the following graph:

graphy

Node A is connected out to B,C and D. This can be described in a n-quads file as:

"a" "follows" "b" .
"a" "follows" "c" .
"a" "follows" "d" .

If we bring up the web view using a file with that content we can query:

g.V('a').As('source').Out('follows').As('target').All()

Running it as a query should give you some json:

{
  "result": [
    {
      "id": "b",
      "source": "a",
      "target": "b"
    },
    {
      "id": "c",
      "source": "a",
      "target": "c"
    },
    {
      "id": "d",
      "source": "a",
      "target": "d"
    }
  ]
}

Swap to the graph view, run it again and you should see a graph. Not all that pretty but it’s a start.

Cayley

So what’s happening here? Starting at ‘A’ and calling it “source” we traverse joins named “follows” that go out from A and take note of the end node calling it “target”. Be aware that the source / target is case sensitive and if you get it wrong you won’t see anything. When I say “calling” what I mean is that as the nodes are being traversed it will “emit” the value found with the name provided as the key. This is building up the JSON objects with each traversal as a new object in the returned list.

Doing more

So now we have the basics and that’s as far as a lot of the examples go. Taking things a little further.

I recently read an article 56 Experts reveal 3 beloved front-end development tools and in doing so I came across entry after entry of tools and experts. My first reflex was where are the intersections and which are the outliers.  So I decided to use this as a datasource. I pulled each entry into a spread sheet and then ran a little script over it to produce the quads file with:

"<person>" "website" "<url>" .
"<person>" "uses" "<tool name>" .

and for each first mention of a tool:

"<tool>" "website" "<url>" .

The results was a 272 line quads file with people, the software they used and the urls for the software.

From there I started Cayley with the usual command:

cayley http --dbpath=userreviews.nq

So what next? We can find a product and see who is using it:

g.Emit(g.V('sublime text').In('uses').ToArray())

Which results in:

{
 "result": [
  [
   "stevan Živadinovic",
   "bradley neuberg",
   "sindre sorus",
   "matthew lein",
   "jeff geerling",
   "nathan smith",
   "adham dannaway",
   "cody lindley",
   "josh emerson",
   "remy sharp",
   "daniel howells",
   "wes bos",
   "christian heilmann",
   "rey bango",
   "joe casabona",
   "jenna gengler",
   "ryan olson",
   "rachel nabors",
   "rembrand le compte"
  ]
 ]
}

Note I used the specific emit of the array values to avoid a lengthy hash output.

Sure that’s interesting but how about we build a recommendation engine?

Say you are a user that is a fan of SASS and Sublime Text. What are some other tools experts using these tools like?

// paths that lead to users of the tools
var a = g.V('sass').In('uses')
var b = g.V('sublime text').In('uses')

// Who uses both tools
var c = a.Intersect(b).ToArray()

// What tools are used by all of those people
var software = g.V.apply(this, c).Out('uses').ToArray()

// Convert an array to a hash with counts
var results = {}
_.each(software, function(s){
  if(results[s]==null){ results[s]=0; }
  results[s] +=1;
})

// Remove search terms
delete results['sass']
delete results['sublime text']

// Emit results
g.Emit({tools: results, users: c})

Here we are:

  1. finding the people that use sass and sublime text
  2. finding all the tools they use
  3. counting the number of times a tool appears
  4. removing our search tools
  5. emitting the results as the response

This gives us:

{
 "result": [
  {
   "tools": {
    "angularjs": 1,
    "chrome dev tools": 5,
    "jekyll": 1,
    "jquery": 1
   },
   "users": [
    "bradley neuberg",
    "nathan smith",
    "adham dannaway",
    "wes bos",
    "joe casabona",
    "jenna gengler",
    "ryan olson",
    "rachel nabors"
   ]
  }
 ]
}

Note how Cayley is pretty happy for us to move in and out of JavaScript and that underscore.js is available by default. Handy. Also I returned a custom result construction with both the results hash and the users it was derived from.

So this isn’t necessarily the most efficient way of doing things but it’s pretty easy to follow.

I think for many, the fact that Cayley uses a JavaScript based environment will make it quite accessible compared to the other platforms. I hope to keep exploring Cayley in future articles.

The Smith Family Children’s Charity

Posted in Inside TFG

Here at The Frontier Group we are a growing family. A few of us have young children and that number is increasing (congratulations to Steve and Elissa!).

Unfortunately, not all families are in a good position to give their little ones a happy Christmas. So, this year we plan to help The Smith Family charity help with that via their Toy and Book appeal. We felt we should also put the offer out there to our friends and customers to join in.

Until the 29th of November 2014, we will be putting together a collection and we’d love for everyone to join in by dropping your gift off to our office – Level 4, 580 Hay St, Perth. Please observe their guidelines at the end of this post as we want to make sure your gift is something that they can hand on to those in need. If you can’t make it to our office they do have a great online system as well.

We all know that Christmas isn’t just about presents but in hard times it can be a wonderfully positive family experience to treat your kids and see a smile on their faces.

Special thanks to Paula for organising this and creating our wonderful space cat picture.

http://www.thesmithfamily.com.au/get-involved/give-toys-or-books

blog-image01

The Following are the guidelines provided by the charity.

Donations

Currently we accept new toys and books for 0 – 12 year olds. Additionally, this year, we encourage you to donate learning and educational related items.

• All gifts received must not be wrapped
• All toys should be no bigger than a school backpack
• Please ensure batteries are included if they are required to operate the toy

Donations most needed

Currently there is a significant shortage of gifts for children 9 – 12 years of age. Your donation to these age categories it would be greatly appreciated.

Items not accepted

The following cannot be accepted:

• Large items i.e. bikes, hula-hoops, adult cricket bats, large doll houses, ride ons
• Second hand or handmade toys
• Clothes and Manchester including costumes
• Toiletries – perfume, make-up, nail polish
• Toys that replicate weapons i.e. guns, knives
• Religious items i.e. books, figurines
• Calendars & diaries
• Candles and lamps
• Adult games or videos
• Items used for marketing a brand or company i.e. fast food items/toys
• Breakable items i.e. porcelain dolls and tea sets
• Items that contain liquid
• Food
• CD’s and video games

Recommendations

Please find below a guide to appropriate toys and books for each age group. Please ensure you check the age suitability on the packaging before purchasing. Remember we have a significant shortage in the 9-12 age categories.

0 – 1
Push and pull toys
Musical instruments
Soft material bath books
Building blocks

2 – 3
Play sets
Dolls with no small attachments
Plastic tea sets (no porcelain)
Plastic golf sets
Toy trucks
Golden books

4 – 5
Baby dolls
Matchbox cars
Plastic kitchen sets
Picture books with few words
Barbie doll or My Little Pony sets
Figurines
Easy jigsaw puzzles
Activity and colouring books
Young reader books

6 – 8
Art, craft and bead sets
Colored pencils and crayons
Jigsaw puzzles
Board games
Remote control cars
Lego
Action Figurines
Kite, Frisbee and Yo yo’s
Sporting goods

9-10 / 11-12
Art and craft sets
Educational games
Sports balls
Science kits
Jigsaw puzzles
Board games
Stationary packs
Meccano kits
Beach sporting goods
Children’s novels
Remote control cars
Electronic hand-held games

Remember: Fun, versatile, activity based, long lasting, educational or active.

Should my company choose RubyMotion or Swift?

Posted in Inside TFG, iOS, RubyMotion, Swift

One of the most highly debated topics at The Frontier Group over the last two years has been whether to use RubyMotion or Objective C for iOS development.

There were a tremendous amount of reasons for and against both RubyMotion and Objective C. In the end we settled on RubyMotion, reasoning that we could learn Cocoa Touch and iOS faster using Ruby than Objective-C. In hindsight, I think it was the correct decision. If you are a Ruby on Rails developer looking to make the jump to iOS, RubyMotion is a great place to start, even if you want to move to Swift later.

When Swift was announced I was intrigued. To me, Swift looked like Ruby and C# had a beautiful strongly-typed baby. Swift’s improved syntax was the push I needed to vote in favour of moving from RubyMotion.

At this point the great debate came to an end. After two awesome years with RubyMotion, The Frontier Group decided to become a Swift shop. I will outline the main factors we considered in this post. Hopefully they can assist you in your decision making process.

A note about RubyMotion

RubyMotion is production ready and extremely enjoyable to use in development of iOS applications.

I want to make something abundantly clear. RubyMotion is awesome. I have launched many apps using RubyMotion. Despite what you may have read RubyMotion is 100% production ready. You can integrate RubyMotion with Interface Builder, CoreData, and every Cocoa Touch SDK easily. RubyMotion is not some hacky workaround, it is a native solution. Apps made in RubyMotion are just as fast and responsive as their Objective-C and Swift counterparts. 

In RubyMotion I’ve successfully used many frameworks in Cocoa Touch. From custom drawing and animation, to Facebook, Twitter, maps, location services, music players, the camera and more. There is the occasional bug, but I’m yet to find one that can’t be worked around trivially.

RubyMotion has improvements and updates released every couple of months. A majority of the updates include impressive improvements to the speed of compile time and commonly used functions. I believe the latest update (2.32) reduced compile time by 40%. 

One thing you should understand – making good iOS apps is more about understanding how the user will interact with the app than it is writing code. It doesn’t matter whether you use RubyMotion or Swift if you can’t provide a good user experience.

The majority of the coding of an iOS app (I’d say 90%) is about understanding how the SDK works. So if you “master” RubyMotion over the course of a couple of years, by virtue of my previous statement you would have had to “master” Cocoa Touch. So 90% of your work is already done if you need to move over to Swift. You would just have to learn a little bit about Swift and get in the mindset of writing in a typed language.

When moving from RubyMotion to Swift I would estimate it took me two weeks to get back to full productivity. The learning curve moving to Swift was minimal, even for someone who hadn’t coded professionally in a strongly typed language. Due to my level of experience with Cocoa Touch I could get into the swing of things easily. 

So…if RubyMotion is so great, why is TFG moving away from it? Let’s have a look.

RubyMotion or Swift?

There were a couple of points that always came up when discussing whether TFG would be a RubyMotion or Swift/Objective C shop. Here’s a verbose run through of each, if you don’t have time to do heavy reading, skip to the bottom for a summary.

Learning a new language: Weakly Typed vs Strongly Typed

Your company needs to think about how the learning curve of moving to a typed language will affect your bottom line if none of your developers have experience with typed languages.

RubyMotion: At TFG, we had a high level of experience with Ruby via Ruby on Rails. So there was no time spent learning new syntax for RubyMotion. I knew all the string and array functions in Ruby, how to declare functions, and how to do sneaky things with blocks. When I started RubyMotion, I only had to learn a new framework (Cocoa Touch), rather than learning a new language (Swift), framework (Cocoa Touch), and bloated toolset (Xcode). That had a huge positive impact on my delivery time and app quality.

Swift: Moving to a strongly typed language like Swift would require some acclimation for our developers. It would open us up to lots of time spent thrashing around trying to solve basic syntax problems.

At first it felt like my hands were tied behind my back because I didn’t know how to do basic things. With Swift being a new language there isn’t the wealth of stack overflow and other posts with solutions to basic problems. I had to solve a lot of problems myself via trial and error and beta level compiler error messages. So our concerns that learning a new language would be costly were definitely warranted. There will always be teething issues when learning new languages – this is not unique to Swift.

However, if you are coming from a company with lots of experience with a typed language then you may have an easier time picking up Swift than RubyMotion. It really depends on your company’s background.

Development Environment: Xcode vs command line and text editor

Your company needs to bear in mind how its developers like to work. If nobody likes the type of environment provided by RubyMotion, they’ll hate working with it and productivity and morale will drop. On the other hand, if your developers hate using IDEs then they may prefer not to use Xcode’s development environment and may not like the idea of moving to Swift.

RubyMotion: RubyMotion apps can be completely built with just your favourite text editor and a Bash prompt. You do not need to interact with the Xcode UI directly at any stage if you don’t want to. I mentioned above you can use the IB gem to use Interface Builder if you want. I would recommend looking into it. Implementing autolayout is trivial using IB, and a serious pain to write manually with code. Although there are libraries that attempt to work around it. like MotionKit (teacup’s progeny) and the much older motion-layout.

Swift: You can use Swift without having to rely on Xcode as your primary editor.

If you don’t use storyboards or xibs, you don’t need to use Interface Builder. Interfaces can be built entirely in code. However, the API for manually writing autolayout constraints is laborious. Interface Builder does a fantastic job of implementing autolayout and it is a breeze to use after the initial learning curve.

The crux of the matter is that an aversion to using Xcode should not prevent you from looking into Swift. However, I think any iOS developer would be well served by becoming proficient in using Xcode.

Xcode is likely where you will end up if you choose Swift development. Make sure that your development team can get on board with that.

Some other things you should look at when determining how your team will enjoy the development environment:

  • Syntax of the language. Objective C was a no-go for me. Swift has a much more readable syntax. RubyMotion is even better (I love you, Ruby).
  • Availability of 3rd party plugins. RubyMotion has access to some Ruby gems AND all the Cocoapods via motion-cocoapods, Swift has access to Cocoapods).
  • Testing frameworks available. RubyMotion has MacBacon which is a fairly stripped down RSpec clone for unit testing. You have access to tools like motion-calabash for interface testing. Look at the last updated dates for those libraries, they are old and dusty. I’m not up to speed on the pimpest testing available in Swift and Xcode, so I’ll leave that topic for now. You will need to do your own research and make your own judgements. 

Development Environment: Instruments Support

RubyMotion doesn’t have the same support for Instruments that Swift does.

When I was tracking down memory leaks in RubyMotion apps I had to do it manually. The only Instruments that I could use were for checking total app memory and CPU usage. That and a combination of handily places puts statements in dealloc calls were what allowed me to solve all the memory issues I had in the cornucopia of RubyMotion apps I worked on.

If you really love tools like Instruments, Swift will win hands down. However, if you’re a “get your hands dirty” type like me, there are other ways to resolve your issues.

Development Environment: Debugging

Stack traces from RubyMotion can be pretty damn useless

I have nothing to say in favour of the stack traces RubyMotion provides. Sometimes you get a stack trace, sometimes you don’t. I’m guessing depending on which thread the process was running. When you do, sometimes the stack trace appears to be pointing to re-allocated memory and no longer has any useful information for you.

If you rely on stack traces for your debugging, RubyMotion is inferior to Swift. It never stopped me from fixing bugs, but I’m a fairly experienced developer. I think newbie devs will have a really hard time debugging RubyMotion apps. You have to know where to look for bugs.

Don’t get me wrong, for any memory issue in either language you’re going to have a hard time in the beginning.

Development Environment: REPL vs ‘REPL’

The REPL in RubyMotion allows you full access to your app – you can change views, update CoreData instances, test your classes out, and check instance variable values. The REPL in Swift is nowhere near as powerful at the moment.

RubyMotion: If you’re like me and you love to make live changes to your app to test out how font sizes will look or add data on the fly, you’re going to want to use RubyMotion.

Swift: The REPL in Swift is almost pointless to me. There were some interesting demos in the WWDC talk, but I have not been able to make it do anything useful. 

Community

RubyMotion has less conferences, user groups, and developers than Swift. Swift’s community will grow faster than RubyMotion’s.

RubyMotion: RubyMotion is relatively young, and still pretty niche. Early on we saw some big hitters like the BaseCamp app embrace RubyMotion, but RubyMotion really hasn’t become mainstream. As a result, the amount of media related to RubyMotion is quite small. One thing to keep in mind is that it will be much harder to replace RubyMotion developers than it would be to replace Swift developers (who will shortly be a dime a dozen). This could also affect things like salary, but I don’t really want to go down the supply and demand path.

Want to have a look at some of the community sources for RubyMotion? Check their official blog and the google group. You could also join the /r/rubymotion subreddit, sign up to the RubyMotion dispatch or MotionInMotion. If you’re new to RubyMotion, you should read Clay Allsop’s RubyMotion Tutorial. 

If conferences are your thing, keep an eye out for #inspect next year, as it has already come and gone for 2014.

Another note on community – RubyMotion belongs to the Ruby community. I’ve seen RubyMotion talks popping up at Ruby conferences as well, like Laurent Sansonetti doing a talk at Ruby Kaigi 2014.

Swift: Although Swift is even younger than Rubymotion, it is the new in vogue programming language for iOS and Apple approved. I think it’s a safe assumption to make that over the next couple of years Objective C developers will be making the move to Swift. There will be a lot more user groups, meetups, and conferences aimed exclusively at Swift developers than there will ever be for RubyMotion.

Apple have an official Swift blog that is updated every couple of weeks so far. As Swift is very new I can’t really point to any great sources of information yet. There are plenty out there, I just haven’t had the time to comb through them and sort the good from the bad.

If you want to talk conferences, you aren’t going to get much bigger than WWDC – follow this link to see all the talks from 2014. Lots of Swift content there.

On the other hand: There are tonnes of resources regarding iOS development that cater for both RubyMotion and Swift developers. The iOS Dev Weekly is a great newsletter to subscribe to, for example. RubyMotion developers can also learn a lot from WWDC talks about Cocoa Touch specific topics. Although they’ll have to convert the code samples from Swift.

Regarding hiring Swift and RubyMotion devs…TFG has hired Objective C developers before to work on RubyMotion projects. It didn’t go well. Developers can often be dogmatic, and I think you’ll find that some people beat the “one true language” drum a little too hard. Depending on where you live, you might not be able to find any local RubyMotion developers. If you only have one developer on RubyMotion, consider whether you can afford to have your bus factor that low.

One very important thing to keep in mind regarding community size is the number of open source contributors. Rails developers are used to standing on the backs of giants. Rails itself is open source and constantly updating. We also rely on tonnes of other gems to build our apps as efficiently as possible (for example: devise for authentication).

In small communities these gems have less people to work on them. This means gems will be updated less frequently, and will have less feedback used to fix bugs and build improvements.

Documentation

The Cocoa Touch documentation is written using Swift and Objective C samples.

All the code you’ll find in the extremely well written Apple docs is written using Swift and Objective C sample. If you’re writing Swift you can copy it into your code. In RubyMotion you will need to convert it into RubyMotion code first. This may not sound like a huge deal until you consider the how verbose some of the Cocoa Touch methods are and how often you’ll have to convert them.

This can be very difficult for RubyMotion beginners with little Cocoa Touch experience. It tripped up some of the developers at TFG early on.

Summary

RubyMotion Swift
Production ready? 100% 100%
Language Weakly Typed (variant of Ruby) Strongly Typed
Integration with Xcode and Interface Builder Good, thanks to the IB gem. Great, there’s still some missing functionality as of Xcode 6 GM (like the refactor function).
Integration with Instruments Poor, you can get basic system usage but not much more Great
Integration with Cocoa touch Good, some issues now and then Great
Debugging Average. It’s not terrible but finding memory leaks is a manual process without Instruments support Good. Stack traces are relevant. Memory issues can be tracked down using instruments
REPL Great Poor at the moment
Maintainers Small. There’s a tiny bus factor keeping RubyMotion (the toolchain) alive. If Laurent et al decide they no longer want to support RubyMotion you’re out of luck. Swift is supported by one of the wealthiest companies on the planet (Apple). After Apple adopted Objective C they proceeded to significantly upgrade it. It feels safe to assume that Swift will continuously get upgraded by Apple.
Community Small, but active Hard to say at the moment due to Swift’s recent release. If we assume it will be as big as Objective C’s – Large.
Conferences Few (#inspect being the primary, but Ruby conferences often contain RubyMotion talks) Many. WWDC has general Cocoa Touch information but primarily Swift focussed
Employment Opportunities Fewer Many
3rd party plugins Plenty of RubyMotion gems, access to CocoaPods via motion-cocoapods Access to CocoaPods
Stack Overflow posts Few for RubyMotion, lots for Objective C that need to be converted Few for Swift, lots for Objective C that need to be converted. This will change over time in favour of Swift.

Making a decision

At TFG, we looked at everything we knew about our company and developers and decided we wanted to move forward with Swift. Personally, I was very excited to learn a new language. I reasoned that knowing more languages would make me a better developer and benefit TFG. I think this has proven true in only a few short months.

There are pros and cons for both RubyMotion and Swift. As a company, you need to sit down and decide what’s important to you before moving forward with a decision. Neither choice is objectively better.

Further Reading:

How to import a Photoshop colour swatch into XCode Storyboards / OS X ColorPicker palette

Posted in Inside TFG

I’m frequently amazed at the work done by our design team, and where possible I try to do pixel perfect implementations of their designs. When designing an iOS application in Photoshop our designers often build a colour swatch that incorporates the client’s branding and the colour scheme intended for the application. Instead of importing these colours manually I recently investigated how to import a Photoshop colour swatch into XCode [1][2].

Steps

Exporting

  1. Create a colour swatch in Photoshop, naming the colours appropriately (these names will be visible in XCode).
  2. Use the swatch menu to save the Swatches for Exchange (This saves the swatch using the Adobe Swatch Exchange format (ase). Note, the filename dictates the palette name in XCode.

Importing

  1. Clone, build, and install the excellent SwatchInstall.app by Ramon Poca. Note, the other command line tools in this package are not required.
  2. Start SwatchInstall.app and drag and drop the ase file onto it.
  3. Restart XCode.

That’s it! Your colour palette is now be available in XCode.

Behind the scenes SwatchInstall.app converts the ase format into clr and copies the result into ‘~/Library/Colors’.

Updating

If you wish to update a color palette simply drag a new version of the ase file onto SwatchInstall.app and restart XCode [3].

Deleting

If you wish to a remove a colour palette, delete the file from ‘~/Library/Colors’ and restart XCode.

Caveats

[1] Note, we tested this process using OS X 10.9.4, XCode 6 beta 4, and Photoshop CC  14.2.1 x 64.

[2] The colour palettes available in XCode are actually imported from the operating system. If you move a project between computers the palette will not be available unless it has been imported on that machine.

[3] Unfortunately XCode storyboards copy colour values rather than linking them. Therefore, if you update the colour palette your storyboards will not be updated.

Search Posts

Featured Posts

Categories

Archives

View more archives