Mobile development: where to start and what to choose

How it differs from web work

The app lives on a device. It must be installed and updated, and it occupies space. Hence the attention to size and to resource use.

Device constraints. Battery, memory, unreliable connectivity, varied screen sizes. A web developer rarely thinks about the app running underground with no signal; a mobile developer always does.

App stores. Releases go through review that can take days and end in rejection. That changes the rhythm: shipping a fix within an hour, as on the web, isn't available.

The lifecycle. The app gets backgrounded, the system may evict it, then restore it. State management is harder than on a page.

What to choose

Native Android. Kotlin and the modern toolkit. Advantages: more devices, a gentler entry, free tools that run on any operating system.

Native iOS. Swift. Advantages: a more paying audience, high-quality tools. A significant drawback: you can only develop on Apple hardware, which for a beginner means notable expense.

Cross-platform tools. One codebase for both. They save time but require understanding both platforms when something goes wrong.

Where a beginner should start

Practical advice: if you don't own Apple hardware, start with Android. Otherwise the very first step runs into buying a computer.

If you do own it, look at postings in your city and count which is more common.

On cross-platform tools. Opinions differ. For: faster to a result, one codebase. Against: when something breaks on a specific platform you'll have to understand that platform anyway, and you have no grounding in it.

A sensible approach: start native on one platform, learn the fundamentals, and pick up cross-platform tooling later. The reverse order leaves gaps.

What to learn

The language. Kotlin or Swift, depending on the platform.

How interfaces are built. The modern declarative approaches: you describe how it looks for a given state and the system renders it.

The lifecycle. What happens on backgrounding, rotation, memory pressure.

Networking. Requests, handling loss of connectivity, caching.

Local storage. An on-device database, settings, files.

Publishing. How to build, sign and submit. Worth going through at least once.

Building a portfolio

Build an app you'll use yourself. A habit tracker, expense log, shopping list — anything personal.

Publish it. At least to open testing. That sets you apart from most: passing store review is experience in itself, and employers notice.

Show offline behaviour. An app that behaves sensibly without a connection immediately says its author thought about real use.

Attach screenshots and a screen recording. Without them nobody sees your app: nobody installs software to assess a CV.

One published app with well-considered states weighs more than five tutorial projects.