Rules to Better Apps (mobile)
If you still need help, visit our Mobile App Development consulting page and book in a consultant.
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 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 https://mofluid.com/blog/10-best-progressive-web-apps.
- Figure: Bad Example - aliexpress get a mark of 6/12 (see tooltip) and cannot be used as a PWA
- Figure: Accessing a PWA on your mobile will prompt adding it on your Home screen. E.g. https://blog.mikemjharris.com
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
- Figure: Good Example - Aim for a good Progressive Web App score
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
- Figure: some apps charge more based on the device you are using
- Figure: know app developers make most of their in-app purchases from the whales 🐳
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.
- Upload your build to App Store Connect.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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