Mobile Developer

When a company's whole service lived inside a browser, splitting developers into screen people and server people was enough. Then phones took over, users asked for the same service on iOS and Android, and the browser way of building screens stopped working.

The sharpest difference is how the work ships. On the web, you push fixed code to a server and everyone sees the new screen on their next visit. An app has to be packaged, uploaded to the stores Apple and Google run, and approved by their review before anyone can install it — and even after approval, nothing changes for a user until that user takes the update.

Here is what that looks like on a bad day. A report comes in that the payment button doesn't respond. The web fix goes out in thirty minutes. The app fix sits in review and reaches users the following afternoon, and the 30 percent who put off updating keep staring at the broken screen for a while after that.

So teams needed someone who designs around the constraints of software that lives on a device rather than on a server. Review timelines, old and new versions running side by side, battery, and permissions for things like the camera and location all land on this role.

More than half the day goes into turning design files into app screens and checking on a real device that those screens render what the server sent back. The rest is shipping and watching what happened after shipping.

1. Building screens — the same design becomes two implementations, one in iOS code and one in Android code, because the two systems supply different building blocks. Even pull-to-refresh on a list is built differently on each side.
2. Talking to the server — the app calls an application programming interface (API), the agreed-upon channel two programs use to exchange data in a fixed shape, and puts the result on screen. Apps add one condition the web can mostly ignore: signal drops in a subway car are normal, so every screen needs an answer for what to show on failure and when to retry.
3. Handling device spread — a small old handset and a folding phone run the same app, and operating system versions are mixed. When a new capability only exists on the newest version, you also build the fallback screen for everyone else.
4. Submitting and releasing — you produce the build, upload it, and wait for review. Even after approval most teams open it to one percent of users first, watch whether errors climb, then widen. This is the one place where the engineering team does not get to pick the release date by itself.
5. Watching the aftermath — the number to watch is how often the app quits unexpectedly. Fewer than one crash per thousand sessions is a normal baseline; if that rate jumps from 0.1 to 0.6 percent the day after a release, you find the cause and fix it in the next version.

Shipping one app version puts this role in contact with five others. Most of those conversations are about explaining an app-specific constraint to someone who doesn't hit it.

1. Product designer — hands over the designs. Anything the two operating systems treat differently gets settled here, such as whether going back is a button in the top-left corner or the phone's own gesture.
2. Backend developer — agrees on the shape of the data. The server changes the moment it deploys, but old app versions stay in the wild for months, so both sides keep confirming that the server still serves those versions.
3. Product manager — agrees on scope and timing. Does the plan include the days review takes, and when does a feature that missed this version actually reach users.
4. QA engineer — checks the build before it leaves. Because an app release is hard to take back, the checking is broader than on the web and runs against a fixed set of device and OS combinations.
5. Growth marketer — shares the store listing and push notifications, the alerts an app sends straight to the device. A user who denies the permission can't be reached at all, so the moment the app asks for it moves marketing numbers.

"On Android this screen hides the save button once the keyboard comes up."

The problem exists on one operating system only, so the design can't be used as drawn.

"Review takes a day or two, so I need the build by Thursday for it to go out next week."

The team doesn't fully control the date an app reaches users.

"If we send this down from the server instead, we can change it without an app update."

A proposal to move a value out of the app so that changing it later doesn't mean another round of review.

The quarter Pagedeck brought document sharing to its apps, Theo said that third sentence more than anything else. Nobody had decided whether a share link should expire after 7 days or 30, and a number written into the app means a new version and another review every time it changes. Theo had the app read the value from the server, and two months later, when Mia asked to make it 14 days, the app was never touched.

It went the other way too. Noa rearranged the buttons on the sharing screen, and that is the screen itself, so there was no route other than an app update. Theo folded it into the next scheduled release.

The most common assumption is that anyone who can build web screens can build the app. Both deal with what users see, and much of the vocabulary overlaps. But an app carries three conditions the web doesn't: it goes through review, older versions keep running, and it shares battery and storage with every other app on the phone. Build without knowing those and you get something that gets rejected in review, or that drains a battery just by sitting there. Saying the work resembles what a frontend developer does is fair; saying the two swap freely is not.

The other frequent mistake is believing that a new release means everyone is now on it. The web behaves that way, so the app seems like it should too, but users have to accept the update and plenty have automatic updates switched off. A month after a release, it's common for 20 percent of users to still be on the previous version. Forget that, reshape the server to match only the newest app, and people who delayed the update open the app one morning to an empty list. That's why the server keeps answering older versions for a while, and why very old versions get stopped at launch by a screen asking the user to update.