Mobile Product Engineering Arnav Gupta 

Disclaimer: Personal Bias Past experiences which form my opinion ● 1.5 yrs : Platform Team Lead & Mobile Engineering Lead @ Zomato ● 1.5 yrs : Lead Engineer (Android) @ Target ● 10+ years mostly native Android Advice most suited to ● Scaleups / Large tech teams ● Ecom, B2C, large DAU (1M+) products 

Outline Engineering Org Design Process Testability* 

Engineering ‘scale’ is different modularisation 3rd party libraries navigation, deeplinks, state 

‘scale’ is different ● device, OS, version fragmentation ● low bandwidth, low storage size, low RAM devices ○ content consumption apps: frequent customer complaints = data usage ○ in a competitive field: app size ∝ uninstall rate ● txns/day or API hits per sec are STILL important; why ? ○ good caching on frontend, helps backend teams ○ lots of ‘scale’ mitigation happens on frontend (eg: exponential backoff) ○ frontend can DDoS backend 

modularisation 

3rd party libraries ● 1 line of code you don’t own = 1 line of risk you undertake ● even the biggies can fail you ○ Google Maps SDK bug: 20M+ users, 96% of top 1000 apps affected ○ Facebook Login SDK bug: 10M+ users, 80% of top 1000 apps affected ● include prebuilt vs add as source ○ build-time hit vs ability to self-fix ○ security considerations ○ CI able to pull 3rd party libs 

deeplinks, navigation, state ● the closer your navigation graph is to a pure state machine the better you’ll sleep at night ● deeplinks should be idempotent, like GET requests, and just work™ zoma.to/r/135 https://zomato.com/restaurants/ncr/gulati zoma.to/u/34 fb://user/arnav https://facebook.com/@arnav 

deeplinks, navigation, state 

Org Design to QA or not to QA pod-wise teams platform team? 

to QA or not to QA “ We can solve any problem by introducing an extra level of indirection ” - David J Wheeler to Butler Lampson 

to QA or not to QA “ We can solve any problem by introducing an extra level of indirection… … except the problem of too many levels of indirection ” 

to QA or not to QA ● PMs do have ability to toggle flags on DB, install apps, capture logs ● PMs will do “strategy”, cannot spend time on run-of-the-mill testing and operational tasks ● Engineers do not test thoroughly, we need a QA to be bulletproof ● Testing features need co-ordinating between frontend + mobile + backend engineers, QA can coordinate with all of them better ● We have compliance reasons ● Why do other companies have QA teams then? 

pod-wise teams start when > 5 team size OK if 1 pod = 1 person 1 pod owns 2 modules ✅ 2 pods work on 1 module ❌ split pods per business domain ✅ split pods per tech function ❌ 

platform team ? do you need one? platform teams clean up after feature pods ❌ platform teams built libs that feature teams use ✅ platform teams are responsible for reliability/performance ❌ platform teams create tools + monitoring for better app perf ✅ platform teams do releases ❌ platform teams own CI/CD infra ✅ 

Process trunk-based development release train build versioning 1 ticket = 1 branch = 1 build = 1 signoff 

trunk-based development & release train 

trunk-based development & release train 

trunk-based development & release train 

build versioning ● what is the APK version of the following apps you use on your phone ? ○ Google Maps ○ Google Pay / PhonePe / PayTM ○ Swiggy / Zomato ● product features ↔ version number pairing not needed ● 2022.12 (week num), or 2022.5.1-5472 (YMD+buildnum) ● v10 of Android = v10 of iOS has same features - why ? ● control feature rollout via ○ server side feature flags ○ API headers 

1 ticket = 1 branch = 1 build = 1 signoff ● 1 short-lived branch created for 1 JIRA ticket ○ scope your work so that this is < 1 week of work ● Use Firebase Test Labs + Test Flight for CD-to-employees ● PM/Design/Business should be able to “install a ticket id” ● Single place to for all stakeholders to - ○ get build for the ticket ○ discuss design / specs / requirements ○ sign off on release 

Testability unit test vs integration test snapshot tests? debug drawer & feature flags enabling manual testing 

unit tests vs integration tests ● tooling, difficulty and build time of integration tests ● what are you testing ? ○ input/output of function? ○ business logic? ○ state machine? ● mocking vs faking ○ can we test by hitting real APIs ? 

snapshot testing do you need it ? fragility & flakiness keeping up with design iteration speed accessibility tests 

debug drawer & feature flags ● API server domain switching ● A/B test (assuming test/control group) ● Assume user id ● Feature flag local overrides ● Dev Tool enable/disable ○ profiling ○ mem-leak catching ○ event / logs / trace capturing 

enabling manual testing 

enabling manual testing 

good reads 

blogs developer.squareup.com eng.uber.com/category/articles/mobile slack.engineering zomato.com/blog/category/technology blog.hotstar.com/tagged/engineering