# Using EntryProviderScope for Scalable Structure in Navigation 3 Preventing navigation complexity as applications grow. - **Source:** [ProAndroidDev - Medium](https://brifing.si/source/d9553fa9-7b72-4b9b-bc73-c6bf9a40dd5f) - **Published:** 2026-07-24 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/c39fc194-4ae6-41e8-9228-09add838ae08 ## Simple Start for Small Projects Registering all screens directly in entryProvider makes sense for small apps in Navigation 3. All routes are visible in one place, and adding new screens is straightforward. However, this approach becomes unsustainable as the application grows. ## Problems of Scaling As features multiply, entryProvider can grow to hundreds of lines. Understanding which screens belong to which feature becomes difficult. Multiple developers modifying the same file increases merge conflict risks. ## Solution: EntryProviderScope Group related screens using EntryProviderScope extension functions. For example, keeping login and signup screens together within authFeature() makes the navigation structure modular. ## Leveraging Kotlin's Power Navigation 3 uses Kotlin functions as organizational units rather than adding a new API layer. This allows navigation code to be refactored using standard Kotlin tooling. ## Alignment with Compose Philosophy Navigation 3 adopts Compose's philosophy of building UIs with small reusable functions. By composing features rather than screens, you achieve a cleaner architecture. ## Simplified Root Navigation When features are grouped, the app's root navigation file shrinks dramatically. Instead of individual screens, you now compose high-level features like authFeature() and settingsFeature(). ## Advantage in Modular Apps This approach works perfectly with feature modules. Each module can contain its own screens and navigation definitions. The main module simply combines features without knowing details. ## Importance of Architectural Decisions Thinking in features rather than screens with Navigation 3 contains complexity where it belongs (in feature modules) as the app grows. The root navigation remains stable. ## Future-Proof Navigation Navigation structures built with EntryProviderScale scale effortlessly as your application grows. When new screens are added, you only need to update the relevant feature module. ## Sources covering this story - https://proandroiddev.com/navigation-3-keep-entryprovider-from-becoming-a-giant-switchboard-ffaafc720156?source=rss----c72404660798---4 — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._