general

Forget the myth of the specialist: the most resilient engineers in 2025 are those who master general-purpose thinking - and it's changing how we build mobile apps.

Every mobile engineer remembers the moment they realized that the platform-specific feature they spent weeks building was already obsolete. In 2015, it was custom Android notification channels; in 2020, SwiftUI rendered dozens of UIKit patterns instantly deprecated. The frantic chase to stay "cutting‑edge" on a single platform breeds fragile, short‑lived expertise. But a counterintuitive force is reshaping engineering teams today: the return of the generalist. This isn't about dabbling in everything; it's about wielding general‑purpose principles that outlast any framework release. I've seen this firsthand while designing mobile SDKs that ship across iOS, Android. And even Kotlin Multiplatform - the code that survives the longest is never the platform‑specific cleverness. But the boring, general, adaptable architecture underneath.

In this article, I'll unpack why general‑purpose engineering is the missing skill in most mobile‑focused job descriptions. We'll explore how general availability of cloud primitives, the rise of general AI models, and even general computing RFCs are directly altering the way we ship features. If you've ever felt pressure to obsess over the latest Jetpack Compose modifier before understanding how HTTP/2 multiplexing affects your app's cold start, this is for you. The general approach isn't a compromise - it's the hardest, most valuable engineering discipline you can build now.

The Specialist Trap: Why Platform Expertise Alone Fails

For the last decade, mobile hiring has been dominated by "platform silos. " You were an Android developer or an iOS developer. And the job listings demanded 3‑5 years of list‑scrolling optimization in one specific stack. This hyper‑specialisation looked rational: each platform had its own memory model, concurrency primitives. And display pipeline. But the result was brittle codebases where business logic, network handling, and even navigation state were duplicated across three languages (four if you count web). When an incident forced us to change how we handled authentication tokens, we had to patch the same general flow in every client. And each platform engineer interpreted the general fix differently.

The specialist trap becomes most dangerous during platform‑specific churn. Consider Android's four different ways to handle background work in five years: AsyncTask, JobScheduler, WorkManager, coroutines with structured concurrency. A pure Android expert might refactor to each new API, burning thousands of hours. A general‑purpose engineer, however, sees the invariant: jobs need to be retried with exponential backoff, states must be persisted across process death. And dependencies should be injected. That general knowledge allows you to wrap any scheduler behind a common interface. So platform changes become a one‑file adapter. The app's reliability improves because you apply general robustness principles - like the circuit breaker pattern - instead of relying on the latest OS guarantees.

I've witnessed this directly when our team migrated from a monolithic Firebase‑dependent Android architecture to a domain‑driven Kotlin Multiplatform core. The platform‑specific developers struggled to reason about shared concurrency; the engineers who had background in general computer science (operating systems, networking, compilers) thrived. They knew that a suspend function is just a syntactic sugar over callback‑passing style. And that general concept made it trivial to trace deadlocks. The takeaway: deep platform expertise without general systems thinking becomes a liability as soon as the platform shifts.

Defining general-Purpose Engineering in a Mobile Context

When I say general‑purpose engineering, I don't mean "full‑stack" in the resume‑padding sense. I mean the deliberate study of patterns that hold across runtime environments: state management, distributed systems, parsing, caching. And resource scheduling. In mobile development, a generalist might ask, "What is the shape of the data,? And how do we keep it consistent locally and remotely? " before wondering whether Room or Core Data should store it. The technology choice becomes an implementation detail of a general principle.

This perspective aligns with what the Twelve‑Factor App methodology calls "disposability" and "dev/prod parity. " Both are general guidelines that work for a microservice hosted on Kubernetes or a Flutter client that talks to GraphQL. The moment you adopt a general approach to configuration - injecting environment‑specific values rather than hardcoding URLs - you eliminate entire categories of release‑night regressions. For a concrete example: our team once lost an App Store review slot because a hardcoded staging endpoint slipped into production. A general build‑pipeline rule that asserts build‑time environment variables can prevent such errors across any platform. That's general engineering: solving the class of problem, not the instance.

RFC 1925, "The Twelve Networking Truths," famously includes "It is always possible to add another level of indirection" and "It always takes longer than you think. " While humorous, these general truths have saved me days of debugging. When an iOS app suffered from random HTTP/2 GOAWAY frames, the generalist instinct to add a retry layer with jitter (a concept from general networking design) fixed the issue without ever diving into Apple's Transport Layer implementation. Those who waited for an Apple‑specific patch were down for two weeks. General engineering isn't just a curiosity - it's a reliability practice.

The General-Purpose Language Renaissance: Rust, Go. And Beyond

A fascinating indicator of the generalist comeback is the adoption of languages originally built for systems programming into mobile infrastructure. Rust, which Mozilla Research designed for safe, concurrent systems, is now used to build mobile networking libraries, crypto modules. And even cross‑platform rendering engines (like WebGPU backends). When you integrate a Rust core via the Foreign Function Interface into an Android app, you're leveraging a general‑purpose memory model that eliminates entire classes of bugs - no more null‑pointer crashes, no more data‑race nightmares. The platform‑specific code (Kotlin, Swift) becomes a thin UI shell.

Go hasn't penetrated on‑device mobile as deeply. But it dominates the backend infrastructure that powers modern apps. A general engineer who understands Go's goroutines and channels can effortlessly reason about Kotlin coroutines or Swift's async/await. They're all implementations of the general concurrency concepts described in C. A. R, and hoare's Communicating Sequential ProcessesThe general knowledge of CSP allows you to debug race conditions across a distributed system that spans a Go microservice, a Kotlin‑based Android app. And a Rust‑based BFF (Backend For Frontend). Our own mobile API gateway team rewrote a critical authentication middleware from Node js to Go. And the general understanding of zero‑copy parsing and bounded goroutine pools reduced p99 latency by 40%. That directly improved the app's login screen responsiveness.

Even TypeScript plays a general role. With the rise of React Native and Expo, many mobile engineers now write general‑purpose TypeScript that runs both on the web and on