Mobile Development in C++

Almost every tech company out there eventually find themselves searching for ways to reduce the overhead of implementing the same digital product multiple times, and with us it was not different. After launching a whole new product using Reactive Native, we started looking at options for our main application, iAuditor, available on iOS and Android.

It is been around one year since we started using C++ as our technology of choice to support a shared implementation across our iOS and Android applications.

This became a hot topic again recently, when Dropbox published this article on their Engineering Blog. While the road up to this point has been full of bumps and learnings, we are still adopting C++ on most of our mobile applications codebase, and today I wanted to share with you all some key points on how we are aiming to make it successful on the long run.

Transcript

1. Eduardo Lino SafetyCulture Mobile Development in C++
2. 2 Why? Build once, use everywhere Consistent style and architecture Improve code quality and test coverage Speed up development Keep the native UX
3. Let's talk about... 3 • How the application architecture looks like • What is our day-to-day workflow • How it impacted us • What is next
4. 4 iOS Android C++ Backend Where is the C++?
5. 5 Tools To make our life easier gRPC and Protocol Buffers RocksDB Djinni C++ v17
6. 6 gRPC + Protobufs API schema definition Network client code generation
7. Protobuf definition 7 message Question { string title = 1; int32 id = 2; // Unique ID number for this question. string body = 3; } message Survey { repeated Question questions = 1; } https://developers.google.com/protocol-buffers/docs/gotutorial
8. 8 RocksDB Local storage Persistent key-value store
9. 9 Djinni A tool for generating cross-language type declarations and interface bindings Generates parallel C++, Java and Objective-C type definitions from a single interface description file.
10. Djinni definition 10 question = record { id: string; title: string; order: i32; } survey = record { id: string; name: string; questions: list<question>; } survey_provider = interface +c { static create(): survey_provider; get_survey(id: i32): survey; save_survey(survey: survey); } https://github.com/dropbox/djinni Models Question.java Question.h Question.m question.hpp question.cpp Survey.java Survey.h Survey.m survey.hpp survey.cpp Interfaces SurveyProvider.java SurveyProvider.h survey_provider.hpp run ./djinni.sh
11. How we've put it together 11
12. 12 build once, use everywhere? Have we been able to Not everything should be in C++, and that's ok. It's key to define what should be in there and, most importantly, what should not. Sort of.
13. 13 development velocity? Have we increased Slow feedback cycles on every change C++ learning curve Not yet.
14. 14 consistent style and architecture? Have we achieved Protobuf and Djinni Schema Static analysis Network and Storage heavy lifting done once Yes.
15. 15 quality and test coverage? Have we improved Yes.
16. 16 native user experience? Have we kept the same Having a consistent local cache Optimistic UI Yes, and better.
17. 17 What's next More boilerplate code generation Clear separation of concerns Reusable by other internal products How can we make it better?
18. 18 Thank you!