So much has changed when it comes to building apps since 2008 when Apple first launched the App Store - and I've been in the app-building game since then so you'll have to take my word for it!
I head up the mobile app development hub here at A Squared. We're a Brighton based team of 15 specialising in React and React Native front-end development. I joined the team in February 2020 and in my first 6 months we built 6 mobile apps.
Yes 6 apps in 6 months!
I used to build apps that only worked on Apple devices coding natively in Objective-C and Swift. When the App Store first launched this was the only option. You had to pick - Apple or Google, or both if you had lots of money and resource.
Write once, run everywhere
Apple encourages developers to code apps in Objective-C or Swift. Those apps will only ever work on Apple devices - iPhones or iPads. Likewise, Google gives developers the tools to code in Java or Kotlin to ship Android-only. But there's a 3rd way. We now have the option to write once, run everywhere using middleware technologies that have evolved and matured especially in recent years. The front-runner options are:
- React Native (open-source, originally built by Facebook)
- Flutter (closed-source, built by Google)
- Xamarin (maintained by Microsoft)
- Ionic (previously PhoneGap)
Five years ago I, along with many other native, single-platform developers would argue that apps built in these middleware frameworks were inferior to building native and pure. And we had a point - middleware apps would not feel as performant as native apps, i.e. scrolling and screen transitions would be sluggish and not feel right to users. And the general look and feel of the user interface would never quite match native Android or iOS SDK UIs.
Why should you listen to me
Well, I've created a lot of apps - I even wrote a book on how to build iPhone apps back in 2012 (damn I'm old!)
I’ve also launched a lot of my own apps some of which have seen millions of downloads (ok brag over).
But my core point is that I'm not just a developer. I'm a founder. I see the business side as well as the code purity. Being an iOS-only developer has always limited my audience to iPhone-only users. A few years ago I decided to make the switch to React Native meaning my apps would also run on Android phones but there was a major downside - I'd have to re-train! This is probably the main obstacle that puts off most experienced native coders from switching.
However, if you're a native iOS or Android Dev thinking of making the leap I seriously recommend doing so and quickly! All of that expertise in your particular native platform will not be wasted. The great thing about one of these middle-ware frameworks is that you can also write native code alongside shared RN framework code. That's why React Native got my vote and I went on to bet my career on that horse! 🏇
Re-training in React Native
From a business perspective this is a no-brainer. You’re basically doubling your potential market and reducing your development costs and time.
Performance is no longer a valid argument against using middleware mobile frameworks. React Native, and the alternatives, have matured, mobile phones are now faster and more powerful and any performance differences are now virtually impossible to spot. It's also incredibly easy to code up custom UI - I find flexbox in React Native much more intuitive than auto layout in iOS and as a result, I can knock out custom user interfaces faster than if I was native only and of course I get then Android app for free(ish!)
In a nutshell, the main reasons I chose React Native were:
1. Maturity (not my own!)
React Native's been around since 2014 and is constantly improved upon and maintained by an active community and by Facebook developers.
2. Foundations - it's built on React
React Native is dependent on React. React is the most popular framework for developing web applications. If you're moving from native mobile development to React Native I'd recommend first mastering React. Learning how application state and user interface lifecycle/rendering works is a core concept you'll need to get your head around first. Or if you're a web developer looking to move into React Native you may have already mastered the joys of React for web. For me, learning React first has led to a massive added win - I can now code web apps super fast too!
3. Mixing in Native Code
4. Speed of Development
Quite honestly, if I were asked to develop an iOS-only app from scratch today I’d definitely choose React Native over native Swift – and that’s from a developer with 5 years Swift experience!
How we build apps fast 🚀
Making bad choices in tech can be very expensive and damaging to a business. And with so many options available it’s easy to become lost in the choices.
Although we are a multi-disciplined dev team here at A Squared we've chosen to fine-tune our expertise by focusing 100% on React, React Native and Firebase which combined enables us to deliver scalable, beautiful, responsive mobile and web apps at pace.
Here are some of the ways that we're working with these three technologies to develop great apps at pace. 🙌
1. A single code-base in React Native
Maintaining multiple codebases are a thing of the past. Using the React Native Cli we'll create a new project that will auto-generate ios and android sub-projects within it. So from the get-go as a native iOS developer, you'll find that you can immediately test and run your new project directly from Xcode in the native iOS Simulator or from Android Studio in the emulator of your choosing. Coming from a native background this is preferable to me than using React Native's Expo option which I feel is aimed more at Web Devs.
By using the React Native Cli as a starting point for a project I keep my options open if I need to delve into native code. The six apps that we've developed recently have needed almost zero native custom code to be written. That's a really important point - before I started working hands-on with React Native I'd heard rumours that one would need to write as much as 30% extra conditional code - i.e. if this is Android run this code or for iPhone run this. I've not found that to be the case at all - maybe it's because we use the latest, most stable versions of React Native in our apps. Plus I think we've made good choices with the 3rd party React Native code libraries we've used in our apps, which will often deal with much of the heavy lifting for you and are a joy to work with - here's looking at you React Navigation my friend!
3. Templates and reusable code
If you wanted to start a brand new React Native project using TypeScript, as highlighted here you could kick start your project from a minimal React Native TypeScript template:
npx react-native init AwesomeTSProject --template react-native-template-typescript
But did you know you can build your own starter React Native templates? That's powerful. It allows us to evolve a great internal starting template that can be reused for pretty much every new mobile app project we work on. How many mobile apps require push notifications? How many require navigation? Splash screen? Multi-language support? We've built up our own awesome starting template so we're not wasting time writing the same core functionality time and time again for each client. It's a serious time-saver.
4. Firebase: Backend-as-a-Service
Most apps will require some kind of remote database. They might require the ability for users of those apps to login, sign-up, communicate with one another via shared data or messaging. These are a few common feature examples that would require a "backend" server-side application.
Many companies will choose to build their own custom backend and will need to hire in server-side developers - often at great cost - to achieve this. In addition to the expense of building custom server-side applications and APIs there can be great risk in taking this route.
Most tech entrepreneurs will have horror stories of when their site went down or the database got wiped - ouch! Now I'm not suggesting that Firebase is 100% safe from attack. But I am suggesting that the top developers at Google who have spent many years developing the array of great server-side tools that make Firebase are likely to have done a far better job than any freelancer or out-sourced agency will ever do if they propose writing a custom backend! Firebase was launched in 2011 and is owned and actively maintained by Google. It is a suite of robust, server-side tools that will manage your database, synchronisation of data between app and server, push notifications, user authentication to name but a few.
We use Firebase for everything. Even hosting. It's the perfect backend solution for most clients. Once a client's Google account is setup we can build their dream app and or website and power the backend from their own Firebase project. We can access and develop the project and the client has full access to see all of the stats and data in their app on the server-side.
Firebase starts with a free tier which means we can build your website or app that comes with free hosting and scalability that you'll only start paying for if it becomes a hit!
5. Automated Tests
Automated Tests mimic user flows in an app or website. So, for example, you might have a test that automates the steps required for a brand new user of your app to sign-up for a new account. Running this test with Appium will first reset the iOS or Android simulator clearing any cached data and then create a fresh install of the app. It will then automatically tap the buttons or simulate the user gestures to navigate to the sign-up screen, enter text into the sign-up form, tap the sign-up button, and await a successfully newly created account. If any of the steps fail the test fails. We can set these tests to run automatically in the cloud which is invaluable when it comes to catching issues like breaking app updates not being backward compatible.
We've also coded our own lightweight mock server which is automatically set up to return errors or simulate timeouts so that the test team can check that the developers have covered all bases.
Another great use case for the mock server is when we're working with one of our SaaS clients like Breathe HR. We provide a lot of front-end development and test resource for Breathe and their own internal dev team keep responsibility for their server-side API. During one of these collaborative projects occasionally we'll be working on a feature where no API exists yet. Using our mock server we can create simulated API responses to any type of API call and this is a really effective way of us being able to continue building front-end apps fast!
6. AppCenter: Build & Deploy in the Cloud
Another tool that features regularly in our workflow is AppCenter. AppCenter, originally HockeyApp and acquired by Microsoft in 2014, is a fantastic, affordable tool that we use for automated builds and deployment when developing apps in a team.
AppCenter enables us to set up automated separate iOS and Android builds and also to distribute updates to clients during development. It integrates sweetly with Github and Gitlab and we'll typically set up staging and iteration branches that auto-build whenever new features are merged, post code review approval.
Couple of Case Studies
Hopefully that's given you a little top-level insight into the techniques we're using but here's a couple of client case studies that illustrate some of those techniques put into practice.
Teeth.app • contactless dental journey
Teeth.app is a genius idea from one of our start-up clients who are trying to modernise the dental industry and help dental practices resume business in the new world that's currently adapting to the impact of Covid-19.
Our client - 2 dentists came to us with a vision to build an app to address 2 main pain points:
- Enable dental practices to manage appointments and check-in patients remotely and contact-free via an app - like a digital waiting room.
- Enable patients to search for dental appointments at any dental surgery in their vicinity.
We approached the brief with a lean start-up mentality and built our client an MVP (minimum viable product) app. The app we delivered was actually five apps in one:
- Dentist app on iOS
- Dentist app on Android
- Patient app on iOS
- Patient app on Android
- Backend dashboard web app.
The budget was extremely tight and at first, I didn't think we were going to be able to build them anything like what they wanted. But we achieved the impossible and delivered:
- An iteration of design and discovery
- Screen designs for all apps
- The development of all 5 MVP apps
The dentist apps enable new dental practices to sign up, manage and share appointments and the patient apps are set up to handle multiple dental appointments and provide push notification reminders and the contactless check-in process.
The Teeth.app and Teeth.dentist apps provided an MVP that helped our client secure their next big round of funding. Watch this space for the future of the dental industry!
- React Native - one code-base with four targets (apps)
- Firebase - authentication, push notifications, practices and appointments database, hosting and cloud functions.
BP Passport • the world’s easiest to use blood pressure app ❤️
BP Passport is a beautiful, easy to use blood pressure app developed to help prevent millions of deaths from cardiovascular disease in third world countries like India.
Our client Resolve to Save Lives is on a mission to save 100 million lives globally. The BP Passport app has became a core part of that mission. The app is translated into over 10 languages including Hindi, Bengali, Punjabi.
Unlike the UK and the US in India many patients have no medical history records. Globally hypertension is one of the most common ways that people die. The BP Passport app was designed to be used by the 250,000 patients that Resolve to Save Lives are actively helping to monitor and regulate their blood pressure.
Our client pivoted during the development of BP Passport and also decided to make the app available to anyone as a handy BP monitoring app. Not just their patients in the 3rd world. This was a really cool move and on a personal note my dad is also now using BP Passport to track his BPs and the handy daily medication reminders feature we built in. I think it's the only app of mine he's ever used 😂😂
- React Native - one code-base with two targets - Android and iOS. Android has about 99% market share in India so this was pretty important!
- Redux and Redux Persist- the app works 100% offline and doesn't share any personal data.
- AppCenter for regular internal and client builds
Happy Clients, Happy Team
I think it's also worth touching on how we work with our clients. Anthony has devised a simple but super-smart framework for success as an agency.
Successful digital agencies, like most businesses, will be the agencies that keep their clients happy and track customer satisfaction. Those agencies will win recurring work and grow, making new clients from the recommendations of those happy clients. Easy huh?!
At A Squared we deliver regular app build updates to our clients in short one or two week iterations. At the beginning of each iteration we use an agile process to plan and estimate the work we intend to deliver in that iteration. This is totally transparent to our clients. And after every iteration we follow up with a satisfaction feedback client survey.
Not only does this keep us constantly on top of client satisfaction there's an additional perk that the whole team all get a financial bonus for super satisfied clients.
Our company gives back about 50% profit to the team. That's an indication of our client satisfaction levels 🔥
If you'd like to become a client then reach out to me directly via LinkedIn here.
Or if you're a TypeScript whizz who loves to stay at the forefront of tech let's talk about you joining the team.