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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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)
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
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
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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
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
designatednerd
_kensh
wernerkrauss
isaoshimizu
asahihidehiko
makotu
hacomono
saboyutaka
riru
bumptakayuki
devops_vtj
th0x0472
nagix
ufuk
cromwellryan
hursman
marcelosomers
schacon
caitiem20
kastner
thoeni
nonsquared
aki_iinuma
ddemaree
smashingmag