Winners at the 20th AIMIA Awards

As we posted about a few months ago, we were really excited to learn that an app we built was nominated for two AIMIA Awards. We're now thrilled to report that the app, Play School Play Time for iPad, built for the ABC, was the winner of the 20th AIMIA Award "Best of Tablet – Entertainment" category, as well as the overall "Best of Tablet"! You can watch the winners videos on the AIMIA website.

We couldn't be more thrilled! We're incredibly proud of the Play School apps, and enjoyed working with the ABC team. The ABC team included: David Glen, James Welbourn (pictured), Priscilla Davies, Tali Gal-on, Peter Marks, Jake MacMullin, Sam Gain-Emery (Sonar Sound), Luke Mynott (Sonar Sound), and Kate Highfield (Education Advisor). Thank you all!

If you haven't already checked out Play School Play Time for iPad, check it out and let us know what you think!


SnapTas: winner of the Go South Awards 2014
Screen Shot 2014-03-31 at 12.02.14 pm.png

SnapTas is a fun little app that we made earlier this month as part of the Go South Awards  competition, which is an app development competition down here that's run by the Tasmanian Government. We're pleased to announce that SnapTas won the business category of the competition! Congratulations also to Bappy Golder, who won the individual category in the competition!

If you were a VC we were pitching to, here's how we'd describe it: "Instagram, but for Tasmania, with retro travel post cards."

We made SnapTas because it's harder than it should be to find great examples of people sharing photos and content that shows off what makes Tasmania such a great place to live. Tasmania is world famous for its scenic environment and its high quality of life, and has hundreds of thousands of interstate and international visitors every year. Right now, though, the best way to find pictures that people have shared is to try searching for hashtags on Facebook, Twitter and Instagram.

Every visitor has a different perspective on our beautiful island, and they enjoy sharing them with the world. SnapTas makes it easy to share and discover photos of Tasmania by creating a dedicated social network for both tourists and locals: when you're in Tasmania, take a photo or pick one from your camera roll, and SnapTas makes it look like a delightfully retro 1950's postcard. It's then shared with your Facebook friends, and you can also choose to make your photo available to everyone via the web.

For tourists, SnapTas is a way to share your trip to Tasmania. For locals, it’s a way to share your unique perspective on your home. SnapTas serves as a showcase of the best of Tasmania, and a single point to show potential visitors, or those want to move to our lovely island.

SnapTas also helps you share photos to Twitter and Facebook. The more people seeing Tasmania, the more people coming to visit and sharing their experience on SnapTas!

We used Parse for the backend of SnapTas, which handles user sign-up, data storage, push notifications, and all of the sharing, commenting and liking features. All of the images get rendered on the iPhone before being uploaded. 

SnapTas will be available to the public soon.

Storyboards and NIBs: A Rebuttal

Beneath the relatively placid surface, a battle is raging among iOS developers.

On one side, we have developers who use the built-in visual interface development tools for constructing their screens. On the other, we have the code purists, who insist on entirely generating their interfaces from code.

Storyboards have a number of important advantages:

  • Seeing your design means thinking visually
  • Storyboards let you see how apps flow together
  • Storyboards are the only way to use segues, which are a marvellous way to handle the transitions from screen to screen.
Screen Shot 2014-02-10 at 1.40.28 pm.png

Apple vigorously promotes the Interface Builder and the use of Storyboards, but there's a surprisingly large number of developers who insist on not using them. One famous example is Google, who, as of 2012, apparently forbade the use of storyboards and XIB files, as well as checking in .pbxproj files (that is, the actual project files used by Xcode to organise where files go.) The reasoning provided is that merging these files is too much of a challenge.

Google aren't the only ones insisting that storyboards aren't a good idea. There are dozens of examples of developers promoting this viewpoint, and here are the most common arguments we see.

"Programmers should code, and not do visual design. You should know how views work from the ground-up, and being able to code your interface is more extensible."

A good programmer knows more than just than their specialty. The argument that programmers should only focus on the written component of their apps implies a separation of skills that simply isn't workable in mobile apps: if you're making an application that relies on the user holding a screen in their hand, deliberately not thinking visually means that you'll be more likely to not catch small visual problems in your app's design.

There's a lot to be said for understanding views and view controllers from the ground up, for the same reasons as understanding any other topic in programming: knowing as much as possible about what's going on behind the scenes makes it easier for developers to make more advanced use of the technology. However, this isn't an argument for avoiding the Interface Builder - understanding how views work doesn't require that you manually create them in your code.

"Creating re-usable views is harder. Also, custom views are hard to see in IB, they're just white boxes."

Another common argument against using storyboards is that using custom views is harder. For example, if you've got a view controller that needs to use a custom selector view of some kind, embedding a view that you've designed in a XIB can be a pain.

