Platform decisioning
A recorded recommendation on native versus cross-platform, argued from device capability, performance need, team ownership, and the integrations the product depends on.
Software & Product Engineering
Mobile Application Development
A mobile application is judged in conditions a desktop product never faces: intermittent connectivity, small screens, device permissions, and a release process controlled by someone else.
Design and build mobile experiences where offline behaviour, backend services, permissions, and release process are planned together from the start.
Overview
The hard parts are connectivity, permissions, and release
Mobile projects rarely stall on layout. They stall on synchronisation after a period offline, on a permission prompt that users decline, on push delivery, and on a store review that arrives at the wrong moment.
We treat those as first-class design decisions: what works offline, what is authoritative, how conflicts resolve, which permissions are genuinely required, and how a release reaches users predictably.
What this includes
Mobile Application Development capabilities
A cross-platform product and a native feature build differ sharply here; scope follows the devices and the offline requirement.
Cross-platform delivery
One codebase targeting iOS and Android where the product does not require platform-specific engineering.
Native platform work
Platform-specific implementation where device capability, performance, or integration requires it.
Offline and synchronisation design
Explicit rules for local state, conflict resolution, and what remains usable without a connection.
Mobile authentication and device security
Token handling, session lifetime, biometric and passcode unlock where appropriate, and keeping credentials in platform secure storage rather than application preferences.
API and backend integration
Service boundaries, payload shape, pagination, and retry behaviour designed for mobile latency and intermittent connectivity rather than adapted from a browser API.
Push notifications and messaging
Notification delivery through the platform services, with permission timing, opt-out, and quiet handling of the case where a user declines.
Analytics and crash reporting readiness
Crash, error, and usage reporting instrumented behind consent so a defect surfaces in a report rather than in a review.
Device testing and mobile QA
Automated tests plus a defined matrix of real devices, OS versions, and screen sizes, including low-end hardware and poor-network conditions.
Mobile performance and resource use
Startup time, scroll smoothness, memory, battery, and data consumption treated as engineering targets, because a mobile user notices all four.
Mobile accessibility
VoiceOver and TalkBack support, focus order, touch-target sizing, dynamic type, and contrast verified on device rather than assumed from the design.
Release and distribution
Build pipelines, signing, staged rollout, and store submission prepared as part of delivery.
Lifecycle maintenance and OS currency
Keeping an app working through annual OS releases, SDK deprecations, and store policy changes, which is continuing work rather than a one-off build.
What you receive
Concrete deliverables
- Platform and architecture recommendation, with the reasoning recorded
- Application implementation for the agreed platforms
- Backend services, authentication, and notification integration
- Crash reporting and analytics instrumentation behind consent
- Device and OS-version test matrix with automated test coverage
- Accessibility and performance verification on real devices
- Build, signing, and store submission pipeline
Why it matters
Practical outcomes
Usable in the field
Offline behaviour is designed rather than discovered during a pilot.
One team, both platforms
Shared implementation where it is appropriate keeps two platforms in step.
Releases become routine
Signing and submission are automated instead of rediscovered each time.
Backends that fit the client
APIs are shaped for mobile payload, latency, and retry realities.
Scope and third parties
Publication to the Apple App Store and Google Play is governed by those platforms’ review policies and your own developer accounts. We prepare, sign, and submit builds against the published guidelines; approval, review timing, and any later policy change are decisions those platforms make, and no approval outcome can be guaranteed. VishTech Soft holds no platform certification or partner status beyond ordinary developer-programme access.
How a mobile engagement runs
From platform decision to a listed, updatable app.
-
Choose platform and distribution
Decide cross-platform or native based on device features, audience, and how the app will be distributed.
-
Design offline and sync behaviour
Establish what must work without a connection and how conflicting changes are resolved when it returns.
-
Build app and backend together
Develop the app and the services behind it together, since mobile constraints shape both.
-
Test across devices and permissions
Test across real devices, screen sizes, OS versions, and the permission prompts users can decline.
-
Submit and release
Prepare store listings, handle review requirements, and establish a repeatable update path.
What we hold ourselves to
On mobile, the network is a feature, not an assumption.
These are the commitments that keep an app usable outside ideal conditions.
- 01
Designed for intermittent connectivity
The app behaves predictably on a poor connection instead of stalling on a spinner.
- 02
Conflict resolution decided up front
When the same record changes in two places, the resolution rule is a design decision, not a race.
- 03
Permissions requested in context
Access to location, camera, or notifications is requested when the reason is visible, and refusal is handled.
- 04
Battery and data as budgets
Background work and payload sizes are constrained deliberately, because users notice both.
- 05
Release cadence that survives review
Versioning and store submission are planned so a fix is not held hostage by the release process.
Relevant technology
What a mobile product is built from
The mobile layer itself, the services it synchronises with, and the testing that spans real devices.
Capability domain
6 tools
Mobile
- Flutter
- React Native
- Swift
- Kotlin
- iOS
- Android
Capability domain
11 tools
Backend
- Laravel
- PHP
- Node.js
- NestJS
- .NET
- ASP.NET Core
- Python
- Django
- FastAPI
- Java
- Spring Boot
Capability domain
5 tools
APIs and Messaging
- REST
- GraphQL
- WebSockets
- RabbitMQ
- Apache Kafka
Capability domain
7 tools
Testing
- Pest
- PHPUnit
- Playwright
- Cypress
- Vitest
- Jest
- Postman
Scope boundaries
Where this work hands off
Mobile work is easily confused with the browser product beside it, so the distinction and the surrounding services are stated plainly.
-
Web Application Development
A responsive web application runs in the browser and updates when you deploy. A mobile app is installed, ships through a store review, and has to cope with the device it lands on, so the two are scoped and engineered separately.
-
API & Integration Development
Shaping the services this app consumes is included; building an integration layer that several client applications share is its own engagement.
-
SaaS Product Development
An app can be one client of a subscription product; the pricing, tenancy, and billing model behind that product is a separate piece of work.
-
Cloud Engineering
The backend an app talks to has to run somewhere; provisioning and operating that environment sits under cloud and hosting work, on your own provider accounts.
-
Quality Engineering & Test Automation
Delivery includes testing this application; establishing an organization-wide automated testing capability is commissioned separately.
-
Application Maintenance & Support
OS releases, SDK deprecations, and store policy changes keep arriving after launch, so ongoing maintenance and a support response commitment are a continuing arrangement rather than part of the build.
Questions
Useful context before a consultation
Mobile questions usually concern cross-platform versus native, offline behaviour, and app-store release timing.
Cross-platform or native?
Cross-platform suits most business applications. Native is the right call when device capability, performance characteristics, or a platform-specific integration determines the product. The recommendation is written down with its reasoning so it can be challenged.
Do we need a separate backend?
Not always. An existing API can often serve a mobile client, though payload shape, authentication, and retry behaviour usually need attention.
Can you publish to the app stores for us?
We prepare, sign, and submit builds through your developer accounts. The accounts and the commercial relationship remain yours.
Can you guarantee the app will be approved?
No. We build against the current App Store and Play guidelines and prepare the review materials, which is what makes rejection unlikely rather than impossible. Approval is the platform’s decision, and guidelines change.
Which devices and OS versions will it support?
An agreed matrix, set from your audience rather than from a default. Supporting older OS versions widens reach and adds test and maintenance cost, so the trade-off is decided explicitly at the start.
What happens when Apple or Google releases a new OS?
Annual releases deprecate APIs and change behaviour, and stores periodically raise their minimum build requirements. Keeping an app current is continuing work, which is why maintenance is arranged as an ongoing engagement rather than assumed to be included.
Is the app accessible?
Screen reader support, focus order, touch-target sizing, dynamic type, and contrast are built in and verified with VoiceOver and TalkBack on real devices. Accessibility is treated as an engineering requirement, not a checklist run at the end.
Start a conversation
Discuss a mobile application
Tell us who uses it, where they use it, and what has to keep working without a signal.