Skip to content

Instantly share code, notes, and snippets.

@jarednova
Created August 30, 2016 15:40
Show Gist options
  • Save jarednova/add228dc2dfba917ccc9b02520b55f28 to your computer and use it in GitHub Desktop.
Save jarednova/add228dc2dfba917ccc9b02520b55f28 to your computer and use it in GitHub Desktop.

What's one piece of advice you would give to an engineer/designer coming into an iOS project?

Read all the way through the iOS Human Interface guidelines, and familiarize yourself with the Apple developer documentation and sample code. UIKit provides more components than you'll know what to do with, but as soon as you receive a mockup that introduces any variations (no matter how subtle) you've got struggles ahead. Many of the core components (e.g. View Controllers, Table View Controllers, etc.) have dedicated guides and sample applications on the Apple developer site; start there. Stack Overflow rarely uncovered good solutions -- I came across more unresolved questions with a slew of hacky approaches in two months of iOS dev than I ever have with web dev. Learning how to grok the Apple API docs / support materials is essential, especially given that you can't read the source. What's one small change we could make to our process to improve the design/build process for iOS apps?

Building UIs in Interface Builder is very different than with HTML / CSS. There is the equivalent of a front-end developer for iOS apps, and since our designers don't have those skills yet they will be much more on the sidelines than they are used to. Apples' version of responsive design -- Auto Layout -- has a pretty steep learning curve. Another huge pain point that we mostly avoided given our small team size is that Interface Builder stores UI as XML files. Merge conflicts are inevitable and pretty much impossible to resolve. (Which is why a lot of people avoid IB entirely and build UIs programmatically). All of this is to say that designers will need to work very closely with developers in implementing designs. They'll also need to be familiar with the iOS Human Interface guidelines and UIKit catalog in order to produce mockups that feel native and aren't impossible to implement. (Keri did a great job with this). What is one significant difference between engineering/designing for iOS versus web tek?

Tooling. It's nice to have one technology stack to worry about, but Xcode is a beast. Iterating on UI isn't quite as rapid when you have to re-compile / run your app with every change. That said, Apple has spent a lot of time making development, debugging and distribution of your app "just work". No task runners, no minifiers, no deploy scripts -- Xcode handles it all. If you don't like the way it does it ... tough. If you could do it all over again, what's one thing you wish you really did differently?

Spend less time on Stack Overflow and more time reading official iOS dev literature. I read the Swift book and started to read Programming iOS 9 when I hit major road blocks and it was very helpful. What surprised you in doing this project? Please give an example of a good surprise and a bad surprise...

I was surprised at how quickly I was able to get the initial version of the app up and running. I had a table view displaying data from the Trace API in a few hours. (With tests!). I was equally surprised at how long seemingly simple things like resizing the navigation bar or removing the top border around a grouped table view were. You know right away when you're fighting Apples' conventions. Overall I was very pleased with where we wound up. I feel like I have a solid foundational knowledge of building iOS applications with Swift. I think it would be an interesting exercise to port Trace Reader to Android / Java, as well as use something a bit higher up like React Native to create something more portable. (Good free skate material).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment