Building It Twice - MobileWebDevCon San Francisco, July 2015

Building It Twice - MobileWebDevCon San Francisco, July 2015

A presentation summarizing what I've learned from a couple of different experiences building native clients for both iOS and Android.

C4861b1dfdf3bbb21faec4a1acdf183d?s=128

Ellen Shapiro

July 15, 2015
Tweet

Transcript

  1. Building It Twice Lessons from building apps natively for iOS

    and Android July 2015 | MobileWebDevCon | San Francisco, CA by Ellen Shapiro vokal.io | justhum.com | designatednerd.com | @DesignatedNerd
  2. None
  3. None
  4. None
  5. None
  6. Why Go Native?

  7. Why Go Native?

  8. Names have been changed to protect the innocent my current

    and former employers' legal teams
  9. Case study #1: Hard Liquor Distribution

  10. What does the app do? —Helps distributors sell more of

    a high-end brand of hard liquor with profit calculators
  11. (A lot)

  12. What does the app do? —Helps distributors sell more of

    a high-end brand of hard liquor with profit calculators —Keeps distributors in touch with news from the brand
  13. What does the app do? —Helps distributors sell more of

    a high-end brand of hard liquor with profit calculators —Keeps distributors in touch with news from the brand —Gives distributors access on the go to assets they can use to promote the brand.
  14. How was the app built? —Built iOS and Android at

    the same time.
  15. How was the app built? —Built iOS and Android at

    the same time —Team of 3 iOS and 3 Android developers (not including myself)
  16. How was the app built? —Built iOS and Android at

    the same time —Team of 3 iOS and 3 Android developers (not including myself) —Very, very well defined design from direct client
  17. How was the app built? —Built iOS and Android at

    the same time —Team of 3 iOS and 3 Android developers (not including myself) —Very, very well defined design from direct client —API built and managed by end client...less well.
  18. What went well? Please do these things.

  19. What went well? What: Extremely clear style guide from the

    agency
  20. What went well? What: Extremely clear style guide from the

    agency Effect: Devs created reusable styles and classes, changes could be made once, applied everywhere.
  21. What went well? What: Extremely clear style guide from the

    agency Effect: Devs created reusable styles and classes, changes could be made once, applied everywhere. Lesson: Spending time on a clear style guide in design can save a lot of time in development.
  22. What went well? What: Designs and wireframes took platform- specific

    idiosyncracies into account.
  23. What went well? What: Designs and wireframes took platform- specific

    idiosyncracies into account. Effect: Devs didn't need to ask questions about how something should work on iOS vs. Android.
  24. What went well? What: Designs and wireframes took platform- specific

    idiosyncracies into account. Effect: Devs didn't need to ask questions about how something should work on iOS vs. Android. Lesson: Think through how different platform conventions affect the user flow at design time.
  25. What went well? What: Platform teams would work on different

    features at the same time.
  26. What went well? What: Platform teams would work on different

    features at the same time. Effect: Each team was able to tell the other about potential land mines in that feature before building.
  27. What went well? What: Platform teams would work on different

    features at the same time. Effect: Each team was able to tell the other about potential land mines in that feature before building. Lesson: If you're building in parallel, don't always have all teams building the same thing.
  28. What went poorly? Please do not do these things.

  29. What went poorly? What: While iOS only had to support

    the current version (iOS 6), Android had to support Gingerbread.
  30. What went poorly? What: While iOS only had to support

    the current version, Android had to support Gingerbread. Effect: The same feature on Android 2.3 would take multiples of the effort it took to build on iOS 6.
  31. What went poorly? What: While iOS only had to support

    the current version, Android had to support Gingerbread. Effect: The same feature on Android 2.3 would take multiples of the effort it took to build on iOS 6. Lesson: Think hard about effort to support a platform vs. # of customers using that platform.
  32. What went poorly? What: Backend team was behind schedule, changing

    environment without notifying app devs
  33. What went poorly? What: Backend team was behind schedule, changing

    environment without notifying app devs Effect: When something would go wrong, it would waste twice as much time.
  34. What went poorly? What: Backend team was behind schedule, changing

    environment without notifying app devs Effect: When something would go wrong, it would waste twice as much time. Lesson: Set up clear times for updates and clear channels for communication.
  35. What went poorly? What: Neither the iOS nor Android teams

    wrote many tests.
  36. What went poorly? What: Neither the iOS nor Android teams

    wrote many tests. Effect: When something broke, we didn't know until much later, and it was hard to find the cause.
  37. What went poorly? What: Neither the iOS nor Android teams

    wrote many tests. Effect: When something broke, we didn't know until much later, and it was hard to find the cause. Lesson: Writing tests costs time up front, but saves time later.
  38. Case study #2: Getting Your Car Back From The Valet

  39. What does the app do? —Allows users to request their

    car from their phone and pay/tip with a credit card.
  40. What does the app do? —Allows users to request their

    car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested.
  41. What does the app do? —Allows users to request their

    car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car is being brought around.
  42. What does the app do? —Allows users to request their

    car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car has been brought around. —Gives users a cashless valet experience
  43. What does the app do? —Allows users to request their

    car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car has been brought around. —Gives users a cashless valet experience —Users don't wait for their car in the rain / cold.
  44. How was the app built? —Built iOS MVP, then built

    Android client as iOS added new features.
  45. How was the app built? —Built iOS MVP, then built

    Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag)
  46. How was the app built? —Built iOS MVP, then built

    Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag) —In-house design by Vokal
  47. How was the app built? —Built iOS MVP, then built

    Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag) —In-house design by Vokal —In-house backend by Vokal
  48. What went well? Please do these things.

  49. What went well? What: Backend team was well ahead of

    schedule for initial iOS build, APIs were well-documented
  50. None
  51. via https://www.flickr.com/photos/girliemac/6514584423

  52. What went well? What: Backend team was well ahead of

    schedule for initial iOS build, APIs were well-documented Effect: I rarely ran out of stuff to do and was almost never blocked by backend issues
  53. What went well? What: Backend team was well ahead of

    schedule for initial iOS build, APIs were well-documented Effect: I rarely ran out of stuff to do and was almost never blocked by backend issues Lesson: App dev is hard without a working backend. Get your BE team ahead as far as possible.
  54. What went well? What: iOS app was built to MVP

    before Android app build started.
  55. What went well? What: iOS app was built to MVP

    before Android app build started. Effect: Issues only needed to be fixed once. User feedback was addressed before Android started.
  56. What went well? What: iOS app was built to MVP

    before Android app build started. Effect: Issues only needed to be fixed once. User feedback was addressed before Android started. Lesson: Building sequentially can save time on subsequent apps.
  57. What went well? What: Thorough, clearly named UI and behavior-

    driven tests for iOS were written
  58. What went well? What: Thorough, clearly named UI and behavior-

    driven tests for iOS were written Effect: Test names/comments could be lifted to start tests on Android, saving even more time.
  59. What went well? What: Thorough, clearly named UI and behavior-

    driven tests for iOS were written Effect: Test names/comments could be lifted to start tests on Android, saving even more time. Lesson: Having the 1st app tested makes it easier to ensure later apps are testing/doing the same thing
  60. What went poorly? Please do not do these things.

  61. What went poorly? What: I vastly underestimated how much I

    had to relearn and how much had changed in Android dev
  62. What went poorly? What: I vastly underestimated how much I

    had to relearn and how much had changed in Android dev Effect: A lot of gains from the things that went well were cashed in on rewriting functionality and tests.
  63. What went poorly? What: I vastly underestimated how much I

    had to relearn and how much had changed in Android dev Effect: A lot of gains from the things that went well were cashed in on rewriting functionality and tests. Lesson: Either get a specialist, or add significant padding to account for ramp-up on a platform.
  64. What went poorly? What: User feedback was not sought out

    before we started building due to budget concerns.
  65. What went poorly? What: User feedback was not sought out

    before we started building due to budget concerns. Effect: Users, especially Valets, had very different ideas of required functionality than we had, causing a lot of rework.
  66. What went poorly? What: User feedback was not sought out

    before we started building due to budget concerns. Effect: Users, especially Valets, had very different ideas of required functionality than we had, causing a lot of rework. Lesson: Don't wait to reach out to your user base.
  67. Obligatory Summary Slide™ —Style guides: Not just for the web

    anymore!
  68. Obligatory Summary Slide™ —Style guides: Not just for the web

    anymore! —Get user feedback before you start building
  69. Obligatory Summary Slide™ —Style guides: Not just for the web

    anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible
  70. Obligatory Summary Slide™ —Style guides: Not just for the web

    anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible —Functional/Behavior tests are far easier to repeat across platforms
  71. Obligatory Summary Slide™ —Style guides: Not just for the web

    anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible —Functional/Behavior tests are far easier to repeat across platforms —Communicate early and often
  72. Question time!

  73. Closing Vanity Slide Werk: vokal.io mobilemakers.co Moi: @DesignatedNerd | github.com/DesignatedNerd

    justhum.com | designatednerd.com