Upgrade to Pro — share decks privately, control downloads, hide ads and more …

All you need is tools

All you need is tools

Developers architect apps, write software, develop new features, and attend conferences like WWDC to learn and bring the new exciting features into their apps. To do so, they use Apple’s official tools like Xcode, and open source projects like CocoaPods or Fastlane. Those are powerful tools but designed and optimized to meet the needs of any sort of project: large, small, written in Swift, but also in Objective-C, for solo developers, and for large teams.

When projects start getting far off the standards for which the tools are optimized, the tools and services can turn into a source of issues. Those usually hold the teams back from being productive and delivering a high-quality final product.

In this talk, I talk about why investing effort into developing your own tools is crucial to move on steadily with motivated and productive developers. Furthermore, I'll give attendees some tips to know when is the right time to do such investment, and go through some real examples of impactful tools that my team has developed to bring best practices and conventions across the whole organization.

Pedro Piñera Buendía

June 06, 2019

More Decks by Pedro Piñera Buendía

Other Decks in Technology


  1. Pedro Piñera Buendía | @pepibumur All you need is tools

  2. • Based in Berlin but originally from Spain. • Build

    tools for mobile developers at Shopify (iOS & Android). • Love doing open source work like Tuist (tuist.io). • github.com/pepibumur • twitter.com/pepibumur About me
  3. • Why you should invest in tools. • How to

    design, develop, and release great tools. • Examples of tools that we’ve developed at Shopify. What will I talk about?
  4. Developers need tools to create apps.

  5. None
  6. Tools can make you productive and bring you focus.

  7. Tools can prevent errors or make them more obvious.

  8. Tools can automate manual work.

  9. Tools define a shared language, facilitating cross- project work.

  10. Tools are usually designed to target a group of users

    and their needs.
  11. Xcode Optimized for small & medium sized apps. Large apps

    come with complexity, high compilation times, and no flexibility to change the build process.
  12. Fastlane Optimized for teams which barely can invest time into

    tooling. Used extensively results in a lot of duplication and untested automation code.
  13. Bazel Optimized for large projects with high compilation times. Used

    in small projects it introduces unnecessary overhead.
  14. There aren’t good or bad tools; 
 there are tools

    more suitable to your needs than others.
  15. When a tool doesn’t suit our needs, our natural response

    is to tweak it.
  16. Compilation with Xcode is slow I’ve seen person X, who

    works for company Y, who published a tweet talking about the flag Z, which should speed up compilation.
  17. There isn’t a Fastlane lane to do X I’ve seen

    someone who published this piece of Ruby code on Stackoverflow that we can wrap into a lane and problem solved.
  18. Manageable code Shared code Consistency Reliability (tests) Deterministic Readable errors

    Reproducible environments Unreadable code Duplication Inconsistencies Untested code Flakiness Puzzling errors Non-reproducible environments Well-designed tools Tweaked tools
  19. High-quality tools Developers’ productivity & motivation High-quality products

  20. Tips 
 How can I create high-quality tools?

  21. Talk to your users about their problems. 1

  22. Talk to your users

  23. Add integration tests. Because the contract with the local environment

    is out of your control. 2
  24. Integration tests

  25. Add metrics. You can’t improve the tools if you don’t

    understand how developers use them. 3
  26. None
  27. Tools are software; test them and strive to keep the

    software well structured. 4
  28. Tools should evolve with the project. Today’s tools and processes

    might not work in the future. 5
  29. Prefer convention over configuration. 6

  30. Convention Configuration

  31. The standard output and error are limited resources. Don’t waste

    them! 7
  32. None
  33. Treat errors as first-class citizens. Try to understand them and

    make them actionable. 8
  34. Not-handled error

  35. Handled error

  36. Tools are products. They need to be devised, designed, implemented,

    documented, released, supported, iterated… 9 %
  37. Questions are opportunities to build tools. 10

  38. Examples

  39. - An iOS developer “I’m trying to set up my

    local environment to work with this project but I can’t figure out how.”
  40. Dev tool %

  41. - An iOS developer “I’d like to test out this

    PR but I’d spend 15 minutes compiling the app.”
  42. Mobile tophat

  43. Mobile tophat

  44. - An iOS developer “Releasing apps is so frustrating; the

    last time it failed due to signing issues and this time the compilation fails.”
  45. None
  46. Easy to consult current and past releases.

  47. Easy to create a hot- fix release. Suggestion of the

    next version number. Integrates with CI statuses.
  48. Easy to see who is responsible for the release. Prevents

    uploading the app when the tests are failing. Easy to distribute to different channels.
  49. - An iOS developer “Maintaining the Xcode projects became a

    burden; when I add new frameworks to the stack, I have to change many settings and build phases.”
  50. None
  51. Demo

  52. • Investing in tooling pays off in the long term.

    • Tools are products; development is one step in the process. • They deserve the same love that is put into the product they are meant to be used with. • Don’t push tweaks beyond their limits. Takeaways
  53. Thanks! Pedro Piñera Buendía
 @pepibumur - pedro.pinera@shopify.com Slides: https://bit.ly/31aGO7q