However:

  • Using the Interface Builder doesn't mean that you have to use the Interface Builder for everything. You're still free to embed a custom view, set its class, and then provide a loadView method for that class to manually create the view hierarchy for that class.
  • Embedding view controllers using container objects is straightforward. If you need to embed a collection of views elsewhere, or if you want to break out the logic of a screen into multiple sub-units, use the Container View object to break out a collection of views into a separate view controller.

A related argument that we see is that custom views just look like empty white boxes in your view controller's designs. Technically, that's true - if you drag in a generic UIView, and set the view's class to your own, it'll still appear as a generic white box. However, this argument against storyboards ignores some important facts:

  • Unless you care about the contents of your custom view, seeing a preview of your view isn't a requirement for constructing the rest of the screen. Positioning and sizing the view on the screen is the most useful feature, and that's what you get.
  • A number of important, Apple-provided views also appear as empty boxes. The point isn't that you get to see the content, but rather that positioning and arranging the view in the screen is significantly more straightforward.

"Auto-Layout sucks, and doing the layout yourself is easier to understand."

Auto-Layout has received a significant amount of criticism since it was introduced, and many developers argue that the older method of struts and springs (as well as defining frame rectangles for each view) is easier to understand.

This was a fair criticism - in Xcode 4, constraints were a huge mess, and it was very difficult to understand how re-repositioning a view in the Interface Builder would affect the constraints.

However, Xcode 5 and iOS 7 has simplified this considerably. You no longer receive a soup of vertical and horizontal blue lines, and controlling the position and size of views using constraints that you design in the Interface Builder is simple and straightforward.

"Using storyboards means designing your interfaces in Xcode, which is slow and crashy."

Xcode doesn't have a great reputation for stability, it's true. However, the time lost to re-launching Xcode after a crash is miniscule compared to the amount of additional time you'll take designing, testing and debugging your layout code.

(Xcode's still the worst IDE ever built, but that makes it no different to every other IDE.)

"Dealing with lingering outlets leads to crashes."

It's a common situation: you link a view to a class using an outlet; later, you decide you don't need the outlet, so you delete it from your code. You run the app, but the view still wants to connect to the now-deleted outlet. Your code crashes. You scream with rage.

This is a reasonable criticism - Xcode should at least provide a more visible warning that the property is missing. However, it's nowhere near enough of a reason to forswear ever using it.

"Merging sucks."

This is the only valid major criticism, and is the major one that causes organisations to ban the use of storyboards and XIBs in their codebases.

However, starting with Xcode 5, the Interface Builder is getting better and better at detecting merge conflicts. When a merge results in structurally valid XML but an invalid storyboard, Xcode will attempt to repair what it can: for example, if merging two versions results in an object connecting to an outlet that was removed, Xcode will notice it, and correct it.

Part of the problem, from a human perspective, is that dealing with merging two versions of a storyboard means working with XML, which is text; normally, working with storyboards is a visual task, but when there's a problem, you have to jump down to text and interpret what the XML actually means.

The XML used by storyboards, however, is actually pretty straightforward. Each view controller is an element that contains its subviews and other components (such as gesture recognizers or segues), and references to other objects are done with short alphanumeric strings. If there's a conflict, it's generally because two developers both inserted views into the same view controller - in which case, it's about as straight to recognize and fix as it is to fix a merge conflict in code.

Parting notes

Storyboards and XIBs are one of the most powerful and flexible tools that you get as part of the iOS developer tools, and shunning them means you lose both flexibility and features. If you're avoiding storyboards for personal reasons, we strongly recommend that you give them a try. If you're avoiding storyboards in your team because of the risk of merge conflicts, get some practice in fixing merge conflicts - they're easier than you think.

If you have any comments, email us!

Go South Awards

Yesterday the Go South Awards were announced in Hobart. The Go South Awards is a competition to design and develop an amazing new app, of any kind, for Tasmania.

The competition has some really solid prize money, and looks like an excellent opportunity for app developers and students hoping to make their mark! Check out the Go South Awards website (built by our friends at Ionata and onetonne) for more information.

We're really thrilled to see an event like this pop up in Tasmania, and commend our friends in the Tasmanian Government, TasICT, and the ACS for collaborating on it. 

iOS Developer Training in Hobart
DoctorScience-Framed.png

We're really excited to announce an intensive 2-day iOS developer workshop in our hometown, Hobart. The workshop is organised in conjunction with ACS Tasmania.

You can learn all about it on our training page, or over at the ACS website. There is a discount for ACS members.

The workshop is designed for existing programmers (of any sort) who want to learn iOS development, or iOS programmers who want to get up to speed with the latest techniques for building iPhone and iPad apps. It teaches the very latest public iOS developer tools and features.

Brisbane and Melbourne iOS developer training is also currently open for registration.