Browsers and devices
Nexpura runs in a modern browser on a desktop, laptop, tablet, or phone — no install. This page lists the browsers we actively test on, what works well on mobile vs. desktop, and the platform-specific quirks worth ruling out first when something looks wrong.
Quick reference
- Nexpura runs in a modern web browser — no app to install. Supported browsers are Chrome, Edge, Safari, and Firefox on their last two major versions, on Windows, macOS, ChromeOS, iOS, iPadOS, and Android.
- The main staff app and the POS register work on desktops, laptops, and tablets in landscape. Some screens (Kanban boards, the financials hub, multi- column report tables) are usable on phones but display better with the wider tablet or laptop viewport.
- Customer-facing surfaces (repair tracking, verify-passport viewer, storefront, web enquiries) are built mobile-first — most customers visit these on their phones.
- Internet Explorer is not supported. Older Safari (older than two major versions) and the in-app browsers inside some social apps (Facebook, Instagram in-app browser, TikTok in-app browser) can render most pages but are not actively tested. If a customer reports a broken-looking page from a social app, opening the link in their real browser usually resolves it.
- We don't require a specific operating system. The constraints that matter are the browser and the browser version, not Windows vs. macOS vs. Linux at the OS level.
Desktop and laptop
The staff app is built for a desktop or laptop browser window in the typical 1280px+ width. Every screen works at 1024px and most work at 768px, but the information density on the financials hub, the Kanban board, and the report tables benefits from the wider window.
Chrome and Edge are the most-tested combination. Firefox and Safari are tested on each release; both render correctly and pass the same e2e suite. Edge on Windows is functionally identical to Chrome on Windows (both use the Chromium engine).
Keyboard shortcuts that exist on the main app are surface-specific (e.g. the POS register has a few hotkeys for common register operations) and are documented on their canonical page. Cross-app keyboard shortcuts (Cmd/Ctrl-K for search, etc.) are not yet implemented — the navigation today is mouse / touch first.
Tablet
The POS register is designed to run on a tablet in landscape orientation. iPad with iPadOS Safari and Android tablets with Chrome are both supported. The on-screen keyboard works for the search and amount fields; for high-throughput register use, a Bluetooth keyboard alongside the tablet speeds things up.
The staff app outside the POS register is also usable on a tablet — the side navigation collapses and the page bodies render in a single column on the narrower viewport. Most workshop staff prefer a tablet on the bench (photos straight from the tablet camera into repair / bespoke records); most counter staff prefer a laptop or a desktop machine.
Phone
The staff app is responsive and works on a phone-sized viewport. Pages reflow to a single column; side navigation collapses to a hamburger menu. Some screens — Kanban board, financials hub, multi-column report tables — are functional on a phone but read more comfortably on a tablet or larger.
Customer-facing surfaces are built mobile-first. The repair-tracking page a customer receives a link to is tested on iOS Safari and Android Chrome as the primary cases.
The photo-capture flow inside the staff app (taking a photo for a repair / bespoke / inventory record) uses the browser's native camera-input control, which on most phones opens the camera app to capture and then returns the file. See Photo attachments for the workshop-specific shape and the HEIC- orientation note.
Known platform-specific quirks
The set of edge cases worth ruling out when a screen isn't behaving as expected. Each entry names the symptom, the cause, and the workaround. None of these are bugs we don't know about — they're the natural quirks of running a web app across the browser-and-device matrix.
HEIC photos look broken in Chrome / Edge on Windows
Symptom: an iPhone user uploads a HEIC photo (the default iOS image format on iOS 11+) to an expense receipt or a workshop record. On the staff member's Windows desktop running Chrome or Edge, the preview thumbnail renders as a broken-image icon. On a Mac, the same upload previews correctly. Cause: Chrome and Edge on Windows don't natively decode HEIC; macOS Safari and the OS-level image services on iOS / macOS do. The file itself is uploaded and stored correctly — the rendering is the only problem. Fix: the iOS-side fix is to switch the camera format on the phone (Settings → Camera → Formats → Most Compatible, which captures JPEG instead of HEIC). The staff-app-side fix planned but not yet shipped is server-side HEIC → JPEG conversion on upload. See the in-context note on Expenses for the expense-receipt-specific shape and Photo attachments for the workshop-side note.
iPhone photo uploads come out sideways
Symptom: a photo taken in portrait on an iPhone and uploaded to a workshop record displays sideways (or upside down) in the photo viewer on a desktop browser. Cause: iPhone photos store orientation in EXIF metadata rather than rotating the pixel data. Some browsers honour the EXIF rotation tag and render the photo correctly; others ignore it and render the raw pixel data, which was captured in the sensor's native landscape orientation regardless of how the phone was held. Fix: the canonical photo-display surface in Nexpura applies EXIF rotation client-side, so most photo views render correctly. If you see a sideways photo, the surface you're on likely renders it raw — note which screen and report to support with the record ID so we can patch the specific render. The underlying file is correctly stored; re-uploading won't fix it.
Safari on iOS rejects sign-in cookies in private / incognito mode
Symptom: a customer or staff member trying to sign in from Safari Private Browsing on iOS sees the sign-in page accept the credentials, redirect briefly, then bounce them back to the sign-in screen as if the session didn't persist. Cause: Safari Private Browsing on iOS has stricter cookie-storage rules; the sign-in session cookie can fail to persist across the redirect. Fix: open the page in a non-private tab. If you need to use Safari on iOS regularly, signing in outside Private Browsing once usually establishes the session for subsequent regular-tab visits.
In-app browsers (Facebook, Instagram, TikTok) render some pages awkwardly
Symptom: a customer clicks a link to your storefront or to a verify-passport page from inside the Facebook feed, the Instagram bio, or a TikTok comment. The page renders, but interactive parts (the buy button, the verify-piece form) feel sluggish or the layout looks off. Cause: in-app browsers inside social apps are simplified browser engines that don't implement the full feature set of Safari, Chrome, or Firefox. They're fine for reading; they're limited for interaction. Fix: most in-app browsers have a small “open in Safari” / “open in Chrome” icon somewhere in the top corner. Tapping it loads the page in the device's real browser where everything works as expected. For customer-facing flows where this matters, the page itself doesn't detect-and-warn today — recipient education (e.g. including “open in your browser” copy in your campaign) is the workaround.
Printer drivers add extra margins or cut off barcode tags
Symptom: an inventory tag prints with the barcode cut off on the right edge, or a receipt prints with a large blank margin at the top. The PDF preview in the browser looks correct; the physical print doesn't. Cause: the printer driver is applying its own margin / fit-to-page setting on top of the page's embedded layout. Common offenders: the “fit to printable area” option on Windows printer drivers, and the “scale” setting in the browser print dialog. Fix: in the browser print dialog, set scale to 100% (not “fit”) and turn off any “page fitting” / “shrink to fit” option on the driver itself. For label printers, the printer's native software (e.g. Dymo, Brother P-touch, Zebra) typically does a better job than the generic browser print path — see Print tags for the supported label-printer list and the recommended workflow.
The page goes blank or shows an old version after a recent deploy
Symptom: the page renders blank or shows old UI for a feature you know was recently changed, even after clicking links inside the app. Cause: the browser is serving cached JavaScript / CSS from the previous version of the app. Most of the time the cache busts on its own within a session; occasionally a long-lived tab needs a hard refresh. Fix: hard refresh — Ctrl+Shift+R on Windows / Linux, Cmd+Shift+R on Mac, or pull-to-refresh on mobile. If the page is still wrong after a hard refresh, close the tab and open it again. If it's still wrong after that, sign out and back in.
Sign-in or 2FA fails immediately after a phone swap
Symptom: you got a new phone, restored from backup, and your 2FA authenticator app no longer produces codes Nexpura accepts. Cause: the 2FA secret is stored inside the authenticator app; some authenticators back the secret up to iCloud / Google account and restore correctly, others don't. If the secret didn't make it onto the new phone, the codes generated by the new app are wrong even though the app looks the same. Fix: use your saved recovery codes to sign in, then re-enrol 2FA from the new phone — see Security and 2FA for the recovery-code flow. If you don't have the recovery codes, see Getting help for the support-side reset path.
File upload silently fails on a slow connection
Symptom: you select a 6-8 MB photo to attach (an expense receipt, a workshop photo, a task attachment), the upload spinner runs for a while, then the page acts as if you never clicked upload — no error, no file in the list. Cause: the request timed out before the server received the full file. Common on patchy mobile data or shop wifi with intermittent drops. The browser doesn't always surface a clean error in this case. Fix: retry on a stable connection (move closer to the wifi access point, or wait until you have full mobile signal). If the file is large, also see the per-feature troubleshooting on the upload surface ( Expenses and Photo attachments both document the size cap and the supported types).
Pop-up blocker swallows the PDF preview window
Symptom: you click Print on an invoice or quote, expect a PDF preview tab to open, and nothing happens. The browser's pop-up blocker icon may briefly appear in the address bar. Cause: the PDF preview opens in a new browser tab; some pop-up blockers treat that as a pop-up and block it without an obvious notification. Fix: allow pop-ups for your Nexpura tenant URL in browser settings, or click the pop-up blocker indicator and approve the blocked window manually. Re-clicking Print after approving usually works the second time.
When to suspect the platform vs. the app
A useful test: reproduce the symptom on a different browser or device. If a screen looks broken on Chrome on Windows and renders correctly on Safari on the same tenant, the issue is almost certainly a Chrome / Windows quirk — see the quirks list above. If the screen looks the same on every browser you can find, the issue is in the app and the right next step is the canonical page's troubleshooting section or a message to support.
For customer-facing pages (a customer reports a broken-looking link), the cheapest debug is to ask them to open the link in their main browser rather than from inside whatever app they were in (Facebook, email, etc.). Eight times out of ten the page is fine; the in-app browser was the issue.
Related
- Common issues — the symptom-first index that points at canonical-page troubleshooting sections
- FAQ — cross-cutting questions including device-specific concerns at the meta level
- Getting help — what to include in a support email when the platform-quirk list doesn't resolve it
- Expenses — the canonical surface for the HEIC-on-Chrome-Windows quirk
- Photo attachments — the canonical surface for workshop-side photo quirks, EXIF orientation, and iPhone capture
- Print tags — supported label printers and the printer-driver settings that affect output
- POS overview — tablet shape and receipt-printer setup
- Storefront subdomain — the mobile-first customer-facing storefront and its checkout layer
- Verify customer page — the mobile-first verify-piece flow most customers visit on a phone
- Security and 2FA — recovery-code flow when an authenticator app stops producing valid codes after a phone swap