Development approaches · ViewBinary Digital
Choosing how to build for web and mobile
Most project decisions come down to one question: how should this thing be built? The answer shapes cost, timeline, and what you can change later. This guide compares the common routes for web and mobile development in plain terms, with the trade-offs each one carries.
Why this comparison matters
Four routes, one honest conversation
Almost every proposal you receive will be a version of four routes: a responsive website, a progressive web app, a cross-platform build, or a native app. The wording changes from studio to studio. What stays the same is the underlying set of trade-offs, and those are easier to judge once you can name them.
None of the four wins everywhere. A route that suits a booking page may be the wrong choice for an app that leans on device hardware. Read each option against what your product has to do, then decide. The rest of this page goes through them one at a time, followed by the questions that usually settle the choice.
What it must do
Search visibility, offline use, notifications, camera access, background work. Each one points at a different route.
Who maintains it
One codebase or two, and whether your team can keep either one updated after launch.
What changes later
Adding a feature, moving to a new platform, or rebuilding is cheaper on some routes than others.
Caption — a route is a set of trade-offs, not a verdict
The four routes
The four routes you will be offered
Responsive websites, progressive web apps, cross-platform builds, and native apps. Most proposals you receive will be some version of these, even if the wording differs. Understanding what each one is good at makes the rest of the conversation easier. None of them wins everywhere.
It helps to hold two ideas at once. First, a route is not a quality level: a well-built responsive site beats a rushed native app for the job it was chosen to do. Second, routes can be combined over time. Plenty of businesses start with a responsive site, add a progressive web app layer when offline use matters, and only then consider a cross-platform or native build for the parts that need it.
Responsive — one layout, every screen
PWA — a site that behaves like an app
Cross-platform — one codebase, two stores
Native — built twice, closest to the device
Route one
Responsive websites
A responsive site adapts its layout to the screen it is viewed on, from a phone to a desktop monitor. It is usually the fastest and cheapest way to reach customers across devices, and it works in any browser without an install.
The limits appear when you need offline behaviour, push notifications, or deep access to device hardware. For a marketing site, a booking page, or a content platform, a responsive build is often the right starting point.
Mobile-first design belongs here too. Building for the smallest screen first, then expanding, tends to produce cleaner results, because it forces early decisions about what actually matters on a small screen. It is a discipline rather than a technology, and it applies to apps as well as sites.
Good fit when
- Customers need to find you through search
- The content changes often and is edited by your team
- You want one build to serve every device
Watch for
Features that assume a device rather than a browser: background sync, sensors, or notification-heavy flows. Those usually push a project toward one of the routes below.
Route two
Progressive web apps
A progressive web app, or PWA, is a website that behaves more like an installed app. It can work offline, send notifications, and sit on a home screen. PWAs avoid app store approval, which speeds up releases and updates.
They are a good fit when you want app-like behaviour without maintaining two native codebases. They are a weaker fit when you need heavy background processing or the latest device APIs. On iPhones they run in the mobile browser, with some feature differences compared to Android: offline behaviour and home-screen installation work, while certain device-level features are more limited.
Good fit when
People return often, need offline access to core screens, and you would rather not wait on store review for each release.
Watch for
Heavy background work, hardware-intensive features, and any capability that is uneven between iOS and Android.
Route three
Cross-platform frameworks
Cross-platform development lets one codebase run on both iOS and Android, usually through a framework built on web technologies. It reduces the cost of serving both platforms and keeps features in sync.
The trade-off is a layer between your code and the device, which can matter for graphics-heavy or hardware-intensive apps. For many business apps, that layer is invisible to users. What matters more is the release rhythm: one feature set, two stores, one set of updates to keep aligned.
Where it helps
Accounts, dashboards, booking, forms, content feeds, and internal tools that look and behave the same on both platforms.
Where it strains
Real-time graphics, heavy camera or sensor work, and features that arrive on one platform first and stay uneven for a while.
One thing to check
Cross-platform does not mean identical. Ask how platform-specific behaviour will be handled before you assume one build covers both.
Route four
Native apps
A native app is built separately for iOS and Android using each platform's own tools. It gives the best performance and the most direct access to device features like camera, sensors, and background tasks.
The cost is higher: two codebases, two release cycles, two sets of updates. Native makes sense when the app's core value depends on performance or hardware that other routes cannot reach. If your product is mostly forms, lists, and content, that extra cost rarely pays for itself.
Choose it when
Smooth motion, low input delay, or sensor and camera work decide whether the product is any good.
Budget for
Two builds and two release cycles, plus the review time each store adds before a fix reaches users.
Plan for
Keeping features aligned across both platforms as the product grows, which is ongoing work rather than a one-off task.
Deciding
How to decide
Start with what the product must do, not with the technology. Write the requirement first, then match the route to it. A short written brief is usually enough to rule two routes out before any estimate arrives.
It has to be found in search
A responsive site or a server-rendered web app usually fits. Pages exist as real addresses that search engines can read, which is the point.
It has to live on a home screen and work offline
Consider a PWA or a cross-platform build. Both can be installed, and both can keep core screens usable without a connection.
It depends on hardware or speed
Native is worth the extra cost. When the product's value sits in the camera, sensors, or frame-by-frame responsiveness, the layer a cross-platform build adds becomes visible to users.
It is mostly reading and forms
A responsive build covers it. A website is mainly read; a web app is mainly used, and pages that handle accounts, dashboards, or bookings sit closer to the second category. The line blurs in practice, but the distinction helps when scoping.
The scope is still unclear
Start with the smallest route that ships the core job, and keep the others open. Changing direction later is easier when the first build does not try to cover every possibility at once.
A discipline, not a technology
Where mobile-first fits
Mobile-first design means building for the smallest screen first, then expanding. It is a discipline more than a technology, and it applies to responsive sites and apps alike.
Given how much web traffic comes from phones, starting with the mobile layout tends to produce cleaner results. It also forces early decisions about what actually matters on a small screen, which is where most of your visitors will first meet the product.
It shows up in small choices rather than slogans: which navigation items survive on a narrow screen, how forms break into steps, what a table becomes when it no longer fits. Teams that skip this step usually rebuild the same screens later, once the phone layout starts fighting the desktop one.
Before you sign off
Common mistakes
Each of these turns into cost later, and each is avoidable with one honest conversation at the start.
Choosing a technology because it is fashionable, before the requirement is written.
Scoping a native app when a responsive site would do the same job for less.
Assuming cross-platform means identical on both platforms, then discovering the differences after launch.
Skipping the question of who maintains the build after launch, and who pays for it.
Treating the first release as the final one, when most products change within the first year.
Scoping decisions are usually cheaper than rebuilds
Questions we hear most about these routes
Should a business app be built natively or with a cross-platform framework?
It depends on how much the app relies on device performance and hardware. Native gives the deepest access and best performance, at higher cost. Cross-platform covers most business app needs with one codebase. Match the route to what the product must do.
What is the difference between a web app and a website?
A website is mainly read; a web app is mainly used. Web apps handle tasks like accounts, dashboards, or bookings. The line blurs in practice, but the distinction helps when scoping a project.
Do progressive web apps work on iPhones?
They run in mobile browsers on iOS, with some feature differences compared to Android. Offline behaviour and installation work, but certain device-level features are more limited. If iOS is a primary audience, check the specific features you need.
Where to go next
Once a route is on the table, the next useful steps are practical: what the project will need from your side, which tools a team is likely to use, and how to judge the build and the support that follows it. If you would rather talk it through first, our contact details are below.
Plan the project
Scope, budget ranges to expect, and the questions worth settling before development starts.
Project planning guideCompare the toolset
What the common frameworks, databases, and design tools are actually used for on a business build.
Tools and stack guideJudge the result
How to review code quality, testing, handover, and the support arrangement after launch.
Quality and support criteriaViewBinary Digital
Parkveien 15, 0350 Oslo, Norway
Monday to Friday, 9:00 AM – 6:00 PM
+65 6208 6962 · [email protected]