"We're building an app." You hear that sentence everywhere today. At family parties, at the bakery, in every other newspaper. Apps sound easy. You have an idea, you type it in somehow, done — it's in the App Store.
That's true — but only on the very last meter. In between lie weeks of work that have surprisingly little to do with programming. I'm describing this here because I'm right in the middle of it myself — with Bonblick. And because I keep noticing how much the effort gets underestimated as soon as someone says "I just need an app for that."
If you're reading this as a Bonblick tester and wondering why some improvement takes days instead of seconds — here's the answer.
1. The visible part: the programming
Programming is actually the part most people picture: writing code, designing buttons, embedding images, building logic. That's real work, but it's only one piece of the whole.
For Bonblick, for example, the "actual app code" for the main function "scan a receipt, read it, show it" was relatively quick to stand up. That's where the rest begins.
2. Different devices
An iPhone is not the iPhone. There's iPhone 12, 13, 14, 15, 16 — all in several sizes. Each screen has a different resolution, a different shape, some have a black bar at the top, others don't. Whoever builds an app has to check that it looks good on each of these devices.
With Android it gets even wilder. Samsung, Google Pixel, Xiaomi, Huawei, Oppo, Motorola — every manufacturer ships the same Android system differently. Buttons sit somewhere else, fonts vary, some devices have a stylus, others fold open.
A list I keep running in my head for Bonblick:
| Thing | How many variants there are |
|---|---|
| iPhone models in active use | around ten |
| iOS versions testers still run | three to four |
| Android manufacturers with their own skin | at least five big ones |
| Android versions in the market | six to seven |
| Screen sizes | too many to count |
So when I say "Bonblick", I don't mean one app. I mean an app that has to work well on a hundred different devices.
3. How code becomes a real app
Once the code is written, it isn't an app yet. It first has to be brought into the format that iPhones and Android devices can understand.
- For iPhone: Apple requires a Mac as a build machine, a digital certificate (think of it as an ID card that only Apple issues), a matching Provisioning Profile (a permission slip per app), and several automatic steps that turn the code into an
.ipafile — that's the finished app package, so to speak. - For Android: Google requires a signing key for digital signatures (you must never lose it — otherwise you can never update the app again), and turns the code into an
.apkor.aabfile.
These build steps are called the build pipeline. They run automatically, but when something gets stuck — and that happens often — the builder ends up staring at incomprehensible error messages for hours.
4. Finding testers
Before an app goes into the big store, you should have it tested on real devices. Not just your own — on your own you miss half the problems. You need other people with other devices.
Finding testers is surprisingly hard. Family and friends help at the start, but:
- They often have the same iPhone model as you.
- They test once briefly, then forget about it.
- They don't want to step on anyone's toes and don't report problems.
Real testers are people who use the app regularly, who give honest feedback, and who can share their experiences in writing or via voice notes. You don't find people like that overnight.
At Bonblick we're trying to solve this with TesterPayKit — a tool that builds the tester feedback channel directly into the app. There's a separate journal article about that.
5. The various test stages — a vocabulary mess
Here it gets really tangled. There are namely many different ways to get an app to a tester, and they all have different names. Here's a translation:
| Term | What it means | Who controls it |
|---|---|---|
| Alpha test | Very early, often just your own team and closest friends. A lot is still broken. | The developer. |
| Beta test | App is essentially complete, but too early for the public. External testers try it out. | The developer. |
| Internal Testing (Google Play / Apple) | Apple or Google allows a small circle of testers (up to 100) who get updates instantly — no waiting time. | Apple or Google, but quickly. |
| External Testing (Apple TestFlight) | Larger tester groups, but Apple reviews every new version first. | Apple. Takes 12–48 hours per new version. |
| Closed Testing / Open Testing (Google Play) | Closed or open tester groups via Google Play. | Google. |
| Firebase App Distribution | Google service that distributes apps to testers — works for iPhone AND Android, completely without an Apple or Google review. | The developer. No waiting time. |
| App Store / Play Store (Production) | The app is public. Anyone can download it. | Apple or Google. Review takes days. |
That means: an app isn't simply "at the tester" or "in the store". It can be in several tester paths at once and feel different to each tester. A real joy for the developer who has to keep track of everything.
6. Apple's review — the bottleneck
Apple doesn't let anything into the App Store without looking at it first. That also applies to beta versions if you want to distribute them to larger tester groups.
Such a check — Apple calls it a review — typically takes 12 to 48 hours today. Sometimes faster, sometimes slower. If something about the app doesn't fit Apple's rules — say a typo in a description, a missing privacy declaration, a note about using your camera that's worded too generally — the version gets rejected. Then you may amend, re-upload, and wait again.
With Google it's faster, but there are rules there too. Violations can lead to the whole app being suspended.
7. What else has to be there besides the code
Before an app can even be submitted, it needs:
- a privacy policy on the internet (legally required in Europe)
- a legal notice (required in Germany)
- a description for the store, in multiple languages
- screenshots in the right resolutions for every device
- an app icon in many sizes
- keywords and categories
- an age-rating declaration (what the app shows, whether there are ads, gambling, whatever)
- data-flow declarations: what the app collects, what gets sent where
- a support contact
Each of these points can become its own story. The privacy policy alone took an afternoon for Bonblick — and we're a relatively simple app, because we don't track anything.
8. Updates — the long part
Anyone who thinks the work is done with the first release is wrong. An app that's in the store wants an update every few weeks — otherwise it smells "abandoned". Testers keep finding problems. Apple and Google change their rules. New devices appear, making old device tests obsolete.
At Bonblick we currently have the agreement to only raise the version number when a real wave is actually done — and otherwise only push the small build number up. Why? Because Apple demands a review again for every new big version number. Whoever uploads a new version five times a day waits five times for Apple. Whoever bumps the build number five times doesn't wait.
Such a detail-decision seems small. But for an app in tester mode it makes the difference between "a week of updates in one morning" and "one update per week".
9. What it feels like
Let me list the days I've spent this week at Bonblick on the following things:
| Activity | Share |
|---|---|
| Programming | about 40 % |
| Checking that everything looks right on various iPhones | 10 % |
| Reading, answering, sorting tester feedback | 15 % |
| Adjusting the build pipeline (Firebase, TestFlight, Play) | 10 % |
| Writing texts (guide page, app description) | 10 % |
| Writing documentation and architecture decisions | 10 % |
| Watching ads to see where the market is going | 5 % |
Only 40 percent is what outsiders picture as "building an app". The rest is the surroundings — and the surroundings are just as important.
10. Why this matters
The next time you hear "we built an app", you'll know: behind it sits a lot more than one programmer with a laptop. Behind it sit tester work, device tests, Apple reviews, Google hurdles, privacy texts, translations, screenshots, support, updates.
That isn't mysterious. But it explains why real apps take time — even when the idea behind them can be told in ten minutes.
For Bonblick that means: when you, as a tester, wish for an improvement and it isn't there in the next hour, that's almost never because of the programming. It's because the app has to pass through all these layers before it lands on your phone again.
Bottom line
An app isn't the code. An app is the code plus a lot of surroundings — testers, devices, reviews, texts, updates. Whoever wants to "just whip up an app" notices that at the latest when they first stand in line for Apple's review queue.
And all of that is just the pre-release. What happens when the app is really public and a thousand people use it daily — that's its own story. One that we at Bonblick will live through too. More on that when the time comes.
Until then: every tester who taps the red bug and sends us feedback makes this process smaller. Thank you for that.