Mobile applications
Third-party mobile apps on voice platforms: what still applies to custom iOS and Android work
When Amazon opened Echo to third-party mobile apps, the lesson was not “add a skill.” It was that a phone, a speaker, and a back office have to share one job graph. That is still the brief for custom mobile work at ETG.
Published 2015-08-20 · Updated 2026-09-19
Why did voice APIs change mobile product design?
A voice surface cannot show a dense table. It can start a job, confirm a status, or hand the rest to a screen. Custom iOS and Android applications that ignore that split end up with a phone UI that copies the desktop and a voice UI that nobody finishes.
ETG still designs field and operations apps around the job, not the gadget. Maps, visit status, and today’s queue belong on the device in someone’s hand. Long configuration belongs on a web application. Billing and tenancy belong on a SaaS platform when you sell that software.
What should a 2026 mobile brief include besides screens?
Offline behavior, push permission, identity, and which events write back to the system of record. If the phone is a companion to a native desktop product, say so — that is the Windows and Mac boundary, not a responsive website.
If you are still choosing surfaces, the software scope estimator will push web, mobile, desktop, and SaaS into one range without asking for an email address.
| Job | Best surface | Why |
|---|---|---|
| Today’s route and visit status | iOS / Android | The work happens away from a desk |
| Role setup and reporting | Web application | Wide tables and admin roles |
| Shop-floor inventory with local hardware | Windows / Mac | Offline, printers, scanners |
Continue with the software scope estimator, software development services, or request a project quote.