SSW Foursquare

Rules to Better Apps (mobile) - 8 Rules

Want to build a mobile application? Check SSW's Mobile Apps consulting page.

  1. Cross-platform Apps - Do you choose the right mobile framework?

    If you need to build a binary app (rather than a web app) that will run on multiple platforms (e.g. iOS, Android, macOS, Windows), you can either build and maintain multiple versions of the app - one for each platform - or you can use a cross-platform (cross compiler) framework to build one app that runs on all of them.

    Video: Mobile frameworks - Comparing the big guns: Ionic, Electron, React Native, Flutter and .NET MAUI (6 min)

    tutorial develop apps ios 2x
    Bad example - An app built in Swift can run on iOS and macOS (and Apple TV if you need it), but can't run on any other platforms

    winui3 addnewitem
    Bad example - An app built with WinUI can run on Windows, but can't run on any other platforms

    single project
    Good example - An app built with .NET MAUI can run on Windows, macOS, iOS, Android, and several others

    With many cross-platform frameworks available to suit every team and product, there is very little (or no) reason to build single-platform apps anymore. Even if you only initially intend to target a single platform, by using a cross-platform framework, you give yourself the opportunity of targeting additional platforms in the future.

    Understand the different approaches to cross-platform apps

    Cross-platform app frameworks generally come in 3 flavors: PWAs, web wrappers and native executables.

    PWAs are the fastest way to transform your website into a cross-platform app. However, you miss out on the native feel of having it in the app store.

    Web wrappers take a single page application written in (or transpiled to) JavaScript, and wrap them in a web view. The web view is just like a browser tab running the SPA on the device, but without the browser navigation buttons (so you can't go to a different address for example). Examples using this approach are Ionic or Electron.

    Web wrappers are an attractive option for teams with an existing JavaScript product. They can be quick to get up and running and leverage your existing skills. But they have significant limitations compared to native executable frameworks, particularly when it comes to accessing platform APIs and features, e.g. encryption, Bluetooth, AR APIs like ARKit (iOS) or ARCore (Android), etc.

    Web wrappers are good for standing up quick prototypes or PoCs, but are not recommended for long term supported solutions.

    Native executables (aka cross compiler) use a cross-platform API to build the app, but compile native binary executables for each target platform. Examples using this approach are .NET MAUI, Flutter or React Native.

    How to choose the right framework

    Developers building apps that target multiple platforms are in the ideal position. Several frameworks exist to fill this niche, meaning developers have the luxury of choosing the best fit for their needs. When choosing a cross-platform framework for your team, ask the following questions:

    • What skills do we already have?

      • For .NET teams, .NET MAUI is the best choice. It targets all the major platforms, it's performant, highly customisable, and leverages your existing skills. It also integrates well with your existing solution

    Video: Clean Architecture in .NET MAUI and ASP.NET Core with Matt Goldman (1 h 23 m)

    • For a React team, React Native may be a smoother transition. There's still a learning curve from React to React Native, but that curve may not be as steep for teams with existing React skills as for other teams.
    • For teams with good Angular knowledge, Ionic is worth considering (but as per above, not recommended for more than a quick prototype).
    • What platforms do we need to target?

      • Not all cross-platform framework targets every platform. Most will work on the 'core 4' (macOS, iOS, Android and Windows). .NET MAUI will also work on watchOS, wearOS and Tizen. If you need to target Linux and/or the web, you should consider Uno platform.
    • What level of 1st party support do we need?

      • Some of these frameworks are maintained by big tech companies. .NET MAUI for example is maintained by Microsoft, Flutter is maintained by Google, and React Native is maintained by Meta. However, they are not equal in terms of first party support. .NET MAUI, for example, has an Essentials API that provides access to many cross-platform hardware features, whereas many of these need to be loaded via 3rd party plugins in other frameworks.

    Developers are spoiled for choice; we have the luxury of choosing from many cross-platform frameworks. Most of them are very mature and stable, allowing us to build first-class apps.

    Frameworks - Pros and Cons

    Here is a nice graphic that gives a quick run-down of the pros and cons of different frameworks:

    cross platform apps pros and cons
    Figure: Mobile frameworks all have different strong suits


    ❌ Don't use a web wrapper. They might seem tempting as a quick option to start with, but you will cause yourself pain 👎🏻 down the line.

    1200px Ionic logo landscape svg
    Bad example - Web wrappers cause you pain in the long run

    ✅ Choose a native executable framework. They let you build the best apps in the long run.

    xplat native
    Good example - Choosing a native executable cross-platform framework lets you build the best apps with minimal pain 👍🏻

    ✅ Do choose .NET MAUI if your team and/or solution already use .NET.

    maui sln
    Great example - .NET MAUI is the best choice for .NET developers

  2. Do you build cross-platform apps?

    cross platform options
    Figure: There are many cross-platform technology options available

    If you're building installable binary apps (as opposed to web apps), it makes sense to use a cross-platform framework so that you don’t need to maintain multiple code bases.

    Writing apps in a single-platform language or framework can lead to fragmentation and technical debt, while writing your app once using a cross-platform technology is the best way to apply DRY to your app as a whole.

    Cross-platform approaches

    There are two approaches to building cross-platform apps. One is to write a single page application (SPA) and use a wrapper technology like Cordova or Electron to turn your SPA into an installable app. This is a good approach if you already have a fully functioning web app and want it to be available for users to install via an app store.

    The other approach is to use an API that is a single, cross-platform abstraction that compiles to native code executable on your target platforms. This is the approach taken by .NET MAUI (previously Xamarin), Flutter, and React Native.

    When to use a web wrapper

    Use a web wrapper, like Cordova or Electron, if your SPA is already built and offers all (or almost all) of the functionality that you want your app to provide.

    When to use an abstracted cross-platform API

    Web wrapper technologies are good for apps that also work as web apps (and potentially already exist as web apps), but they also suffer from some of the limitations of web apps.

    If you need multi-threading, or access to hardware features, platform or operating system APIs or system processes, then using an abstracted cross-platform API is a better option.

    Which cross-platform framework to choose

    If you need access to specific platform APIs, you may not find them available in the web wrapper options (and almost certainly not via 1st party support). In this case, you could rule out using a web wrapper.

    If you already have a .NET development team and your solution is built on .NET, it makes sense to use .NET MAUI. .NET MAUI lets you write your UI in XAML or Blazor, so if you already have a Blazor web solution, you can share your UI controls in a Razor Class Library. You could also share other things like DTOs and authentication logic between Blazor, ASP.NET Core, and .NET MAUI apps.

    If you already have a strong React team, it may make sense to use React Native. There is a bit of a learning curve to go from React to React Native, but it still builds upon your team’s existing skills.

    Choose Flutter if you like Dart.

  3. Do you have a PWA (Progressive Web App)?

    Progressive Web Apps have transformed the mobile web practices to provide a native app like experiences for the users. They work just like native apps and include features such as smoother navigations, offline modes and push notifications, but are much more economical and do not use the device storage.

    Progressive Web Apps are reliable which means they load instantly and the performance isn't compromised even if the network is shaky.

    On the mobile the 'Add to homescreen' option can be used to create an icon on you phone.

    PWAs also account for higher user engagements and conversions which is probably why many organizations are now adapting this technology to grow their businesses.

    In order to be a PWA, your app should:

    • Use a responsive design - So it works on desktop or mobile
    • Be fast - Use a service worker to precache the app resources (HTML, CSS, JavaScript, images) needed to run, and cache the data at runtime to improve performance
    • Be installable - Use a web app manifest and the beforeinstallprompt event to notify the user that it is installable

    Examples of Progressive Web Apps can be seen at 10 Best Progressive Web Apps.

    pwa bad example
    Figure: Bad example - Aliexpress get a mark of 6/12 (see tooltip) and cannot be used as a PWA

    pwa example
    Figure: Accessing a PWA on your mobile will prompt adding it on your Home screen. E.g.

    You can check the Progressive Web App score of your application using Chrome's Developer tools.

    Note: See how to generate a PWA report on Run Lighthouse in Chrome DevTools.

    PWA tools
    Figure: Good example - Aim for a good Progressive Web App score

  4. Do you know how to get mobile config to your users?

    Getting configuration into the hands of mobile app users can be challenging, and you need to make it as seamless as possible. For web apps, this usually isn't a problem; for any given instance, you go to that instance's URL. But for mobile apps, they often don't even know which instance to connect to.

    When all the users of your app will need a single shared configuration, that config can ship with your app. But when your app needs per-user, per-tenant, or per instance config, that can be tricky.

    Check out the video above for the best way to magically provide your users with configuration. And for a write-up, check out Automagic Tenant Config for Mobile Apps.

  5. Do you know how to monetize apps?

    You don't have to charge users for your software. In fact, even free apps and games are designed to make money. Do you know the best way to monetize your apps?

    Apps make money in all sorts of ways, even the 'free' ones. You need to choose the right monetization model for your apps depending on its functionality and audience.

    Free vs Paid Apps

    Some apps require a form of payment, meaning you must pay for the app before you can use it. Others are 'free', meaning you can use the software, and all its features, without paying for it. These apps make money in other ways. The middle ground is called 'freemium', which is where you get the basic app or game for free, but need to pay to access advanced features.

    Payment Models

    Whether your app is paid up front or 'freemium', if you need to collect money at some point from your users, there are a few ways to do it:

    One-time fee

    This is the traditional approach, where you set a price for your app or game, and users must buy it before they can use it. This might be the right approach for you if:

    • Your product is a AAA gaming title
    • Your product is a useful, but not essential, productivity tool
    • Your product is not a SaaS product (one-off payments are difficult to reconcile against ongoing cloud and hosting costs)

    Figure: Good example - The Legend of Engadine on iOS and Android is free to play, but a one-time purchase unlocks premium features.

    More information: The Legend of Engadine official website.

    One-time fees work with either paid apps or 'freemium' apps; users can either buy the app up-front or use the app for free, and pay to unlock premium features.

    Subscription fee

    Subscriptions have become much more popular, even for traditional desktop software. Rather than pay a one-time fee, users pay a recurring monthly or annual fee to use the software. This might be the right approach for you if:

    • Your product is a SaaS product
    • Your product is likely to get recurring regular use without you needing to continually drive engagement (e.g. An essential, or at least high value, productivity tool)
    • Your product has other ongoing maintenance costs (e.g. Content development)

    Figure: Good example - Microsoft 365 is available to home and business users for a low recurring cost

    Microsoft 365 (formerly Office 365) is a suite of productivity tools that run on mobile, desktop and web. With a subscription, users get access to these apps and the connected services that tie them together in the cloud, and the cost over a 3 year period (the average time between desktop releases before Office 365) is lower than the cost of a desktop license amortized over the same period.


    Micro-transactions is the practice of continually charging comparatively small amounts of money over a long period of time. Micro-transactions can be a great fit if used responsibly, but are considered unethical when combined with nefarious practices like dark patterns, 'pay-to-win' or exploiting gambling addition.

    For these reasons, micro-transactions are increasingly subject to scrutiny from governments and regulators. This might be the right approach for you if:

    • You are certain you have an ethical model for micro-transactions
    • You are not exploiting minors or people with a gambling addiction
    • You have a genuine use case for providing small purchases in your app that can bring joy to your users

    Video: Bad example - Pokemon Go, one of the most successful mobile apps of all time, combines the freemium model with micro-transactions to exploit a vulnerable subset of users. It's incredibly effective, but unethical

    Monetizing free apps

    Most free apps are designed to make money too. There are of course exceptions (for example apps created by government departments or agencies, such as the Service NSW app), but generally most apps need to generate revenue; even the free ones. Free apps and games can still make money, and these are some of the ways that they do so.

    Ad revenue

    The most common way for free apps and games to make money is through advertising. Ads are shown to users in the app or game, either as banners that are constantly there, or as interstitial ads (ads that appear between levels or interactions and block the rest of the app or game until they are finished). In-app advertising is still a significant revenue stream, but is considered less-professional or less-polished for certain categories of games or apps. This might be the right approach for you if:

    • Your app is a mobile or web app (desktop users are less tolerant of in-app ads)
    • Your app has a strong re-use strategy (e.g., 'addictive' games, or diary-like apps that require or support daily use)
    • Your target demographic is less likely to pay to use an app (and less bothered by ads)

    Note: If you include ads in your app, you should consider a freemium model, so that users can pay to remove them.

    Figure: Good example - Cronometer offers a paid and free tier. On the free tier, users see ads, but can pay to remove them

    Some apps provide the app for free, but content within the app is paid for. This is a good model for content creators, or an excellent model for content platforms with user generated content. This might be the right approach for you if:

    • Your content is your product, and your app is just a delivery vessel
    • You have a lot of user generated content (and your users want to monetize that content too)
    • You are regularly adding new content to your app

    Figure: Good example - The Zinio app is a digital magazine platform. The app is free, but users pay to subscribe to a magazine or to purchase individual issues

    Loss leader

    This approach is uncommon, but occasionally an app developer might want to give an app away for free to entice users to try another, revenue generating app. Examples include showcase apps for UI control library vendors, like Syncfusion, Telerik or Grial Kit. This might be the right approach for you if:

    • Your app is used to demonstrate expertise
    • Your app is a portal for a different subscription product
    • Your app has low or no ongoing maintenance or support/infrastructure costs

    Data mining

    Some apps offer functionality to users for free, and in exchange gather information about users for sale to advertisers or other interested parties. Tiktok, one of the most successful apps in the world, is a surveillance app that mines data about users, their connections, and environment. Some apps are more extreme than others, and the breadth and depth of data acquisition can vary.

    NOTE: This is not an ethical approach to monetizing apps and is not an approach you should use.

    Resource utilization

    Sometimes an app will use users' resources in the background. This is cool for things like SETI@Home, a screensaver that uses an idle computer's CPU to crunch numbers in the search for alien life, but less cool for apps that install an agent into a user's browser and use it to mine cryptocurrency.

    NOTE: This is not an ethical approach to monetizing apps and is not an approach you should use.

  6. iOS - Do you know how to optimise your test and release deployments?

    A common approach is to submit your app to Testflight, wait for user feedback, then submit for App Store release. The problem with this approach is that your release cycle can be significantly impacted by Apple's review schedule. App Store and Testflight reviews can be very quick, but can also take up to 3 weeks!

    A better process is to submit your build for Testflight and Release simultaneously.


    1. Upload your build to App Store Connect.
    2. When automated processing is completed (scanning of the assemblies usually takes less than an hour), you will receive an email confirmation, open Testflight and submit for approval.
    3. Immediately, prepare your app for submission to the App Store (by completing the appropriate metadata, e.g. new features or fixes in this version). Important : Set to Manual Release so that your app does not get automatically released untested.
    4. If you are using external or public users, your build must be approved by Apple for testing. Note: If you are using internal testers only (App Store Connect users), they can begin testing immediately.
    5. Once both your App Store and Testflight builds have been approved, get a Test Pass via the Test Please process - see Rules to Successful Projects: Do you conduct a "test please" internally and then with the client?

    Tip for Mid-Sprint Releases : If its an internal app, you can accelarate the Test Please process by asking someone with an iPhone to test straight away via Testflight. Tip for End of Sprint Releases: Get the Testflight and Release submissions approved in preparation for your Sprint Review. You can then demo your release to the Product Owner and be ready to release your Product Increment after the Sprint Review. 6. You can now release your app as soon as you are ready. In App Store Connect click Release to make your latest build publicly available in the App Store.

    bad example new

    Figure: Bad Example - v1.7 is "Waiting for Review" in Testflight but only v1.6 is submitted to the App Store. This can introduce delays of 3 weeks.

    good example new

    Figure: Good Example - v1.7 has been submitted to Testflight and App Store at the same time - also "Waiting for Review", but your build will be ready to release as soon as testing has passed

  7. Do you have a device policy for your mobile dev teams?

    Lack of access to physical devices for testing can significantly impact mobile development. Issues can arise that you don't know about until UAT. Do you know the best way to mitigate this and avoid spiraling development costs?

    Mobile development is acutely prone to the "works on my machine" problem. Features that work on an emulator or simulator may not work as expected when running on a physical device, or features that work on iOS may not work on Android, or vice versa.

    It's important to ensure that features and UI work as expected on the devices that your end users will be running the app on.

    Tip Ensure that testing on at least one physical device on each OS you are targeting is part of your definition of done.

    You need to choose the right option to ensure that all team members have access to the required devices without incurring unnecessary expenses.

    Option 1: Developers use their own devices

    The easiest approach is just to let your developers use their own devices for testing. This can work well at the start but leads to problems if you divide your work between devs with access to different devices.


    1. Developer A works on Feature 1. They test it on their Android phone, it works, so they open a PR and merge it.
    2. Developer B works on Feature 2. They test it on their iOS phone, it works, so they open a PR and merge it.
    3. At the end of the Sprint, a build is sent to testers for UAT.
    4. Feature 1 doesn't work on iOS, and Feature 2 doesn't work on Android. :::

    Option 2: Use a cloud based service

    Cloud based options like BrowserStack are awesome, as they give access to a range of devices that can be used for testing.

    Using something like BrowserStack is not a good option for development, as it introduces substantial latency to your inner development loop.

    However, it is an awesome tool for testing and can be incorporated into your release cycle, as an automated test tool.

    Option 3: Create a device policy

    Having test devices available to your developers is the best option to ensure they can test their work on the hardware and OSes that your clients will need.

    Note: If your client requires a specific device or a specific hardware version for you to test on, they should supply these to your development team.

    You will need to create your policy according to your organization's needs, but the following high-level steps are usually applicable to everyone:

    1. For each project, identify the minimum number of physical devices required to support all the necessary features and functionality.
    2. Create a device sharing policy that outlines the process for reserving and using devices, ensuring that all team members have access to the devices they need.
    3. Encourage team members to purchase their own devices that are compatible with the projects they work on. The company can provide a partial reimbursement or a stipend for the purchase of the device.
    4. Utilize device emulators and simulators to test apps on devices that are not physically available to the team.
    5. Regularly review and update the list of supported devices to reflect changes in the market.

    Important: It's essential to register your devices in your company's asset catalogue and enrol them in your MDM solution.

  8. Testing - Do you test .NET MAUI apps on different devices?

    .NET MAUI (Multi-platform App UI) is a framework that enables developers to create cross-platform applications for different devices efficiently. However, the efficiency of this framework could mean nothing if the developed apps are not tested on various devices, especially the older once.

    Testing mobile apps on different devices helps in ensuring compatibility across multiple platforms and versions. Different devices have unique hardware, operating systems, and screen resolutions. Therefore, testing an app on different devices ensures that the app can work efficiently on all platforms. For example, an app that runs smoothly on an Android device might be incompatible with an iPhone's operating system, resulting in a suboptimal user experience and potential bugs.

    Option 1: Use emulators

    There are several ways that developers can test mobile apps on different devices to ensure that they are running smoothly and providing the best user experience possible. One approach is to use emulators, which are programs that simulate the behaviour of specific devices and operating systems. These emulators can be very helpful for testing basic functionality, but they may not accurately represent all aspects of the user experience, such as touch sensitivity and screen size.

    Some of the popular .NET MAUI emulator apps are:

    • iOS Simulator - Allows developers to preview their apps on iOS and macOS devices
    • Android Emulator - Allows developers to test their apps on various Android devices
    • Tizen Simulator - Allows developers to test their apps on Tizen devices

    Option 2: Use a cloud-based service

    Testing mobile apps with cloud-based services like BrowserStack offers several advantages to developers. Firstly, it allows them to easily access a wide range of real devices and browsers for testing, enabling comprehensive and efficient app evaluation. The developers can run tests on multiple operating systems, screen sizes, and resolutions, ensuring that their MAUI app performs seamlessly across various platforms. Additionally, these cloud-based services provide instant access to devices, eliminating the need for physical hardware and saving both time and resources. However, reliance on such cloud-based services introduces substantial latency to your inner development loop, and might not be the best option for development.

    Apart from BrowserStack, there are several services that offer similar functionality:

    • Sauce Labs
    • LambdaTest
    • Experitest
    • CrossBrowserTesting

    Another effective way to test mobile apps on different devices is to use real hardware. This allows developers to see how the app performs on a variety of devices with different screen sizes, processing power, and other specifications. One approach is to borrow or purchase multiple devices to test on, but this can be time-consuming and expensive. The better way is to have a device policy for your mobile dev teams.

    Regardless of the approach used, it is important to test on a variety of devices to ensure that the app works well for all users. This can include testing on both iOS and Android devices, as well as different versions of each device and operating system. Additionally, testing on different screen resolutions and aspect ratios can help identify any design issues that may arise. By thoroughly testing on a range of devices, developers can ensure that their MAUI app is high-quality, user-friendly, and reliable across all platforms.

We open source. Powered by GitHub