Steer73

Contact Us
Steer73 1
BY STEER73

How to Reduce the Cost of Building a Mobile App Using Shared Resources

At Steer73, we build apps for both SME’s and global enterprises. There hasn’t yet been a project where budget wasn’t a consideration. Our core role is to help clients spend the least amount of money to get their desired outcome.

One of the primary ways to reduce cost, without compromising on quality, is through the use of shared resources, maximising re-use wherever possible.

Often this complex topic is reduced to whether to build native apps separately for iOS and Android or to go cross-platform. It isn’t as binary as this.

We sat down with our CTO, Phil Marland, to understand how he frames the decision for our clients.

The summary… there are levels to this, ranging from build once, deploy twice, to having a completely bespoke solution with zero re-use of any resources. The right choice is dependent on the project requirements and the levels can be broken down roughly as follows :

Level 0: 100% native, bespoke apps built using native tools (Native)

Level 1: Cross-platform tools and shared resources but bespoke UX for each platform (Xamarin Native)

Level 2: Consistent app with platform-specific customisations where needed (.NET MAUI or Flutter)

Level 3: Build-once, deploy-twice (e.g. simple wrapped web-apps) (Cordova)

Level 0: 100% native, bespoke apps built using native tools (Native)

Level of shared resource— Zero utilisation of shared resources. Everything is produced in a siloed fashion and developed using the platforms native technologies such as Swift for iOS and Kotlin for Android. Separate teams, with distinct skills, work on a separate product in their own ways. There is zero re-usability across the Android and iOS teams.

As an example, code modules such as data access, network communication etc are not shared between platforms. The business logic and/or algorithms are developed independently for each platform. There is no effort to create shared libraries or modules.

Cost— Very high

Outcome— Beautiful Native experiences but at a high cost. This cost is broken into a few key areas, all of which can significantly reduce the ROI your app delivers:

Cost to build: It's the most inefficient way to build apps. Team costs, tooling cost and infrastructure costs will be as high as they can be.

Cost of ownership: You’re maintaining two, completely separate digital products, each with their own cost of ownership.

Time to market & technical debt: The added complexity, workload and cost of maintaining two apps means that there are higher barriers to adding new features. For almost all organisations, this will mean apps that are slower to react to user, market and organisational requirements.

Maintaining continuity across platforms can also be a challenge, as releases may need to be synchronised across both apps. Delays to one can be caused by an issue with the other.

Level 1: Cross-platform tools and shared resources but bespoke UX for each platform (Xamarin Native)

Level of shared resource— Minimal. At this level, the teams start to share knowledge. They might also start to share some assets including some code and designs.

The team will be using cross-platform tools, such as Xamarin Native, where a single programming language can be used to build solutions for different platforms. It’s important to note that this is different from build-once, deploy-twice solutions (detailed later) because although the language is common, the implementation is specific.

Sharing resources and using a common language removes the need for these assets to be produced from scratch, twice. An example could be assets like messaging and copy. There could be a shared library that is used across both apps.

Cost— Still relatively high but there will likely be some good savings in certain areas. It's certainly a much more efficient way of building apps than levels 0.

Outcome: Cost is still relatively high and there has probably been little (if any) compromise on native ability. However, some cost savings and efficiencies have stated to be introduced. Workload is being reduced, which for some areas, can reduce the barriers for new features/changes. This is worth considering for projects where the finished product needs to be of the highest possible user-experience quality, but there’s evidence that solutions like this may become less and less necessary given the improvements in Level 2 technologies detailed below.

Level 2: Consistent app with platform-specific customisations where needed (.NET MAUI or Flutter)

Level of shared resource— High. At this level, the vast majority of the applications are common. However, there is some customisation where it’s most needed. As an example, back navigation. iOS uses a back button within the app UI (usually in the top left) or a gesture like swiping from the left of the screen. Typically, this hasn’t been the case with Android devices, which have a dedicated back button in the lower part of the screen. This is an example of something that would need to be custom for each app. With platforms like this, it’s usually necessary to do some custom work to support either complex or unusual device capabilities, or to support third-party packages and SDKs that may be needed. For example payment processing or image recognition.

Cost— Significantly reduced. Most code and resources are now only built once and deployed across both platforms. There are many good, free, opensource platforms for delivering cross-platform apps such as .NET MAUI. Both the time to build and the cost of ownership/team needed should be significantly reduced. Savings of 50%+ can potentially be unlocked vs level 0 implementation.

Outcome— Cost of build and ownership have been significantly reduced. Ease of ownership is also much higher, which can lead to more agile, rapid development of new features. However, some compromises might have been made in terms of taking full advantage of the features and capabilities of each platform. In addition, if your app is extremely graphics-intensive, you may have had to sacrifice performance.

*Note: Due to the improvements in tooling, it’s now very achievable to produce extremely high-quality, native-feeling apps for different platforms using cross-platform tooling. This is making the case for level 1 weaker. Whereas once there were a lot more examples of ‘native features’ that required a highly bespoke approach to designing and building the app, now most users will be unable to tell that an app was built using a cross-platform tool.

Level 3: Build-once, deploy twice (e.g. Simple wrapped web-apps) (Cordova)

Level of shared resource— Everything is shared. Built once, deployed across both platforms.

Cost— Lowest

Outcome— Unlikely to be good. At this level, things have been taken too far and big compromises have been made. The apps, by definition, are not built for the operating system they live on and users will usually be able to tell. Although cost has likely been low, return on investment will probably be disappointing.

What level is right for your project?

This, as with any technology decision, is dependent on your business, your requirements and what your app actually does. Some questions to help get you on your way...

How complex is your app in terms of UI/UX, features, and functionality?

Are there any platform-specific or hardware-dependent requirements?

Does your app require high performance, especially for graphics or real-time processing?

What programming languages and frameworks are your developers experienced with, if any?

Given what you’re trying to do, how much code can realistically be shared across platforms?

How are your requirements going to change over time?

How do you plan on handling platform updates, bug fixes, and feature additions over time?

Are there specific third-party libraries or plugins that your app relies on and are these libraries available and well-supported in the chosen cross-platform ecosystem?