Secret ingredients to quality software

SSW Foursquare

Rules to Better Apps (mobile) - 3 Rules

If you still need help, visit our Mobile App Development consulting page and book in a consultant.

  1. 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 , using 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 , using 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

    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

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

  2. Do you know how to monetize apps?

    Do you know free games are designed to make money? See the good and bad examples:

    Bad example: paid apps

    Good example: free apps with in-app purchases

    Bad example: paid with currency

    Good example: paid with abstract currency

    Bad example: treat all customers the same

    Good example: detect when a customer might leave and offer them incentives

    Bad example: same prices for everyone

    Good example: capture data eg. What device and do data mining to set different prices

    how to monetize
    Figure: some apps charge more based on the device you are using

    how to monetize 2
    Figure: know app developers make most of their in-app purchases from the whales 🐳

  3. 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.

    1. 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

We open source. Powered by GitHub