When developing an app you have a lot of decisions to make because you have a lot of topics to deal with. In this talk I’m going to give you a general view on the different challenges we faced whilst working on our first React Native app. by Jan Wessel (Senior Frontend Developer @kartenmacherei)

1. Learning to drive
A story about app development

2. Who has worked on an app before?

3. App development = driving a car

4. For me the field of app development has a lot in common with driving a car and the automotive
industry in general. I'd like to give you a look on what challenges we faced and what we have learned
along the way working on our first project. All seen from my perspective.

5. Start your engines!
Our goal was to build a car, learn to drive it and then ship it to other people for their own use. When
we began working on the project, everything was new:
● the team setup
○ all new starters
● the setup
○ working with students
○ working as a development partner
● the technology
○ app project
○ unknown tools

6. The learner
The first weeks consisted of going through the theoretical parts of driving. Paperwork, learning the
principles of how an engine works, rules to follow in traffic, etc.

8. Manufacturing tools
In order to actually start the manufacturing, you need tools. Concerning those we had two choices:
1. Use OEM tools -> native development, native workbenches
2. Use aftermarket equipment and a middle-man -> frameworks
For us, OEM tools required too much of specialized knowledge, so we searched for a middle-man to
do the heavy lifting for us.
We decided on React Native in the end.

9. Searching for suppliers
Not a single automotive company today builds every component on their own. A car is one big puzzle.

11. Sourcing parts
When it comes to parts (components), you have to choose between make or buy. Working with
unfamiliar technology on a basic to medium level you should build parts on your own - to build up
knowledge.
Once you're feeling comfortable enough - and more complex features are required that would be too
time-consuming to build - buy parts!
Like e.g. Bosch is for cars, Google, Amazon and the like are for apps. And for more specific parts
there's specialists.

12. The first steps
Once we had set up our development environments, we started coding away.
With React Native you can come to the first results in a short time.

13. The first steps
Every once in a while I attempted to change gears and suddenly the engine would go out. Not the
best feeling when you've just stopped at a traffic light and people behind you are in a hurry…*

14. Change of seat

15. The group of students I mentioned earlier was given the opportunity to shape the product idea and
use us as their factory.
Everything else than development would've been part of their responsibility:
● The business model
● Marketing
● Conceptional work
● Design and identity

16. But, it didn't work out and soon it had to be decided to either stop the project or take over the
complete responsibility. The idea was valued so high that we were put in the driver's seat. And that's
when the real work began! These are a couple of topics we had to work on:
● Branding and design
● Research and development
● Shipping and marketing
● Testing and user research
● Product management and planning

17. The MVP - the prototype

18. The prototype
We all know what a car looks like. And we also know that there are different types of cars. Sports
cars, coupes, sedans, minivans, etc. They come in different shapes, different sizes, with different
features and at different prices.
We sat together and had to clarify the overall vision of what kind of car we were about to build and
then had to define a MVP.

19. The prototype
When you work on an MVP, you're easily lured into reducing the scope so much that the MVP does
not fit your vision anymore. Don't do that!
If your plan is to build a car – build a car! Not a skateboard, not a scooter – a car. It's perfectly fine
to reduce the scope so that it fits your skills, budget and plans at the time being.
It might be a good idea to not start with a full-fledged luxury car that has every option available. You
don't need heated leather seats or autonomous driving for your first build!

20. Still you should have your potential customers in mind! Start small whilst still building sth. useful
and at best enjoyable. That's your MVP.
We initially made a few mistakes in the beginning because we didn't correctly define our MVP*. After
an initial build and a couple of test-drives we felt that we had to add more features. We didn't ship
early enough and that slowed us down.
The prototype

21. Branding and design

22. People associate a product with its brand and certain qualities that the brand carries. E.g. a Volvo is
considered to be durable and almost indestructible. A Porsche is believed to be one of the best
sports cars in the world, because it's reliable and straightforward.
People can identify with those qualities - although a single car of the brand might not have those
qualities.
Branding

23. Starting from the drawing board like us, you'll realize that you're not only working on a product. At
the same time you're actually building a brand.
That and the values you associate it with, help you and your customers to form a relationship with
your produce.
Branding

24. A lot of buying decisions are not triggered by rationale but by emotion. Besides the brand qualities
it's also the look (and feel).
People get emotionally attached to a car not only because of its power, its sound or the comfort of
the ride. It's the design that gets them hooked!
But be aware that defining the design can cost you a lot of time and cause frustration. So: be a
copycat (or at least start using a UI library)!
Design = emotion

25. Being a copycat like the chinese automotive industry has been for a long time, comes with its own
benefits. You're saving time and money. And at best the design you copy appeals to the targeted
audience.
In the beginning we struggled a lot coming to an agreement over a design, both for the interior (the
GUI) but also for the exterior (the brand) and marketing media.
Having a design studio you trust and especially one that delivers, pays off. Today - and that's even
better - we now have an inhouse designer in our team!
Design

26. Guidelines

27. Following guidelines for app design are like targeting different markets, to an extend it's like you're
manufacturing for RHD and LHD at the same time. iOS and Android in our case.
For an MVP and likely for the first iterations of the prototype, you might not have to follow the
guidelines very strictly as to some extend they are similar.
But as your feature-set grows you should have a more strict look at them. Especially when it comes
to navigation!
Design by the guidelines!

28. But you just said to follow the guidelines? Yes. But sometimes you should also follow good
judgement and adjust things to your brand! Also, the existing app design guidelines are not really
optimized for the reality (think about reachability of buttons for example).
No one wants a car that looks the same as every other. Despite that they all work similarly, many
have their own specialties.
Don't design by the guidelines!

29. Testing

