Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save donnywals/538644c1cc6d0e2dbce4 to your computer and use it in GitHub Desktop.
Save donnywals/538644c1cc6d0e2dbce4 to your computer and use it in GitHub Desktop.

Robert van Loghem - Let your designer tweak and deploy your app

  • “The best apps are created by constant experimentation and tweaking.” You have to touch the app, play with it and iterate over your design. Just using Sketch won’t do. Designers ask for tweaks all the time, changing colors, corners, icons and tweaking animations is the kind of thing that’s important. But constantly having a designer ask about that is annoying.
  • So, what if the designer could actually get their designs into the app on their own. That would mean.. that the designer has to touch code?.. Ew! That won’t turn out well. Experimentation time!!
  • Explaining how to use Xcode to a designer can be very complicated. Showing them how to use images.xcassets is a no-brainer. Designers know how drag&drop works so that’s all fine. The next step is to allow the designer to change a label here and there. @IBDesignable is a great tool for that. If you combine that with @IBInspectable the designer can change a lot of aspects for a button or label without needing the developer.
  • Paintcode is a great tool that allows you to draw UI components and create style kits. This means that you can use Paintcode to create a style kit with colors, use those as default values on a button and the designer can change defaults without touching code. Because you can design entire UI Elements in Paintcode, a designer can change a lot without having to touch code.
  • If the designer decides that all buttons should have a different color then it’s time to refactor. You don’t want to create a project you can’t maintain yourself so if the designer is happy and made significant changes, make sure to refactor your code.
  • In order for the designer to change the project you want them to push the code to the repo. Don’t start with the command line. Make sure to get a GUI for git and make a proper, understandable README.md so your designer can use your repo and update bit of the UI.
  • When your apps become more complicated and you start talking about Cocoapods, Carthage and Paintcode your designer will be a little bit confused. If you want to use fastlane, fabric and things similar to that, your designer will be confused. It’s important to be patient and help them out where possible. If you can get your app up and running on a fresh machine in 10 minutes (excluding downloading/xcode installing) you’re fine. If it takes longer, you might have a problem.
  • At first, make sure you have a design branch. You will make sure that it remains in sync with all other stuff. You don’t want your designer to solve merge conflicts or merge their code to master. That’s very advanced and complex for designers. As time goes by, you might want to start them off creating their own branches and pull request. But at first, have them hit a magic sync button, nothing more. Your README.md should explain what your designer should do when stuff breaks.
  • You don’t want designers worrying about provisioning profiles and all that. That’s frustrating for developers who know what they’re doing, imagine how it will be for designers. This is where CI comes in. If you have a build machine you can have the designer push to a repo and then kick off a build, automatically deliver to something like Crashlytics and the designer has their changes on their iPhone or iPad. Tools you can use for CI are Travis CI, bitrise.io or even a Mac mini under your desk. Bitwise is free but times out after 600 seconds which might be too short. To build the app you can use a tool like Fastlane or just the built in tools. Delivery could be through iTunes, crashlytics or any other delivery tool you like.
  • If you’re using crashlytics you can make your app available for a certain group and optionally notify them of the new build. This could be interesting if you want to just deploy to a group of designers and not all beta testers.
  • Fastlane can integrate with a whole range of tools. It’s usually faster than using Xcode to build and deliver your app so that’s a huge benefit.
  • If you’re using bitrise.io you get to set up a virtual machine that you can manage to your heart’s content. You hook it up to a git repo so it can pull and then run the fastlane commands. In order to make it all work you have to upload your profiles and keys so you should always make sure that you trust the tool you use. If your tools provider gets compromised your keys might be up for grabs. A self-hosted solution should mitigate that.
  • Your design machine would only have Xcode, git, paint code and all that. The build tools, provisioning profiles and delivery tools aren’t on the design machine. This is all on an external machine that hooks in to git and kicks of builds.
  • Question: How often was the git repo messed up by the designer?
  • Never, we just had to revert once or twice. The designers call me over and I help them do that which is fine. Still faster than being called over all the time.
  • Question: Do autolayout constraints break all the time?
  • I always tell the designers to check their work in the simulator. This way the constraints won’t break per se. If the constraints of have to be modified and the designer is somewhat experienced I start telling them how constraints work. But because we use git it never goes terrible wrong.
  • Questions: Do you have any thoughts on Xcode server as CI?
  • Not really, making sure that everything gets delivered is important. I don’t use Xcode for this at all, I only use Fastlane. The cool thing is that they ship updates really fast but sometimes after an Xcode update it’s unstable for a while.
  • Question: How long does it take for a designer to make a tweak and then receive the update?
  • Usually about ten minutes. The CI tools has to download dependencies, build them, clone the repo and all that. I could make it faster by pre-packaging it all.
  • Question: Did you every consider prototyping tools?
  • Yes, we use flinto and sketch for that. But once the app is almost done or in a late stage it will take longer and longer to make changes. It’s easier to do this straight in the app. We do always start with a prototype and even on paper. But at a certain moment we need to move to the real thing.
  • Question: You mentions paintcode, how does performance compare to png?
  • In a tableview I have to draw to a separate layer and use that. But for instance a login screen is fine, no performance issues there.
  • Question: With paintcode you can kind of set the master layout. How do you teach the designer that they can’t change the master layout in IB?
  • At first we work together and then I let them do it by themselves. They can’t push to master so they can’t mess anything up too bad. So that’s important to me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment