Android Kotlin Development
Features are the visible layer of an Android app. Security, accessibility and resilience are the production layer that determines whether it survives in the hands of real users.
An Android Kotlin app that implements every feature on the product roadmap but transmits sensitive data without certificate pinning, fails TalkBack traversal on the first interactive screen, crashes silently when the network returns an unexpected error shape, and ships with debug logging enabled in the production build has not met the production standard. It has met the demo standard. The gap between the two is not visible in a sprint review on a development device connected to a staging backend. It becomes visible in a Play Store security audit, an enterprise procurement accessibility questionnaire, a production crash report from a device configuration the development team did not test, and a Google Play policy review triggered by an incorrectly declared data safety form. NextEnvision applies the full production standard to every Android Kotlin development engagement for businesses and agencies in Australia, the United Kingdom and Singapore. Features and non-functional requirements, delivered together, from sprint one.
What Production-Grade Android Kotlin Development Covers Beyond Feature Delivery
Production-grade Android Kotlin development treats five categories of non-functional requirement as first-class engineering obligations alongside the feature work that appears in the sprint backlog. Security is the first. An Android Kotlin application that handles user credentials, financial data, health records or enterprise authentication must implement certificate pinning using OkHttp’s CertificatePinner to prevent man-in-the-middle attacks on API communication, store sensitive data in the Android Keystore rather than SharedPreferences, apply ProGuard or R8 code shrinking and obfuscation to the production APK to prevent reverse engineering of business logic, and pass the Play Integrity API check before allowing sensitive operations on devices with compromised system integrity. Accessibility is the second. An Android Kotlin application deployed in Australia or the UK for a public-sector, healthcare or enterprise audience is frequently required to meet WCAG 2.1 AA accessibility standards by contract. This requires content descriptions on every non-text Compose element using the semantics modifier, correct TalkBack traversal order through the Compose semantic tree, minimum touch target sizes of 48dp, colour contrast ratios of 4.5:1 for normal text and 3:1 for large text and UI components, and correct dynamic text size scaling using Sp units rather than Dp for text sizing throughout the composable hierarchy. Resilience is the third. A production Android Kotlin application handles network errors, API error responses, offline states and unexpected data shapes with explicit Kotlin error types that surface correct UI state rather than crashing silently. Observability is the fourth. A production Android Kotlin application has structured logging through Timber with release trees that route logs to Crashlytics rather than logcat, Firebase Performance custom traces on the operations the product team needs to monitor, and a Crashlytics configuration that captures the custom keys and user identifiers that make crash reports actionable rather than anonymous stack traces. Code quality is the fifth. A production Android Kotlin application has Detekt static analysis configured in the CI pipeline with Kotlin-specific rules enforced on every pull request, a documented code style guide applied consistently across every module, and module-level package structure that enforces the Clean Architecture dependency rules without relying on developer discipline alone.
Android Kotlin Development Services by Production Quality Requirement
Six Android Kotlin development services targeting the non-functional requirements that separate production-grade applications from feature-complete prototypes.
Android Kotlin Development with Security Engineering
Security engineering in Android Kotlin development covers the full OWASP Mobile Security Testing Guide requirement set for the application category. Certificate pinning is implemented using OkHttp’s CertificatePinner with the SHA-256 fingerprints of the backend certificate chain, with a backup pin included to prevent a certificate rotation from making the application unable to communicate with the backend. Sensitive data stored on the device uses Android Keystore-backed encryption with hardware-bound keys on devices that support the StrongBox hardware security module. The production build configuration enables R8 full mode with obfuscation rules that protect business logic classes while preserving the reflection access that Retrofit, Room and Hilt require. Play Integrity API attestation is implemented for applications where the server must verify that the client is the genuine, unmodified Android Kotlin application running on a non-rooted device before processing sensitive operations. Root and emulator detection provides a secondary signal for applications that cannot rely on Play Integrity API attestation alone.
Android Kotlin Development with WCAG 2.1 Accessibility
WCAG 2.1 AA accessibility implementation in Android Kotlin development covers the Compose semantic tree, touch target sizing and colour contrast requirements that accessibility audits test. Every non-decorative Compose element that conveys information receives a semantics modifier with a contentDescription that describes the element’s purpose to TalkBack users in terms of what the element does rather than what it looks like. The semantic tree traversal order is explicitly set where the default Compose traversal order does not match the logical reading order of the screen. Interactive elements enforce a minimum touch target of 48dp using the minimumInteractiveComponentSize modifier from the Material Design 3 library. Text uses Sp units throughout the composable hierarchy so that user-set system font scale preferences are respected without layout overflow. Colour contrast is verified at the design stage using the WCAG contrast ratio formula and confirmed in device testing with the accessibility scanner. Switch access and keyboard navigation are tested on physical Android devices with accessibility services enabled, not only in the Compose preview.
Android Kotlin Development with Hilt Dependency Injection
Hilt dependency injection architecture in Android Kotlin development replaces manual dependency wiring and service locators with compile-time verified dependency graphs that make every module testable in isolation. The Hilt component hierarchy maps to the Android lifecycle hierarchy: SingletonComponent for dependencies that live for the application lifetime, ActivityRetainedComponent for dependencies that survive configuration changes but are scoped to an activity, ActivityComponent for dependencies that are destroyed with the activity, and ViewModelComponent for dependencies that are scoped to a ViewModel lifecycle. Repository and data source implementations are provided as interface bindings using @Binds, which allows the test environment to substitute a fake implementation without modifying the production module. The Hilt module structure is documented at the engagement start so that every developer on the team understands which scope a new dependency should be provided at and why, rather than defaulting to Singleton scope for every injection regardless of the appropriate lifecycle.
Android Kotlin Development with Error Handling and Resilience
Error handling and resilience engineering in Android Kotlin development replaces unhandled exceptions and generic error messages with a typed error model that produces correct UI state for every failure category the application can encounter. The Kotlin Result type wraps repository return values so that the presentation layer receives either a success with the domain object or a failure with a typed error that the ViewModel maps to the correct sealed class UiState variant. Network errors are categorised at the data layer boundary: a timeout produces a different UiState than a 401 Unauthorized response, which produces a different UiState than a 500 Internal Server Error. Retry logic uses exponential backoff with jitter for transient network failures, implemented using Kotlin’s retryWhen Flow operator with a configurable maximum retry count and delay ceiling. Offline-first data access queues writes when connectivity is absent and synchronises when it is restored, using WorkManager constraints to ensure synchronisation only occurs when the device has network access and the application is not under battery optimisation constraints.
Android Kotlin Development Code Quality and Standards
Code quality standards in Android Kotlin development are enforced through static analysis rather than code review alone. Detekt is configured in the Gradle build with a custom rule set covering Kotlin-specific quality rules: maximum function complexity thresholds that identify functions that should be decomposed, magic number detection that flags hardcoded values that should be named constants or ThemeData tokens, forbidden import rules that prevent cross-module dependency violations from bypassing the Clean Architecture layer boundaries, and Compose-specific rules from the compose-rules Detekt plugin that enforce parameter stability and composable function naming conventions. The Detekt task runs in CI on every pull request and fails the build on any new violation introduced by the pull request, preventing quality debt from accumulating across the sprint history. The Kotlin official code style is applied through the .editorconfig file shared across the team, with the Android Studio Kotlin formatter configured to apply the same rules on save so that formatting differences never appear in pull request diffs.
Android Kotlin Development Library Evaluation and Integration
Third-party library selection in Android Kotlin development has long-term maintenance consequences that affect every developer who works on the codebase after the initial integration. We evaluate every candidate library against five criteria: active maintenance with a recent release within the past six months, Kotlin Multiplatform compatibility where the application has KMM requirements, Kotlin coroutine support rather than RxJava or callback-based async interfaces that introduce style inconsistency with the rest of the Kotlin codebase, a current stable release without known security vulnerabilities in the NIST National Vulnerability Database, and a compatible Apache 2.0 or MIT licence without restrictions on commercial use or distribution. Libraries that fail any of these criteria are either rejected in favour of alternatives or accepted with a documented risk acknowledgement and a migration plan for the exit path if the library becomes unmaintained or compromised.
The Production Android Kotlin Development Library Stack
Production Android Kotlin development builds on a set of actively maintained, Kotlin-native libraries that cover the common application requirements that the Android SDK and Jetpack libraries do not address directly. For network communication, Retrofit 2 with the Kotlin Coroutines adapter provides a type-safe HTTP client whose interface declarations match the backend API contract with compile-time verification, or Ktor client for applications that need multiplatform network code that runs identically in the Android JVM and Kotlin/Native iOS targets. OkHttp underlies both and provides the HTTP interceptor layer where certificate pinning, request logging and authentication header injection are implemented. For image loading and caching, Coil is the Kotlin-native choice over the older Java-based Glide and Picasso libraries: Coil uses Kotlin coroutines for async loading, integrates with Compose through the AsyncImage composable, and has a composable request builder API that matches the Kotlin development style of the surrounding codebase. For structured logging, Timber provides a tree-based logging architecture where debug builds plant a DebugTree that writes to Android Logcat and release builds plant a CrashlyticsTree that routes warning and error logs to Firebase Crashlytics as non-fatal issues, providing context for crash investigations without exposing log output in production builds. For JSON serialisation, Kotlin Serialization provides a compile-time safe serialiser that generates serialisation code at compile time rather than using reflection at runtime, which is compatible with R8 full mode without requiring keep rules for data class properties. For dependency analysis and leak detection in debug builds, LeakCanary 2 is added to the debug build variant only, providing automatic heap dump analysis that surfaces memory leaks as structured reports in the Logcat output during development without adding any overhead to the production build.
Four Production Quality Pillars in Android Kotlin Development
Mobile Security Engineering
WCAG 2.1 Accessibility Compliance
Android Kotlin development security engineering addresses the OWASP Mobile Top 10 vulnerability categories that affect the application category and data sensitivity. Certificate pinning prevents API communication from being intercepted by a proxy on a compromised network. Android Keystore encryption prevents sensitive data stored on the device from being accessed if the device is rooted or the application package is extracted. R8 code obfuscation prevents reverse engineering of business logic and API endpoint strings from the production APK. Play Integrity API attestation prevents API access from modified versions of the application. The security requirements are documented in the Architecture Decision Record at the start of the engagement, reviewed against the application’s data sensitivity classification, and implemented in the first sprint rather than added as a pre-launch checklist item in the final sprint.
Error Handling and Resilience Patterns
WCAG 2.1 AA accessibility in Android Kotlin development is verified at three stages. At the design stage, the Figma design is checked for colour contrast ratios and touch target sizes before any Compose composable is written. During development, every composable that adds to the semantic tree is reviewed for correct contentDescription values, traversal order and focus management. Before submission, TalkBack traversal is conducted on a real Android device using a screen reader script that covers every interactive element in every critical user flow, and the results are documented against the WCAG 2.1 success criteria that apply to the application. Accessibility violations found in this process are fixed before Play Store submission rather than deferred to a post-launch accessibility remediation engagement that costs more and affects real users in the interim.
Code Quality, Observability and Standards
Resilience engineering in Android Kotlin development designs the error handling architecture before the first data layer class is written. The domain layer error model defines the typed error categories the application must handle: network timeout, authentication failure, server error, validation error, data not found and permission denied are distinct error types that produce distinct UI states and distinct user-facing messages. The Kotlin Result type propagates these error types from the data layer through the domain use cases to the ViewModel without exposing raw exceptions. The ViewModel maps each typed error to the correct sealed class UiState variant so the Compose screen renders the correct UI for each failure: a retry button for transient network errors, a re-authentication prompt for expired sessions, a contact support option for server errors and an input correction prompt for validation failures.
Flutter Performance Engineering
Code quality and observability in Android Kotlin development are enforced through tooling rather than through good intentions. Detekt static analysis with Kotlin-specific rules and Compose-specific rules from the compose-rules plugin runs in CI on every pull request and fails the build on new violations. Timber structured logging with a CrashlyticsTree in production builds routes warning and error logs to Crashlytics non-fatal events, providing investigation context for crash reports beyond the stack trace. Firebase Performance custom traces measure the operations the product team needs to monitor: database query latency, image loading time and critical business operation duration. The Kotlin official code style enforced through .editorconfig and the Android Studio formatter means formatting is consistent across the entire codebase without requiring manual review of whitespace and import ordering in every pull request.
White Label Android Kotlin Development for Agencies
Digital agencies delivering Android Kotlin development to clients in Australia and the UK bear commercial and reputational responsibility for the production standard of the applications they deliver. An agency that commissions Android Kotlin development from a partner who delivers feature-complete but security-incomplete, accessibility-incomplete or resilience-incomplete applications is accountable to the client for every post-delivery deficiency, regardless of whether the deficiency was in the partner’s scope. Our white label Android Kotlin development applies the full production quality standard to every agency engagement: security engineering appropriate to the application data sensitivity, WCAG 2.1 AA accessibility compliance verified on real Android devices, typed error handling and resilience patterns throughout the data layer, Detekt code quality enforcement in CI and the structured library evaluation process that prevents unmaintained or insecure third-party packages from entering the production codebase.
The white label arrangement covers the complete Android Kotlin development engagement including production quality engineering, under your agency brand. Mutual NDA before any client brief or project file is shared. Google Play developer account, Kotlin source code, security documentation, accessibility compliance report and all submission materials belong to the agency or end client. Zero NextEnvision identifiers in any deliverable. AEST and GMT coverage for Australian and UK agency clients. Complete IP transfer on project completion. Post-delivery maintenance available through the agency at the agency’s rate with zero NextEnvision visibility to the end client.
Why Deferred Non-Functional Requirements Become Production Crises in Android Kotlin Development
The commercial case for applying non-functional requirements from sprint one in Android Kotlin development rather than deferring them to post-launch is not a quality argument. It is a cost argument. Every non-functional requirement that is not implemented during the initial Android Kotlin development engagement will be required at some point after launch, and implementing it after the fact costs significantly more than implementing it alongside the feature work it relates to. Certificate pinning implemented post-launch requires updating the OkHttp client configuration that is referenced across the network layer, updating the CI pipeline to include pin verification in the build, and releasing a Play Store update that users must install before the unprotected version is removed. The same work done during the initial Android Kotlin development engagement is a single architecture decision and its implementation in the first network layer sprint. WCAG 2.1 accessibility implemented post-launch requires auditing every composable in the codebase for missing semantics, restructuring traversal order in screens where the default Compose semantic tree does not match the logical reading order, and updating the design system to enforce the correct touch target sizes and colour contrast ratios that the original design did not specify. The same compliance implemented during the initial Android Kotlin development engagement is verified at the design stage before a composable is written. Error handling implemented post-launch requires refactoring the return types of every repository method from throwing exceptions to returning Kotlin Result types, updating every ViewModel that catches exceptions to handle the new result type, and adding the missing UiState variants that the incorrect error handling made impossible to represent. The same architecture implemented during initial Android Kotlin development is a data layer design decision made in the discovery phase. The pattern is consistent: non-functional requirements deferred from the development phase to post-launch are not avoided. They are paid for at a higher rate, under production pressure, by a team that now has to change code they did not write rather than write correct code from the start.
Android Kotlin Development Engagement Models by Starting Position
Greenfield Android Kotlin Development to Full Production Standard
Android Kotlin Development Audit Against Production Standard
A new Android Kotlin application built with full production quality requirements applied from sprint one. The discovery phase produces an Architecture Decision Record covering the security requirements appropriate to the application’s data sensitivity classification, the accessibility compliance target and the specific WCAG 2.1 success criteria that apply, the Hilt dependency injection module structure, the error handling architecture and the Detekt configuration for the project. The library evaluation is conducted before any third-party package is added to the Gradle version catalog. The production quality standard is built into the feature development process rather than added as a pre-launch checklist.
Security and Accessibility Compliance Remediation
An existing Android Kotlin application assessed against the full production quality standard. The audit covers security: certificate pinning posture, data storage practices, R8 obfuscation configuration, Play Integrity API status and known vulnerabilities in the third-party library dependency tree. Accessibility: composable semantic tree completeness, TalkBack traversal correctness, touch target compliance and colour contrast compliance. Error handling: return type analysis across the data layer, exception handling patterns in the domain and presentation layers and missing UiState variants for error categories the application currently cannot represent. Code quality: Detekt violation count, library currency and maintenance status. A written audit report with findings ranked by severity and effort-to-fix estimates is delivered before any remediation begins.
Android Kotlin Development Code Quality Overhaul
A targeted Android Kotlin development engagement that addresses a specific compliance requirement: a security audit finding from a penetration test or enterprise procurement review, a WCAG 2.1 accessibility remediation triggered by a government accessibility audit or an enterprise procurement accessibility questionnaire, or a Play Store security policy compliance requirement triggered by a Play Console policy notification. The remediation engagement begins with a scoped assessment of the specific compliance gap, produces a written remediation plan with effort estimates for each item and a proposed implementation order, and executes the remediation in a sequence that addresses the highest-severity items first without disrupting the production application throughout the engagement.
Flutter Maintenance and Support Retainer
An Android Kotlin development engagement focused specifically on bringing an existing codebase to the production code quality standard: Detekt static analysis configured and integrated into CI with all existing violations triaged and remediated in priority order, Timber structured logging implemented with a CrashlyticsTree release tree replacing raw Log calls throughout the codebase, Kotlin code style enforced through .editorconfig and formatter configuration applied consistently across the team, the third-party library dependency tree audited against the evaluation criteria and unmaintained or vulnerable libraries replaced with maintained alternatives. The code quality overhaul is executed incrementally with the production application remaining functional throughout, using feature flags and incremental deployment where the Detekt configuration changes affect build behaviour.
How Production Quality Is Applied Throughout Android Kotlin Development
Discovery: Security Classification and Quality Configuration
Data Layer: Security and Error Handling Architecture
The Android Kotlin development discovery phase documents the data sensitivity classification that determines the security requirements: an app handling financial credentials requires Play Integrity API and StrongBox-backed Keystore, an app handling health records requires PHIPA or NHS data sovereignty compliance, a consumer app with anonymous users requires a different security posture than an enterprise app with SSO authentication. Detekt is configured with the project-appropriate rule set. The WCAG 2.1 compliance target is documented. The library evaluation criteria are agreed. The error type taxonomy is defined before the first data layer class is written.
Compose UI: Accessibility from First Composable
The data layer is implemented with security and error handling architecture applied from the first repository class. OkHttp is configured with the CertificatePinner for the backend API domain. SharedPreferences are replaced with EncryptedSharedPreferences for any data that should not be readable in plaintext from the device storage. Repository methods return Kotlin Result types with the typed domain error model, never raw exceptions. The Retrofit service interface uses Kotlin coroutines suspend functions with a response wrapper that maps HTTP error codes to the typed error model before the result leaves the data layer.
CI Pipeline: Static Analysis and Quality Gates
Every Compose composable is written with accessibility applied from the first implementation: semantics modifiers on every non-decorative element, minimumInteractiveComponentSize on every interactive element, Sp units for text, and correct contentDescription values that describe what the element does rather than what it looks like. Composables are added to the shared Compose component library with accessibility requirements documented in the Kdoc, so that every screen assembled from the shared library inherits the correct accessibility implementation rather than reimplementing it inconsistently per screen.
Pre-Submission: Security and Accessibility Verification
The CI pipeline applies quality gates that prevent non-compliant code from reaching the main branch. Detekt static analysis runs on every pull request and fails the build on any new violation introduced by the pull request. Unit tests covering domain use cases and ViewModel state transitions run on every pull request with a coverage threshold enforced for the new code introduced. The R8 build configuration is verified to produce a correctly shrunken and obfuscated APK that passes the reflection requirements of Retrofit, Room and Hilt without requiring blanket keep rules that defeat the obfuscation. The CI pipeline output includes the Detekt report, the test coverage report and the R8 verification result in the pull request comment.
Post-Launch: Observability and Compliance Monitoring
Before Google Play submission, two formal verification sessions are conducted. The security verification proxies the production build’s API communication through a MITM proxy to confirm that certificate pinning is active and correctly configured for the production certificate chain. The accessibility verification runs TalkBack on a real Android device through a screen reader script covering every critical user flow, documents the semantic tree traversal against the WCAG 2.1 success criteria checklist and verifies colour contrast ratios at the device display level rather than in the design tool. Any findings from either verification session are remediated before submission proceeds.
From Flutter Architecture to App Store
After Google Play launch, the production quality programme continues through monitoring. Firebase Crashlytics crash-free rate and ANR rate are monitored weekly against the Android Vitals thresholds. Crashlytics non-fatal events routed through the Timber CrashlyticsTree are reviewed monthly for patterns that indicate error handling gaps not caught in pre-launch testing. The third-party library dependency tree is reviewed quarterly against the NIST National Vulnerability Database for newly discovered CVEs in libraries used in the production build. Google Play policy update notifications are reviewed as they are issued and the data safety form is updated when new data collection or sharing practices are introduced by feature development.
Android Kotlin Development: Production Quality FAQs
Questions about security, accessibility, dependency injection, error handling and library selection in production Android Kotlin development.
What security requirements should Android Kotlin development address?
Security requirements for Android Kotlin development depend on the application’s data sensitivity classification. Applications handling financial credentials, health records, enterprise authentication or payment data should implement certificate pinning using OkHttp’s CertificatePinner with the SHA-256 fingerprints of the production API certificate chain and a backup pin, to prevent API communication from being intercepted by a MITM proxy on a compromised network. Sensitive data stored on the device should use EncryptedSharedPreferences backed by Android Keystore rather than plain SharedPreferences. The production APK should enable R8 full mode with obfuscation rules that protect business logic class and method names from reverse engineering while preserving the reflection access that Retrofit, Room and Hilt require. Applications where the server must verify that the client is the genuine, unmodified application should implement the Play Integrity API attestation flow. Applications handling financial or healthcare data should also be assessed against the OWASP Mobile Security Testing Guide for the relevant mobile application security verification level.
How is WCAG 2.1 accessibility implemented in Android Kotlin development?
WCAG 2.1 AA accessibility in Android Kotlin development is applied at three stages. At the design stage, Figma designs are checked for colour contrast ratios meeting the 4.5:1 minimum for normal text and 3:1 for large text and UI components, and interactive elements are sized to the 48dp minimum touch target before any Compose composable is written. During development, every non-decorative Compose element receives a semantics modifier with a contentDescription that describes what the element does to a TalkBack user rather than what it looks like. Text uses Sp units throughout the composable hierarchy so system font scale preferences are respected. The minimumInteractiveComponentSize modifier is applied to every interactive element. Semantic tree traversal order is explicitly set where the default Compose traversal order does not match the logical reading order. Before submission, TalkBack traversal is conducted on a real Android device with a screen reader script covering every critical user flow, and the results are documented against the applicable WCAG 2.1 success criteria. Accessibility violations found in this verification are remediated before Play Store submission.
How does Hilt dependency injection work in Android Kotlin development?
Hilt provides compile-time verified dependency injection for Android Kotlin development by generating the dependency graph at build time rather than resolving it at runtime. The component hierarchy maps to the Android lifecycle: SingletonComponent for dependencies that live for the application lifetime such as the Retrofit service and Room database, ActivityRetainedComponent for dependencies that survive configuration changes but are released when the activity is finished, ActivityComponent for activity-scoped dependencies, and ViewModelComponent for dependencies scoped to a ViewModel. Repository implementations are provided as interface bindings using the @Binds annotation in a Hilt module, which allows the test configuration to substitute a fake implementation without modifying the production Hilt module. The Hilt testing library provides HiltAndroidRule for instrumented tests that need the full Hilt component graph and allows individual bindings to be replaced with test doubles using @BindValue. The module structure is documented in the Architecture Decision Record at the start of the Android Kotlin development engagement so every team member understands which component scope a new dependency should be provided at.
What is ProGuard/R8 and why does Android Kotlin development need it?
R8 is the code shrinker and obfuscator built into the Android Gradle plugin that runs during the release build of an Android Kotlin application. It performs three operations. Shrinking removes unused classes, methods and fields from the application binary, reducing the APK size and eliminating dead code that increases the attack surface. Obfuscation renames classes, methods and fields with short meaningless names that make the decompiled APK significantly harder to read and understand, protecting business logic, API endpoint strings and algorithm implementations from reverse engineering. Optimisation restructures the bytecode to improve runtime performance. The configuration challenge in Android Kotlin development is writing the keep rules that tell R8 which classes and members must not be renamed because they are accessed through reflection: Retrofit service interfaces, Room entity classes, Hilt injection targets and Kotlin Serialization data classes all require specific keep rules to function correctly after obfuscation. Missing keep rules produce runtime crashes in the release build that do not appear in the debug build. R8 configuration is applied and tested as part of the initial Android Kotlin development engagement rather than added at pre-launch when there is no time to debug obfuscation-related crashes.
How does Android Kotlin development handle errors and offline states?
Error handling in Android Kotlin development begins with the typed error model defined in the domain layer: a sealed class hierarchy that represents the specific error categories the application must handle. Network timeout, authentication failure, server error, validation error, data not found and permission denied are distinct error types that produce distinct UI states and distinct user-facing messages. Repository methods return Kotlin Result types wrapping either the success domain object or a typed domain error. The ViewModel maps each typed error to the correct sealed class UiState variant: a retry action for transient network errors, a re-authentication prompt for expired sessions, a contact support option for server errors and an input correction prompt for validation failures. Retry logic uses exponential backoff with jitter for transient failures, implemented using Kotlin Flow’s retryWhen operator with a configurable maximum retry count and delay ceiling. Offline state is handled by an offline-first data architecture that serves cached data when the network is unavailable, queues writes using WorkManager with network connectivity constraints, and synchronises queued writes when connectivity is restored.
How do you evaluate and select third-party libraries for Android Kotlin development?
Third-party library selection in Android Kotlin development applies five evaluation criteria before any library is added to the Gradle version catalog. Active maintenance: the library must have a release within the past six months and an active issue tracker that responds to reported bugs. Kotlin coroutine support: the library must provide a coroutine-based async interface rather than requiring RxJava or callback-based wrappers that introduce style inconsistency with the Kotlin-native codebase. Security posture: the library must have no known vulnerabilities in the NIST National Vulnerability Database at the current version. Licence compatibility: the library must have an Apache 2.0 or MIT licence without commercial use restrictions. KMM compatibility: where the application has Kotlin Multiplatform requirements, the library must support the Kotlin/JVM and Kotlin/Native targets used in the KMM shared module. Libraries that fail any criterion are either rejected in favour of alternatives or accepted with a documented risk acknowledgement and a migration plan specifying the exit path if the library becomes unmaintained or a vulnerability is discovered after integration.