YAGNI in App Development: What It Is, the Principle's Essence, and Practical Benefits

What Is YAGNI?

YAGNI (You Aren't Gonna Need It) — an extreme programming (XP) principle meaning “you aren't gonna need it.” The rule states: never implement functionality that is not required by current user stories. If a feature isn't needed today — don't build it, even “just in case”.

The term was coined by Ron Jeffries, one of the co-authors of the XP methodology (with Kent Beck). Jeffries stated: “Implement the simplest thing that works, and don't add anything until it's needed.” YAGNI is not a prohibition on planning, but a prohibition on premature implementation.

According to the Standish Group CHAOS Report (2023), 64% of features in an average software product are rarely or never used. Extrapolating to a mobile app — more than half of the written code doesn't bring value to the user. YAGNI prevents this waste of resources.

Apply YAGNI as a strict filter: every feature must answer the question “what specific user problem does it solve right now?” If there's no answer — the feature isn't needed.

YAGNI vs Laziness and Cutting Corners

YAGNI is not a rejection of quality architecture. YAGNI forbids writing unnecessary code, but doesn't forbid writing correct code. If a current feature needs a clean abstraction layer — create it. If the layer isn't needed — don't create it. Key difference: YAGNI is about functionality, not about quality.

Developers often confuse YAGNI with intentional accumulation of technical debt (technical debt is always a compromise, YAGNI is a principle of efficiency). The difference is that technical debt is acknowledged and documented, while YAGNI violation is simply extra work.

Ask yourself: “If I don't create this abstraction now, how long would refactoring take when it's needed?” If refactoring time is less than writing time now — postpone it.

Why Is YAGNI Critical for Mobile Projects?

Mobile development is especially sensitive to YAGNI violations for three reasons: APK/IPA size directly affects installation conversion rate, compilation time of mobile projects grows linearly with code volume, and every extra feature adds points of failure. YAGNI is not about laziness, but about focus.

A study by Google Play Console Data (2023) showed: every 10 MB of APK size reduces installation probability by 1.2%. Unused code is not just clutter in the repository — it's direct financial loss. Extra libraries (for functionality that “maybe we'll add later”) are the most common source of APK bloat.

According to the Gradle Build Performance Report (2024), each additional module in an Android project increases full build time by 3–7 seconds. If you add 5 modules “just in case” — the build time increase will be 15–35 seconds per build. Over a year, a team of 5 developers loses up to 200 person-hours waiting for compilation.

Monitor the binary size in CI: set a warning limit (e.g., +500 KB per commit). If the size grew without a new feature — it's a YAGNI violation that needs to be discussed at code review.

YAGNI vs Gold-Plating: Practical Examples

Gold-Plating: Premature Animation

Gold-plating — adding functionality beyond requirements in an attempt to “improve” the product. A typical example: a developer adds complex transition animation between screens, although the design specifies a simple fade. The animation takes 2 days, the user doesn't notice it, and bugs on different devices haunt the project for years.

According to the UX Collective Annual Report (2023), 78% of users judge an app by speed and stability, not by animations. YAGNI says: if the animation isn't specified in the requirements — don't implement it. The designer will add animation when it's actually needed to solve a UX problem.

Implement only what's in the mockups. If the designer didn't draw an animation — it shouldn't exist. Any deviation from the mockup is a YAGNI violation.

Premature Localization into 20 Languages

A common startup mistake: immediately building support for 20+ languages “for future international market entry.” YAGNI recommends: localize only into the current market language. Adding each new language requires translator time, testing strings for truncation, and debugging RTL layouts.

According to the Deloitte Digital Globalization Survey (2022), 60% of mobile apps never expand beyond their first market. If that's your case — resources spent on multilingual support are wasted. YAGNI approach: English (base) + target market language. Others — as you actually enter a region.

Use YAGNI for prioritization: if a feature isn't in the roadmap for the next two quarters — don't start it. The roadmap must be documented and approved by the product manager.

How to Apply YAGNI in Android and iOS?

YAGNI in Android: Don't Add Unnecessary Libraries

Android projects suffer from library inflation. Developers add Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — even before the first line of business logic is written. YAGNI recommends: add libraries as actually needed, not preventively.

// YAGNI violation: preventive inclusion of libraries
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// And the app just shows "Hello World"

Libraries are dependencies with their own complexity. Each requires version updates, migration on breaking changes, and increases APK size. Add a library when a specific task arises that this library solves. Start with OkHttp (minimal HTTP client), add Retrofit when you need a REST client, and so on.

YAGNI in iOS: Don't Force SwiftUI

SwiftUI is a powerful framework, but its adoption should be driven by real needs. If a project starts with iOS 14+ and requirements for custom UI components are minimal — SwiftUI is a good choice. If a project must support iOS 13 or requires complex custom gestures — UIKit remains the right solution. YAGNI is against migrating to SwiftUI “because it's trendy.”

// YAGNI: use UIKit as long as there's no real benefit from SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profile"
    }
}

// If SwiftUI is needed — integrate via UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Analysis by Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) recommends: don't migrate existing UIKit screens to SwiftUI without a clear business reason (e.g., need for Live Preview for the designer). Rewriting working code is a direct YAGNI violation. SwiftUI — for new screens, UIKit — for existing ones.

Typical Mistakes When Following YAGNI

YAGNI as an Excuse for Poor Architecture

The most dangerous mistake is using YAGNI as an excuse for poor architecture. “We won't create a repository layer because YAGNI — we'll write the query directly in the ViewModel.” This isn't YAGNI, it's accumulating technical debt. YAGNI forbids unnecessary functionality, not architectural integrity.

Architecture is an investment in maintainability. If you're writing more than 3 screens — a basic architectural layer (MVVM, repository) is already justified. If it's 1 screen — you can afford a simpler approach. The key: determine the architectural minimum needed for current features, and don't add more.

Separate decisions into “architectural” and “functional.” Architectural decisions (layers, navigation, DI) are not covered by YAGNI — they're needed for maintainability. Functional decisions (features, screenshots, animations) — are covered.

Blindly Following YAGNI When Working with APIs

Another extreme — ignoring future API contracts. A developer receives a JSON from the backend with 5 fields and parses only 3, because “the rest aren't needed according to YAGNI.” The problem: when a field is added, the backend might break parsing if the response changed. The solution is to map all response fields, even if not all are used now.

According to Meta API Design Guidelines (2023), the client must parse all fields returned by the server, ignoring unused ones, but not discarding the entire structure. YAGNI here is about something else: don't add handling of fields that aren't yet in the specification “just in case the backend returns them.”

Parse the entire response structure (all fields the server currently returns). Don't add handling of fields that aren't in the current API specification. This is a balance between YAGNI and resilience to change.