Web applications (PWA), Serbia
A web application that installs from the website to the phone, keeps working when the signal drops, and sends notifications, with no app store publishing.
For businesses whose customers or staff need a tool on their phone, for orders, bookings, a catalogue, or internal forms, where a conventional mobile app would cost more and take longer to build than the job requires.
An app is not a goal in itself. We start with what people do and how often they come back, and only then choose the form. Sometimes the answer is that you do not need an app, and we say so in the first conversation.
Repeat orders, bookings, a catalogue for sales staff in the field, work orders, or internal forms: this is where an icon on the phone and working on a weak signal genuinely shorten the job. The same code runs on Android and iPhone, and a new version reaches users with no app store review. We write the app for that workflow and use ready-made libraries only when they are needed, and we say why.
If the app must keep running in the background, use Bluetooth or NFC on iPhone as well, or if customers really look for your app in the App Store and on Google Play, a native app is the more honest choice. It takes more work, because it is published, reviewed, and maintained in two stores, but a PWA cannot meet those requirements, and it is better to say so before the project starts than after.
Few people will install an app from a business they contact once a year. If a visitor wants information, a price, or a contact and moves on, a fast mobile-friendly website does the job, and an app would be a cost with no benefit. In that case we suggest the website. It can gain installation and offline use later, if they turn out to be needed.
Android and iPhone do not support the same things, and the differences affect how the app works for your users. That is why we list them before the project starts and test on real phones, since capabilities change with new system versions.
On Android, Chrome offers installation itself, and the app can also show its own install button. iPhone has no such prompt: the user opens the Share menu and chooses to add the app to the home screen, which since iOS 16.4 also works from Chrome, Edge, and Firefox, not only Safari. That is why we build a short guide into the iPhone version, because the option is not obvious on its own.
On Android, notifications can also work from the browser once the user allows them. On iPhone they work from iOS 16.4, and only when the app has been added to the home screen and the user confirms permission with a tap, for example on a subscribe button. So we ask for permission when the user can see what the notification is for, not on the first open. Anyone who does not add the app or does not accept notifications will not receive them, so important messages need a second route, such as email.
After a first visit online, the screens and data we prepared also work without a connection. Entries can be saved and sent when the connection returns: in the background in Chrome on Android, while on iPhone we plan for sending when the app is opened again. Data on the phone is not an archive, because the browser can delete it, so anything important must also be on the server. Bluetooth and NFC from a web app work in Chrome on Android but not in Safari on iPhone, and a PWA cannot be relied on for constant background work, such as tracking location while the app is closed.
We price this after an assessment, once we know what the app has to do, because very different jobs go under the same name. These are the things that change the scope most.
An app that only shows the last saved catalogue offline is relatively simple. When users also change data offline, we have to decide what happens if two people edited the same thing, who takes priority, and how the user sees that something has not been sent yet. So we decide screen by screen what must work offline, rather than applying it to everything.
An app with no login and an app with customers, staff, and an administrator are not the same job. Each role means its own screens, its own permissions, and checks that nobody sees data that belongs to someone else. On top of that comes the area where your team edits content and sends notifications, if the existing WordPress is not enough for that.
Connecting to a WordPress site, a WooCommerce store, inventory, or accounting depends on whether the other side has an API and how well it is documented. If the website already holds the content and accounts, the app can use them so nothing is entered twice. A standalone app is simpler at the start, but it needs its own database and its own backups.
Frequently asked questions
Not by itself, because a PWA installs directly from the website. On Google Play it can be published as an Android app that opens the PWA, using Trusted Web Activity. Apple requires in its guidelines that an app be more than a repackaged website, so do not count on the App Store without additional work, and even then approval is not certain. If being in the stores is a requirement, say so at the start, because it can change the choice of technology.
Yes, with limits worth knowing in advance. The user adds it manually, through the Share menu. Notifications work from iOS 16.4, only when the app has been added to the home screen and the user allows them. Safari on iPhone does not support Bluetooth and NFC from a web app. For orders, bookings, and forms this is usually not an obstacle, but we test each requirement on a real phone before promising it.
What has been prepared in advance does: saved screens and data are available offline, and entries can be saved and sent when the connection returns. The first visit needs internet. Anything that must be current, such as a live price, stock level, or free slot, cannot be accurate offline, so the app must make that clear to the user.
Yes. WordPress and WooCommerce have an API through which the app reads and changes content, products, or orders, so data is not entered twice. The app can also run completely separately from the website when that is simpler. Which is better depends on where the data already sits and who changes it, and we settle that before development starts.
Process
The same four steps regardless of the service - to know where the project is at all times.
Other services
Services are often combined - redesign with performance work, a store with maintenance.
Contact
Send a short project description, the current website link if one exists, and the goal you want to achieve. We will respond with the best next step.