30. One thing that can't be overstressed, is the need to keep your car in a solid and safe state, especially
after you've added tuning parts. Thrown a new ECU (Engine control unit) in? You'd better check
thoroughly if all affected systems still work as intended!
That's why you not only need engineering, but you also need test drivers.

31. As an engineer you cannot always foresee the effect of changed parts, how well the play together or
if modifications to existing parts probably cause more wear and tear on the car.
A test driver can be one of the peers from your team, but better be someone who doesn't know about
the modifications and test the produce as if they were an un-cautious customer.

32. Navigation

33. Once you're feeling comfortable enough with your prototype car, you will be adding comfort features.
So you've got to add switches and dials for the driver to access those. And as we're not living in the
days of mechanical applications anymore you'll be integrating a touch display with an on-screen
menus.
For apps that means a navigation assistant comes in handy. And again, that's when you've got to
select from available packages.
Tom Tom, Navigon, Falk, just to name a few…

34. A navigation assistant should enable your users to find their ways without making them think. So on
one hand, it should be using common patterns and on the other hand be flexible enough to handle
different tasks.
Having worked with mostly “conservative” navigation systems before, I found it difficult to get used
to see navigation as a means of stacking cards. And I was often asking myself: “I just want to go
there or there, how hard can it be?”.
Stacking cards

35. Choosing the right solution
We chose the manufacturer's own and most modern system which to us seemed to be reasonable
(Navigation Experimental). It aimed to replace the existing navigation options that needed to be
developed because with iOS and Android on React Native's roadmap, neither of the existing ones
were really sufficient.

36. Sadly, time should prove us wrong and they discontinued the model. ;-(
So before the first delivery we had to throw that out, search for a new one and finally rewire
everything. Tedious.
Yet now, while working quite reliably, we're facing other issues. We'll see that when we come to
optimizations.

37. A word of caution
Avoid navigation that is unusual and/or unintuitive. While e.g. gestures are appealing, they can get in
the way and have to be learned.
All cars do the same thing in essence, but not all manufacturers provide their customers with an
intuitive to use interface.

38. Telemetry and trip recording

40. Despite the fact that we send and store telemetry data on a server for safety, we had to set up
something that keeps at least some data locally on the client-side.
That's why we added Redux for that matter.

41. Never trust your data when test-driving!
When working with local data the car most of the time seemed to work as intended. Until the
moment another technician took over the work, flushed persisted data, tried to re-start the engine
and – nothing but a red screen full of error messages.
So, check and clear your local telemetry data often!

42. Trip recording
You cannot have people who're going to use your cars for their own purpose drive without a proper
trip recorder. You want to be able to store records of their driving activities to find out about
problems. You want to know which features they use, how and how often they use them.
We added a tracking system - Fabric - to the car's internals, which let us track events and crashes.

43. Updates and backwards compatibility

44. When people download your app it's more like their signing a leasing contract rather than buying it -
depending on your business case. Normally they would exchange their car for a new model every
once in awhile. A new car would mean a new app version. But unlike in the automotive scenario they
could choose to keep their initial model (out of laziness, technical issues or because you didn't
communicate the benefits).
But you don't want people to run into problems because they don't use a newer version of your car!

45. With React Native you have a means to work around some of the issues of outdated versions when
you use Microsoft's CodePush. Unlike with car where it is necessary to make an appointment with
your car dealer to have you onboard-software or affected parts updated*, we could deliver updates
directly.
But soon as we started to add more features affecting the native codebase and/or the
underlying data structure we realized that we would break existing versions.

46. Some of the changes we could've covered in code, but who wants to maintain a wire harness that's
becoming more and more complicated? I for myself am no car electrician.
So we made it a rule that when e.g. data models change, we create a new API version and target this
version in the app using a simple version hint added to all requests.
My colleague Lee is going to tell you about that in his talk.

47. Optimization

48. In the car world there's a lot going on keeping engines that depend on fossil fuels alive. Most
methods target the engine itself, as there's still room for improvement.
For example:
● Start-stop system
● cylinder cut-off
● down-sizing
● Reducing friction
Keeping the motor running

49. Similar things can - and sometimes should - be done in an app. In React and React Native you have a
handful of methods dealing with the lifecycle of the app.
And that's where great potential for optimization can be found. What you want to do is reduce
re-renders and rendering* in general.
We looked into navigation earlier. Turns out that we have to put a lot of attention into the navigation
as it affects rendering a lot more than expected and causes memory usage going up.

50. User experience

51. Collecting feedback, managing user's expectations and finding out about their needs is crucial to
success. At the same time, users can distract you from getting things done and make you lose focus.
Ask 10 people what features they want in a car. You might get 10 different answers. And probably
they're telling you what they want - which is not at all times what they need.

52. In that same field personas come into play. For me it does not help to have personas for
decision-making as they are are only made up. A stupid example:
● Persona Georg: 52 years old, company owner, on the road a lot, wants comfortable seats
You might think, oh that persona wants comfortable seats, so you might be tempted to add heating,
memory function and a massage feature. But is this what they need? Isn't it rather an ergonomically
designed seat that's optimized to adapt to climate conditions?

53. Finding out need vs. want is really hard, but worth the effort.
You need to take both quantitative as qualitative analysis of user data into account.

54. Summing it up

55. Even today I sometimes get the feeling that some things are way to complicated and feel like having
to work with this:

56. And there are many things we haven't even touched yet:
● Building and shipping
● Keeping both OSses on par
● Marketing
● etc.

57. But: it is relatively easy to get into app development with React Native even if you might hit a dead
end sometimes. Yes it takes a lot of either passion or determination to get through, yet:
You'll be proud seeing others drive a car that you have built!

58. Thanks for your attention
and have a smooth ride!

59. Jan Wessel for kartenmacherei