The process of building a mobile app

The team at San Digital has extensive experience developing apps for mobile devices, smartwatches, and smart TVs; using native and hybrid technologies (and everything in-between!) including using Rust for complex comms.

Do you really need an app?

The first, second and third question in the process of developing a mobile app is "do you really need an app?" Reasons I've heard why companies believe they need an app include:

  • Our customers spend hours each day on mobile apps.
  • Our customers will think we're behind the times.
  • Our competitors have mobile apps.
  • Our marketing department needs more data.
  • Our marketing department wants to send push notifications.

Broken mobile phone

Of course, none of these are justified or evidenced reasons for a mobile app. When we sit down with a client to discuss the possibility of a mobile app, it's a workshop to discuss and tease out the business's goals and objectives - or the challenge we're trying to address. Once there's a clear view or problem statement, we then look at appropriate technologies and solutions, often with rapid prototyping and end-user testing.

In our experience, the solution is very rarely a mobile app that's submitted and maintained in the App Store, Google play, and others. More often than not a responsive website or a PWA (Progressive Web App) can deliver a better outcome, at a lower cost of development (often with existing web component reuse) and without introducing new technologies and maintenance overheads. After all, a mobile app requires installation on the mobile device.

OK, so you do need an app this time

There are justifications for mobile apps, such as requiring:

  • Truly native device functionality, e.g. tracking steps using a motion coprocessor (note: web apps can support some native features like the camera).
  • Near real-time and persistent comms, e.g. on a local network to the Internet of Things (IoT) devices, and when "offline".
  • Edge compute, e.g. saving cloud compute costs, performing time sensitive operations, or utilising on device machine learning capabilities.

These justifications are great examples of the tech we love to work with at San Digital and usually deliver a defined outcome.

Device support

Thinking about what types of devices, platforms and versions of operating systems to support can be a tricky mapping exercise. There may be quick wins for support, but it's often best to look at the audience's devices. Rarely is "we need to support all devices and platforms from day one" justified, or a sensible strategy.

To give some colour to the number of devices and platforms, Android alone has >10 major Android versions (with at least half still a general consideration for targeting). There is also Android TV and Android Wear โ€“ which target very different physical devices and may work in tandem with another device.

Analysing only mobile, Android is open-source meaning many mobile handset manufacturers choose to modify or enhance the operating system with their own "flavours", including app deployment. Marrying this complexity with device capabilities, such as screen size and the number of cameras, to motion and AI processors, highlights the sheer number of target devices and nuances to consider. Bad app reviews because a mobile device does not have a physical required capability is easily mitigated when fully understood.

Many devices

A common approach to this device matrix mayhem is to target a single device or platform as a rapid prototyping exercise. This loop can yield quick feedback from users or target audience, which sometimes proves there is no rationale for developing the app for production use and that you don't need an app! Having a clear but flexible plan to deploy for other platforms reduces the "big bang" day one release.

Tech and framework selection

Framework selection and tooling should always factor in the devices targeted and the specific features required, sometimes with considerations for existing team skills. A friend recently asked "what do you think of Flutter", to which there is no quick answer, there is no "killer framework" to rule them all, forever, for everyone. There's the old hybrid vs native debate too, with marketing such as "write once, run everywhere", if that's true, you probably don't need an app.

Continuous prototyping, deployment and feedback

Let's call it CPCDCF! (let's not, you can call it Agile if you want). It is critical to get a working prototype (even with stubbed functionality) into end-users' hands as fast as possible. We typically stub functionality that's seen as a commodity (e.g. login) and tackle the most challenging and unique features first. This approach de-risks any technology concerns by tackling them early and head-on while establishing business merits by testing with real users.

Fast feedback

To push apps to users quickly, we typically use one of our standard continuous delivery pipelines. Our clients can utilise from day one to accelerate development โ€“ more on this another time.

There are many tools available to monitor crash logs, engagement, and activities such as A/B testing โ€“ ensure the right products are selected and provide value (as some tools themselves require investment and tracking of that return).

Testing

OK, this article just got serious. Unit and integration testing can be completed mostly with virtual devices as part of CPCDCF pipelines. However, due to manufacturers' divergence and the fact physical devices can behave differently than emulators and simulators, there is no substitute for physical device testing.

App testing

Physical devices are costly to acquire, grow old quickly, and their resale value drops drastically (but the devices will need to be retained for legacy testing anyway). For context, I recently spoke to a company with tens of thousands of test devices!

