Ahmed El-Helw - Abdulahi Osoble without a Monorepo Scaling Android Development HudHud Maps - Careem Technologies 

This Talk is Not Monorepo vs non-Monorepo 

Starting Point Sharing Libraries 

No content

Merging 2 Apps 

No content

“MiniApps” are just Groupings of Features 

No content

No content

Container (App Shell) * Lives in its own repository * “Cont a ins” (depends on) a ll the fe a tures a nd deleg a tes to them * Outputs the f in a l a pk th a t goes to the Pl a y Store 

Architectural Principles 

* No fe a ture directly depends on a nother * Fe a tures a re option a l (T&Cs a pply) * Aim tow a rds not h a ving n di ff erent w a ys of doing things 

inte rf ace Feat ur eFacto ry { fu n p r ovideFeat u r e(dependenciesP r ovide r : DependenciesP r ovide r ): Feat ur e } inte rf ace Feat ur e { // .. . } 

inte rf ace Feat ur eFacto ry { fu n p r ovideFeat u r e(dependenciesP r ovide r : DependenciesP r ovide r ): Feat ur e } inte rf ace Feat ur e { // .. . } 

inte rf ace DependenciesP r ovide r { fu n ana ly tics(): Ana ly ticsP r ovide r fu n expe r iments(): Expe r iments fu n l ocationDependencies(): LocationDependencies fu n netwo rk ingDependencies(): Netwo r k ingDependencies } 

No content

Dependencies • Cont a iner implements DependenciesP r ovide r • Fe a ture doesn't need to know the concrete type • We c a n ch a nge det a ils without fe a tures needing to m a ke a ny ch a nges a s long a s the API is consistent 

No content

No content

No content

Dependencies Provider * it’s a n interf a ce, so we c a n h a ve fun with individu a l dependencies * Wr a p it * No-op it * Repl a ce it 

Navigating with Deep Links 

scheme: / / / 

inte rf ace DeepLin k Reso l ve r { f u n r eso l ve( ur i: St r ing): Intent? } 

inte rf ace Feat ur e { f u n deepLin k Reso l ve r (): DeepLin k Reso l ve r ? = n ul l } 

fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) } 

fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) } 

fu n r eso l veDeepLin k ( ur i: St r ing): Intent? { va l host = u r i.pa r seHost() va l f eat ur e = feat ur es.getO r Defa ul t(host, n ul l ) r et ur n f eat u r e ?. deepLin k Reso l ve r () ? .r eso l ve( u r i) } 

Registration 

va l feat u r eFacto r ies = mapOf( " r ides" to RidesFacto ry (), " f ood" to FoodFacto ry () ) 

imp l ementation( l ibs. f eat ur e. r ides) imp l ementation( l ibs. f eat ur e.food) 

/ / imp l ementation( l ibs. f eat ur e. r ides) imp l ementation( l ibs. f eat ur e.food) 

Push Noti f ications • Received by the cont a iner a nd deleg a ted, b a sed on a f ield, to the proper fe a ture 

How do teams develop? 

No content

No content

Librarisize the Container 

No content

CI/CD 

Sharing steps 

Common checks 

Dependency Diff c a reem/dependency-di ff -tldr 

Size Delta J a keWh a rton/di ff use 

No content

Manifest Diff 

Source Compatibility ch a nges to... 

Source Compatibility ch a nges to... 

Binary Compatibility 

No content

No content

No content

Run It 

No content

No content

No content

No content

No content

No content

No content

No content

Binary Compatibility • Gr a dle will compile e a ch module a g a inst the st a ted version • For p a ck a ging a nd runtime, Gr a dle picks the "newest" version 

Tooling can Help for our Libs • https://github.com/Kotlin/bin a ry-comp a tibility-v a lid a tor • https://github.com/tylerbwong/met a l a v a -gr a dle 

Dependency Ownership • Pl a tform Dependencies • Fe a ture speci f ic Dependencies 

Dependency Alignment • Publish BOM or Version c a t a log • Centr a lizing control of BOM/Version c a t a log a t a pl a tform level • Pl a tform dependencies only 

Challenges • More di ff icult to m a ke ch a nges a cross a ll a pps • Deprec a tions a re tricky to m a ke • Extr a cting st a nd a lone SDKs is tricky 

Thank You 

for some smaller teams having devx is a distant dream but they can continue to scale until their codebase is as big as a whale ignoring the monorepo reviews multiple repos they will use one main repository controls the release version bump PRs will certainly increase since every team builds on their own tests and makes sure it works on their phone uploads their new version to internal maven the ability to rollback makes it a haven tooling comes into play helping to fi nd bugs and slay detect hidden changes before they break catch them early before the mistake di ff erences in size of apks dependency di ff s across the days a central team controls dependencies setting the version and avoiding redundancies let's not forget compatibility too binary and source to name a few using the tools and being aware helps save us from lots of despair unfortunately, that is all the time allotted for this summary rhyme written with 0% GPT now go enjoy sessions and co ff ee 

Scaling with Kotlin Multiplatform • Te a ms h a ve their own KMP dependencies • Choice between n a mesp a ce cl a shing a nd "KMP" per fr a mework t a x on iOS • Bridges h a ve to be repe a ted, since types a re a ll slightly di ff erent