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.

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
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
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