There are many reasons for using real devices for testing:

  • Connection types and failure, apps transferring data (which is likely), will need to ensure service with any connection (whether via GRPS, 3G, 5G or WIFI etc.) and if that connection fails, handle elegantly. Connection type switching should also be tested, along with knowing some devices will have different or multiple connection possibilities.
  • 3rd party alerts and notifications, ensure that apps handle unexpected conditions, such as incoming phone calls, messages, emails, push notifications or low power/memory/disk space warnings.
  • Device performance and experience, when using a simulator running on a top-spec laptop, expect the version on a mobile or tablet device to be different. A real device's hardware and software features are never entirely replicated using an emulator either. Other devices with varying age also have inconsistent performance.

Maintenance

Once the app is finally released to whichever platform(s), the feedback cycle does not stop. With live feedback on the App Store or Google Play, it's even more essential to ensure feedback is responded to appropriately and taken into account.

In addition to feedback, keeping abreast of the latest developments in hardware, operating systems, trends, usage, and capabilities are integral to assessing future return on investment and the brand/security risk.

Keeping the lights on

Keeping the lights on isn't easy when the whack-a-mole switches and new lights keep dis/appearing.

In summary

The mobile, tablet and connected devices market continues to develop at high-speed, with new versions, platforms, and devices launched regularly. However, there is a lack of real innovation in the industry, meaning that updates are usually cosmetic.

Do you really need an app? Then figure out where you want to focus first. We'd love to help, especially with a sprinkling of IoT, AI or another emerging tech you also really need.

Jumping into the FHIR - type systems and objects

We have been doing a deep-dive on FHIR implementations and tooling following our initial FHIR investigation. A critical area of investigation for any system, particularly a large distributed system with many clients and peers that need longevity and guided evolution is its type system. Use of a strict type system can have many benefits - interoperability, governance, data quality, security, performance, developer experience, reduced component complexity and the ability to evolve services with confidence

Integrating with Events

The San Digital team has worked with numerous organisations in both the public and private sectors to transform their applications architecture into a flexible and business-focused model. Working with events at scale is key to maintaining individual teams' agility.

The process of building a mobile app

The team at San Digital has extensive experience developing apps for mobile devices, smartwatches, and smart TVs; using native and hybrid technologies (and everything in-between!) including using Rust for complex comms.

Low friction development environments

While setting up a sample project from an unnamed large vendor the other week I was disappointed by having to read large amounts of documentation and run various bits of script to install dependencies and set up infrastructure. We live in a world that has tools old (Make) and new (Docker) that can be combined to make onboarding engineers low or zero friction.

Cloud-native FHIR platforms

Continuing our series of posts on web protocols, we have been investigating more specialist protocols, in this case, "FHIR". We have produced a document based on our research, investigations and experience.

Team Structures

Multiple team structures can work to deliver software projects. There is no real one size fits all, however, there are common components that can be seen across different structures. At San Digital we believe that Engineer-led teams deliver great results for short duration high-impact projects.

Rules of the Road

This is called rules of the road but they aren't rules they're more guidelines, so they're rules until there is a good reason to ignore them.

Estimating and delivering defined outcomes

Recently there has been a shift away from time and materials projects towards defined outcomes, driven by various legislative changes, specifically IR35, but also cost control in the procurement function of larger organisations.

The San Digital Stack

San Digital has been designed as a remote first business from inception, on the assumption that it's easier to add offices later if they are necessary in an agile way. To work in collaborative way completely remotely takes a carefully thought out set of tools. Some of the ones that we use are really standard and some are a little more interesting.

Test driven design, or planning driven development

Design processes in most business software development resemble peer review or crowd-sourcing. A putative design is presented to peers, who will do their best to find problems while the originator of the design defends it against these challenges. Ideally, where they are demonstrated incorrect or incomplete the process will iterate and an updated design produced and defended.

A human view of computer vision at scale

Computers analysing and acting on what they see is not science fiction or even a new concept, it has been a reality of humankind's drive towards hyper-efficiency since around the time I was born.

Building scalable frontends

Scaling frontends is hard, actually scaling all codebases is hard, frontends just happen to be particularly visible and have a tighter feedback loop and a higher rate of change. As with all codebases, it is in principle possible to scale development through standards and integration processes, but these are a poor substitute for communication. Once development moves beyond the scope of a single team, either progress slows to take into account of different processes or implementations drift away from each other over time. Teams need to find a way to operate independently towards a goal.

Cross platform native mobile development with Rust

San Digital have extensive experience of mobile development and the use of Android as an embedded operating system. We treated android as a deployment target target for Rust firmware as well as writing our intricate real time communications component for both iOS and Android. This approach has advantages, you can maintain a single code base for a complicated communications layer, while also taking advantage of the full native capabilities of each platform

The evolution of web service protocols pt 2

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.

The evolution of web service protocols pt 1

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.