Mobile app development in Miskolc

01Do you really need an app, or is a good web interface enough?

The first question isn't iOS or Android — it's whether you need an installable app at all. A mobile-optimised website or web-based customer portal is available without a download, and is typically quicker and less costly to build. A middle ground is the PWA (progressive web app): it can be added to the home screen, partly works offline and can receive notifications on iOS too — but it doesn't appear in the app stores, and its access to some device features is more limited.

An app adds real value where users come back regularly and where you need to build on what the phone can do. During discovery we weigh up all three routes and explain in writing which one we recommend — if the web route is the better choice, we'll recommend it, even if that means a smaller order. We also look at the habits of your intended users before deciding. If several of the following apply, an installable app is very likely worth it:

• users would use it regularly, several times a week;
• it has to work in the field, even with a weak signal;
• the work needs the camera, barcode or QR scanning, or location;
• push notifications are an important way to bring users back;
• an app store presence also strengthens the credibility of your brand.

02Native or cross-platform: why React Native?

With native development, the iOS and Android versions are built from two separate codebases, which means two parallel streams of development and maintenance. With a cross-platform approach, a single shared codebase runs on both systems. We typically work with React Native: the user interface is built from each platform's own components, so the app feels native, while development and maintenance are concentrated in one codebase. For business and customer apps, this approach has generally proved itself well.

In practice this brings three advantages: both platforms get new features at the same time, bugs are fixed once, and we can build on shared know-how — and even shared code — with our web interfaces (React, TypeScript). If a feature needs special hardware access or a platform-specific solution, we flag it separately in the discovery findings and justify the technology choice in writing so it remains traceable later. That way, your app doesn't depend on the knowledge of a single developer.

03Backend, integrations and offline mode

An app rarely stands on its own: the server side behind it stores the data, manages users and sends the notifications. We build this part too — typically on Node.js or .NET, with a PostgreSQL database, in the Microsoft Azure cloud — and connect it via a REST API to your existing systems, whether that's a custom CRM, business software or a webshop. If needed, the app can also connect to machines or building automation — again, all handled under one roof.

For users in the field, offline mode is a key issue: the app stores recorded data on the phone, syncs it when the connection returns, and resolves conflicts according to rules defined in advance. Push notifications are delivered through Apple's and Google's notification services; who receives which message and when is designed in line with each user's settings and consent. We can also make the content and scheduling of notifications manageable from an admin interface.

04App Store and Google Play: the rules of publishing

Both app stores review submitted apps and can reject those that don't meet their guidelines. Common reasons for rejection include an incomplete privacy policy, a login that doesn't work for the reviewer, or an app that offers little more than a website. We take these guidelines into account from the design stage and build time for review into the schedule, so your launch doesn't slip. A rejection isn't the end of the road: we fix the point raised and resubmit the app.

An important principle is that the developer accounts (Apple Developer Program, Google Play Console) are registered in your company's name — for an organisation account, both stores require a D-U-N-S number, and we help you obtain one. The stores also require data handling information, and if users can create an account in the app, they must also be able to delete it from within the app. That's why we set out the GDPR requirements — privacy notice, consents, where the data is stored — at the design stage.

05What happens after launch?

A mobile app is never finished once and for all. Apple and Google release a new OS version every year, and Google Play regularly raises the Android API level that apps must target — if you don't keep up, after a while you can no longer upload updates to your app. The libraries used, security fixes and changes to app store guidelines also need constant attention. Maintenance is therefore not an optional extra but a condition of keeping the app alive.

Handover comes with documentation and training, and after that we can take care of maintenance as needed: updates, error monitoring, app store submissions and further development based on user feedback. We can also cover the server-side hosting environment and your company's IT background through our managed IT service, under the same contract — so one partner is responsible for the app and the system behind it working together. The scope of maintenance — what, how often and with what response time — is agreed in writing in advance.