React Native Tips: How to optimize assets for better performance

Written by Samitha Nanayakkara – Associate Tech Lead at Calcey

React Native is a favorite of mobile app developers everywhere as it allows you to build multi-platform apps using a single codebase.

However, as the complexity of an app increases, so does its size. Unoptimized code and assets lead to larger apps which consume valuable storage space on the devices they’re installed. Larger apps also mean slower downloads, and it could lead to users abandoning the app altogether out of frustration.
That is why it is vital to optimize assets such as images and animations. Doing so can drastically reduce app size and improve overall performance.

A developer can

  • Optimize the size of images AND
  • Optimize the resolution of images

Optimizing the size of images

PNG images are popular with React Native app developers due to their efficient rendering (compared to SVG) and high quality (compared to JPEG). However, these images can sometimes negatively impact the app’s performance. To address this issue, developers can use ‘TinyPNG’ to optimize and compress their PNG images without sacrificing quality. TinyPNG is a web service that uses advanced lossless compression techniques to reduce the file size of PNG images.

For one of our projects at Calcey, we were able to reduce the size of the production app by 67.43MB solely by optimizing image size. 

For macOS users, a convenient tool called “TinyPNG4Mac” can be installed to optimize an entire folder of images quickly with a simple drag and drop. TinyPNG4Mac can be a helpful tool in streamlining the image optimization process and reducing the size of the PNG images used in a React Native app.

Optimizing the resolution of images

Services such as TinyPNG won’t be very effective if high-res images are being used. 

As app developers, we often include alternative images to provide the best experience to our users. As displays continue to become better, it’s easy to be tempted to include the highest-resolution images in our apps. However, this isn’t always necessary.

Let’s take Android devices as an example. Most modern phones have a pixel density of 400-500 DPI, with the Samsung S22 Ultra having a pixel density of approximately 500 DPI. When an app is about to display an image, the Android operating system automatically determines the device’s pixel density and serves the correct alternative image. In the case of the S22 Ultra with WQHD+ mode enabled, Android will render images specified for the xxxhdpi density.  For example, if the app is about to display ‘my-photo.png’, the OS will select the mdpi, hdpi or any other alternative version of the particular image based on the phone’s pixel density.

But what size should these xxxhdpi images be? According to the Android documentation, xxxhdpi images should be 4x the size of the base images. For example, if the base image size is 48 x 48 pixels (i.e.1x), the xxxhdpi image should be 192 x 192 pixels (Figure 1). It’s important to remember that designers typically work at a 1x scale because it’s regarded as best practice and makes easy design scaling possible.

  • 36 x 36 (0.75x) for low-density (ldpi)
  • 48 x 48 (1.0x baseline) for medium-density (mdpi)
  • 72 x 72 (1.5x) for high-density (hdpi)
  • 96 x 96 (2.0x) for extra-high-density (xhdpi)
  • 144 x 144 (3.0x) for extra-extra-high-density (xxhdpi)
  • 192 x 192 (4.0x) for extra-extra-extra-high-density (xxxhdpi)

Figure 1: Relative sizes for images at different density sizes

So, it is not necessary to include ultra-high-resolution images.

Since this post focuses on React Native, you might wonder if there is a rule of thumb for what the resolution of any image you include should be. According to React Native 0.70 Documentation, it is sufficient to have 1x, 2x, and 3x scaled images for any mobile device. These scales are similar to the scaling factors used by iOS.

Including higher resolution images beyond 3x may not be of much use, as mobile devices will scale the images down to fit their displays. In fact, including higher-resolution images can increase the size of your app unnecessarily, as explained previously.

In creating a lightweight, high-performing app, it’s best to stick with the 1x, 2x, and 3x scaled images. This is especially true if you design your assets at 1x scale, and you can then use the 2x and 3x scales as needed.

In a project we worked on at Calcey, we reduced the size of the production app by an additional 20 MB by optimizing our images. Altogether, we reduced the production app size by a whopping 90 MB through image optimization alone. This demonstrates the significant impact image optimization can have on the size and performance of a React Native app.

Additionally, given below are a few other methods that can be used to arrive at a smaller app size.

For Animations: Use Lottie

Lottie is a library for Android, iOS, and the Web. It allows developers to include animations in their apps with ease, and is based on the open-source Bodymovin extension for Adobe After Effects. Lottie uses JSON files to describe the animation data.

Lottie can be a good choice for mobile apps compared to GIF and other animation formats.

  • Small file size
    Lottie animations are typically minor compared to  GIF and other video formats. This can reduce the size of the app  and improve its performance.
  • High-quality animations
    Lottie animations are based on vector graphics, meaning they are scalable  to any size without a loss in quality. This can  especially be useful in creating animations with smooth, clean lines and curves.
  • Customizability
    Lottie allows developers to customize the animations they include in their apps. This is useful in creating animations that match the style and branding of the app.
  • Premium makes things even better
    Lottie’s Premium Service can be used to optimize Lottie files to obtain smaller animation files.

Analyze the JS Bundle

react-native-bundle-visualizer is a tool that can be used to visualize the bundle size of a React Native app. It provides a visual representation of the size of the app’s JavaScript, assets, and other dependencies, allowing developers to identify areas where they can optimize the size of the app.

There are several reasons why developers might want to use react-native-bundle-visualizer:

  • Identify areas for optimization
    By visualizing the size of the app’s bundle, developers can quickly identify areas where they can optimize the size of the app. This can include optimizing images, removing unused code, and using code-splitting techniques.
  • Monitor changes to the bundle size
    react-native-bundle-visualizer can be used to monitor changes to the bundle size over time, allowing developers to track the impact of their optimization efforts.
  • Improve app performance
    Reducing the size of the app’s bundle can improve app performance, particularly on devices with lower specifications. Using react-native-bundle-visualizer, developers can identify and address problem areas contributing to a larger bundle size.

Analyze the Android APK file
The Android APK Analyzer is a tool that allows developers to analyze the contents of their Android app packages (APKs) and understand their size and composition. It’s included in Android Studio and can be used to examine the size of the app’s code, resources, assets and identify potential areas for optimization.

Figure 2: Analysis of an APK

One of the main benefits of using the Android APK Analyzer is that it allows developers to identify and optimize the size of their apps. For example, developers can use the tool to identify resources that take up a large amount of space e.g. large images or unused code. They can then take steps to optimize these resources, such as by compressing images or removing unused code.

By following the tips and techniques outlined here, you’ll be well on your way to building lightweight, high-performing React Native apps users love. And remember, every little bit of optimization can make a difference – even reducing the size of your app by just a few megabytes can vastly improve the user experience and make your app stand out in a crowded marketplace. Happy coding!


Reminiscing our journey with Upflex

A few days ago, our client Upflex announced raising a round of Series A funding from a collective of strategic investors which includes WeWork, Newmark, Cushman & Wakefield, and the Silicon Valley Bank 🎉

Of course, we are really happy too. As Upflex’s engineering partner throughout, we’ve directly been involved in helping Upflex get to where it is today. We’ve navigated the ups-and-downs of building a startup together, including that fire walk every founding team has to endure—finding product-market fit.

In the five years since inception, Upflex has signed up names such as American Express, Richemont, Trinet, FlexJobs, Stella Connect, and Schneider Electric as customers, and Colliers International as a partner. More recently, the company partnered with Anarock to expand operations in India, and its digital platform covers more than 5,500 office spaces in 75 countries. All in all, the future is looking bright for Upflex, but the seeds of this growth were planted a long time ago.

In 2017, We Got A Call…📲

…from Upflex’s co-founders, Christophe Garnier and Ginger Dhaliwal. That’s when it all began. At the time, Christophe and Ginger had a rough-around-the-edges idea to build a digital platform that allows companies to book flexible workspaces. In their possession was a partially completed MVP and a small budget which they had managed to put together by themselves. 

Being non-technical founders, they were looking for someone to help complete the MVP and handle all end-to-end engineering duties if the MVP succeeded in gaining traction. We said yes, but on the condition that completing the MVP and taking it to market was going to be treated as a pilot project. We believe this is a better approach to developing software, as it allows both parties to understand whether they’re a good fit for each other. It’s also a very fair way of doing things, in our opinion.

The MVP garnered positive interest and we also liked working with Upflex, so we agreed to become Upflex’s engineering partner. In order to accommodate their limited budgets, we agreed to provide our services at a discounted rate. Not only did this unique agreement allow Upflex to continue working with us, but it also allowed us to perfectly align our incentives with those of the Upflex team.  

That’s not all though. we even decided to become seed investors in the startup. To us, Christophe ticked all the boxes as a founder. He was passionate, resilient, and had a lot of experience in the industry. Being a founder-led company ourselves, we knew what it takes to build a thriving business, and in our eyes, Christophe had it all. Therefore, the decision to become a seed investor in Upflex was an easy one to make.

Pivot, Pivot, Pivot

Between what it is today, and how it was first conceptualised, Upflex has gone through many pivots in response to market conditions—as startups do. In 2018, Upflex operated as a marketplace that allowed anyone to book a shared office space with ease. The company targeted business travelers who wanted a nice office space to work out of, and long commuters and remote employees who didn’t want to work from home but also didn’t want to spend hours on the road everyday.

Upflex’s value proposition in 2018, as described on its website. Source: The Wayback Machine

12 months later, Upflex realised that lots of companies were very interested in setting up distributed offices around the world without signing up for expensive leases. As this was a lucrative market that could provide a more stable revenue stream, Upflex decided to double down on it. We worked with Ginger, who by then was running Upflex’s product team, to roll out a slew of new features to support the company’s new direction. Among them was a portal that business customers could use to add team members on to their subscriptions and allocate usage limits on an individual basis. Once added, team members could book workspaces under the company’s name. At the end of the billing period, the company would be sent a single invoice to pay, sparing accountants from periodic headaches.

Launching SafeSpaces™

Then came COVID-19, and it necessitated another pivot. While the world collectively embarked on the single largest remote working experiment it had ever seen, many predicted the death of the office as we know it. 

But Upflex correctly sensed that post-pandemic, there will be a significant subset of workers who wouldn’t want to work from home, but also would not want to put themselves through the misery of a long commute as before. Companies wanted to become as asset-light as possible (Why pay for office space that you don’t need?), but at the same time had to provide employees with a safe and hygienic office to work in. The latter contradicts the former, as you can’t vouch for safety and hygiene when you don’t actually have control over the upkeep of the building that houses the office.

There was also another side of remote work that was becoming more apparent with every passing day. New employees to 100% remote workforces were finding it hard to build social bonds with coworkers, and as a result, collaborative cultures carefully nurtured over time were at risk of falling apart.  

SafeSpaces™ is Upflex’s answer to this trilemma. Under the SafeSpaces™ program, companies can provide employees with flexible workspaces that meet CDC and WHO standards, thus providing them and their families much-needed peace of mind. Employees can choose from any of Upflex’s 5,500+ workspaces around the world and make bookings by themselves.

Late nights, deadlines, and disciplined iteration

Driving rapid iteration and hitting every deadline is no walk in the park. Things become even more complicated when you consider that our team in Sri Lanka has to work around a 9.5 hour time difference with NYC, where Upflex’s team is based. But we never shied away from the challenge, and simply found ways to adapt.

On some days, that meant scheduling calls at odd hours for both sides. It’s not easy (They have their own lives too!), but we trusted our teams to find a balance that worked for them. It also meant investing a lot of time and effort into building trust with Ginger and the product team at Upflex, as that is the bedrock of a strong working relationship. 

Anticipating customer needs

In keeping with Upflex’s pivot to adapt to a post-COVID world, our product engineering team worked tirelessly to introduce a ton of new products and features. For instance, we built a set of white labeled apps that can be used by third party real estate brokers to sell workspaces to their own clients. We rolled out intelligent local currency billing to eliminate currency conversion hassles, and introduced QR check-in. Each and every product and feature was carefully built to complement the existing mobile app, which again, was built by us. We understood that in a future where work will be distributed, customers would rate singular, convenient, and zero-contact experiences very highly. It was also a good way to differentiate Upflex’s value proposition from its competitors.

Upflex’s story shows what happens when you deploy software smartly to solve real world problems. Of course, it also helps to have a proactive engineering partner like us 😉

Looking to build a cutting edge digital product of your own? Talk to us to find out how we can help!

Cover Photo by Helena Lopes on Unsplash


Developing an app? Here’s how to choose between an in-house and a remote development team

When building a tech company every founder and CTO needs to decide how they will structure their tech team. The options available are fairly well established.

  • Hire developers that work with you in your office (in-house team)
  • Hire developers who will work from home (remote team)
  • Hire a team of developers provided by an external software development agency. Often such agencies would be off-shore and hence work remotely with you

What’s best for you? The short answer is – it depends. The cost will play an important role in this decision, but there are several non-quantifiable factors you need to consider too. If you’d like to compare the likely cost of an in-house team vs a remote team provided by an agency we’ve broken down the costs of an in-house dev team in New York here. Here’s everything else you need to consider, other than cost/budgets;

  1. Can you attract the best local talent? 

There is a huge difference between a 10x developer vs a journeyman. This is relevant with anything, not just software development. But, software by nature has strong asymmetric returns. For example— a brilliant developer may singlehandedly create an MVP of a product that goes on to become a billion-dollar company, while a mediocre developer may write a lot of code that simply gets scrapped. The time and effort put in may not be different but the end results may vary wildly. In software, as in many other fields with asymmetric returns, the best talent isn’t only a fraction better than the mediocre players. What they produce is exponentially better in value. 

The question at hand is ‘Are you going to attract the best talent in your locality?’ If you’re based in a tech hub, your chances of acquiring that top talent will likely be low when you compete with giants like Google, Amazon, and Facebook.  But you shouldn’t be discouraged. Rather than sticking to your locality, make the whole world your hiring market. Go remote. 

2. Is speed your priority? 

Studies show thatthe average hiring time for a software development engineer in 2017 was 41 days“.  On top of recruitment time, A typical team needs to go through a process of team development i.e. forming, norming, storming, and performing, before they can operate at peak levels.  If you’re in a race against time to get to market ahead of the competition, hiring a ‘ready-made team’ from an external agency will help you avoid these obstacles altogether. When time is of the essence, a team from an agency with a prior working history will always reach the ‘performing’ stage faster and you’ll end up saving months in recruitment time too.

3. Lean and focused teams are in

Auren Hoffman is right when he says that “Almost every company spends over 95% of its time doing what every other company does. And it spends less than 5% of its time on things that are unique to the company. This makes no sense.” It’s a well-known fact that larger teams move slower and are harder to coordinate compared to smaller teams. Simply keeping everyone on the same page (more difficult than you’d expect in the highly dynamic world of technology) becomes an almost impossible task as team size grows. At Calcey  we are huge fans of Jeff Bezos’ ‘two pizza teams’ concept and we organize our software development teams accordingly. 

So how can you keep your core team lean and focused? You outsource through external agencies for everything other than for the few key core competencies that make your business unique. Surprisingly, software development doesn’t fall into this category even at some tech companies. Sometimes, their core competency may very well be product design, branding, and customer relationship management. 

4. How specialized is your business domain?

If you’re in a niche, complex business and your software project requires a deep understanding of your domain, then opting for an in-house software development team makes sense. They can learn and absorb your business domain over time rather than forcing you to spend considerable time and energy teaching an outsourced software development team about your business. You would also not be able to directly control churn within your remote development provider’s team and hence may need to repeat this onboarding process again and again if too many experienced hands leave the team.

5. Are you willing to invest in a team?

What’s the type of team that comes to your mind when you think of developing software?  Do you imagine a team made up of 3 or 4 developers? Or a team with developers and other supporting roles such as PMs, Software Architects, and QA engineers? Just a couple of developers might do when you’re starting out and only looking to create a scrappy MVP. But once you need to operate at scale; serve a sizable user base and integrate with 3rd party apps in your ecosystem etc. this bare-bones team will quickly reach its limits. At that point, it would be time to bring in the supporting roles and get your developers who were previously shipping code at abandon, accustomed to industry-standard development practices. This isn’t always an easy transition, and any technical debt created by your original developers would be exposed and will need to be fixed. 

If you’d rather avoid these growing pains or don’t want to invest to create a fully-fledged development team, it makes sense to go with a remote development agency that can provide a fully-fledged team that can manage the full software development life cycle from day one.

6. How much flexibility do you need?

Software products often need to change tech stacks as they mature. Furthermore, development may have to speed up and slow down at different points of time. If you opt for an in-house team it’s worth considering how you will manage such changes. Can your team re-skill when you need to change tech stacks? Will you be able to hire quickly when you need to speed up development and have flexible staffing arrangements in place to ramp down the team when you slow down?

Often this is where an external agency will shine. Their business model revolves around managing staffing requests and serving clients using a variety of technologies. So flexibility and versatility are often baked into their mindset and contracts.

7. You don’t know what you don’t know

When confronting a challenge your solutions are typically generated by your prior experiences. It’s very likely that there are better solutions out there, but we can only consider a sub-set out of these solutions— those that we know of. So what does this mean? Simply put, the broader your perspective the better. 

Having a broad perspective is easier said than done in the dynamic world of technology. The industry evolves at a breakneck pace and new frameworks, libraries, and tools are constantly introduced. How many of these latest and greatest tools we are exposed to depends on how often we are faced with the novel, fresh challenges. Ideally, a highly motivated developer would keep in touch with the latest developments, but given the pace of change in the industry, this is impossible. So necessity is a better driver of learning. 

What all this means is that an in-house tech team that is embedded in one business domain and a narrow technology stack will often have a narrower perspective and idea set in comparison to an outsourced agency which is more versatile due to the nature of their business.  

Principally, both approaches to software development are beneficial, however, their effectiveness can vary depending on the situation. Remote development comes at the benefit of providing a broader, more versatile team while in-house development gives your developers a deeper understanding of the project.  On the other hand, in-house teams come with the headache of time spent on recruiting and finding people with the right ambitions to help the company in their core business functions. The added benefit of having a remote development team is they often have more flexibility which is better than having less. Which option you go with depends on your own unique circumstances, but whatever it is, choose wisely.

Cover image credits: Unsplash/@wocintechchat


Resolving data sync inconsistencies in calorie counts and energy expenditure that arise with Apple Health integrations

Apple Health and Fresh Fitness Food: How many calories did the team at Calcey burn to find a solution for data integration?

In December 2020, Fresh Fitness Food, one of London’s leading providers of bespoke nutrition, took the next step in on-the-go accessibility through the launch of their mobile app. Fresh Fitness Food (FFF) provides precision nutrition tailored to each individual’s needs and dietary restrictions. With the new mobile app, however, FFF has the potential to be so much more. 

The app can track fitness goals, daily activity, and calorie expenditure. It can then suggest and provide guided workouts and meal plans to help you achieve your goal. Real-time data can be entered on-the-go and accounted for in the design of your next meal. FFF employs a Michelin star trained menu consultant to create this bespoke meal plan and will deliver it right to your door. 

Calcey, who developed a new web portal for FFF, was the team behind the design of the mobile app. The app was meant to be easily connectable with other activity tracking devices and programmes such as Fitbits and Apple Health. However, soon after launch, the team was made aware of a discrepancy. 

Where’s the fire?

The number of calories burnt each day was provided to the user through the FFF app. To do this, the app would integrate data from Apple Health or any other fitness monitoring system the user already had. When comparing the numbers provided by the app against those provided by Apple Health, it was found that they varied by 50-200 calories each day. The team at Calcey puzzled over this inconsistency and began to search for an explanation. Seek and ye shall find – the team soon discovered the reason behind this.

Apple Health used a system of time intervals to produce the final number of calories burnt at the end of the day. It was a two-part calculation, using Active Energy – the energy expenditure while walking, exercising etc- and Resting Energy – the energy spent for metabolic processes such as food digestion. Some time intervals however, would straddle two days. E.g – 11.30 pm to 12.30 am. This was the cause of the discrepancy between the data recorded by the FFF app vs Apple Health. 

Douse the flames

Once this was brought to light, the next step for Calcey was to find a way to extract the correct number of calories belonging to each day. They did this by proportionately allocating calories based on time. Eg – If the time period was 11.30 pm – 12.30 am and the total calories burnt during this time was 100, 50 calories would be allocated to the first day and 50 to the second. Similarly, if it was 11.45 – 12.45 with the same number of calories, 25 calories would be allocated to the first day while 75 would be included in the count for the second day. 

The team wrote and re-programmed the FFF app to include this method of calculation, and the change has been implemented for future downloads. Any user who was affected by this discrepancy in the month since the app’s launch was afforded the opportunity to have their calorie number corrected and updated. The team at Calcey does not anticipate any further stumbling blocks with the FFF app; however, should any arise, the team will spend as many calories as required to ensure the best possible service is provided to a client!

AnnouncementsHow toTech

London’s leading precision nutrition service goes Mobile! Here’s how Calcey made it happen

The backstory 

Over a year ago, Fresh Fitness Food (FFF), introduced its web platform to the market. Now, FFF is kicking off 2021 with a brand new mobile app, live and ready to download!

For those unfamiliar with the brand, FFF Fresh Fitness Food (FFF) combines precision nutrition with convenience, by offering individualized meals, cooked, and delivered to your door, daily. In a market brimming with generic healthy meal providers, what sets FFF apart is its ability to individually tailor meals to every customer, taking into account their nutritional needs, health goals, allergies, and food preferences. Selecting appropriate meals per customer, then preparing and sizing them to suit individual nutritional requirements is daunting enough – but to do this at scale, particularly at the scale at which FFF operates at, is extremely complex. Currently, FFF delivers more than 70,000 meals per month in London and the suburbs. 

This is largely made possible through the end-to-end web-platform that Calcey developed for FFF to manage its entire business. This mini-ERP manages FFF’s complete workflow from customer sign-up and automates meal planning to ensure that users receive the exact nutrition they need each day. It even helps FFF manage cooking manifests and deliveries. Upon launching the solution FFF realized an immediate 14% improvement in gross margins. 

The FFF mobile app

FFF’s mobile app is not a simple extension of this web solution, providing another interface for busy customers to reschedule their deliveries. Of course, it offers these capabilities to current FFF customers, but it also offers a whole lot more, essentially a ‘complete fitness center in your pocket’ for any user. If improving your fitness is on your new year resolution list this is the app you can’t do without. It offers;

Calorie tracking 

Understanding the exact nutrients in a broad range of food items is the foundation of FFF’s business model. The mobile app is integrated with the leading food databases in the world – cataloging nutritional data for millions of food items and FFF’s team of nutrition experts are constantly validating and increasing the accuracy of these measurements. 

Activity tracking 

The app can be connected with Apple Health and Fitbits to seamlessly track daily activity levels.

Meal plan and recipes 

As the app knows the exact calories you’ve had so far in the day, how active you’ve been, plus your health goals (e.g.: gaining muscle, losing fat) it’s better placed than anyone to recommend what’s optimal for your next meal. It does exactly this and provides recipes as well! 

Guided workouts 

The app has a complete section dedicated to guided workouts by top trainers. As a bonus, on the days you workout, the app will adjust your daily caloric expenditure accordingly and perhaps let you fit in that sweet treat, without letting you get derailed from your overall plan. 

The holy grail of nutrition 

What does all this mean for current FFF customers? In a nutshell, now they have access to the holy grail of nutrition. Imagine, you had a personal chef (and nutritionist) that tracked all your snacks and your activity level on a daily basis and adjusted your main meals in real-time to still keep you on track with your health goals? With the new mobile app, this is what the FFF’s customers now experience. 

Changing the game and going international 

If you’ve read so far you would have understood how this mobile app dramatically increases the value of FFF’s service to its existing customers. But what’s more, it will attract a completely new set of users drawn by its calorie and activity tracking capabilities, guided workouts and healthy meal plans. In short, exactly the type of folk who will find FFF’s service quite valuable. Attracting your target audience by providing them great value – we can get behind that marketing strategy! 

Scaling any business worldwide is tough. Tech businesses find it easier because releasing an app for a new market is less risky and requires less investment than putting up physical infrastructure, creating delivery fleets etc. This mobile app marks FFF’s transition from a click and mortar operation to a tech business. Today it can launch its app in any city and assess the interest level around its core ethos of healthy living and directly engage the people with this mindset. The core IP it’s created by its digital properties, is scalable and franchisable worldwide. 

Want to plan out a similarly transformative journey for your business? Get in touch and we’d be happy to help. 


A Short Guide To Integrating Wearables

Integrating wearables with apps can deliver a range of benefits to users.

Image credits:

At Calcey, we believe that great things can happen at the intersection of business and technology. Be it in bio-tech, education, real estate, or finance, the intelligent use of technology can make things better for everyone.

Take for instance Fresh Fitness Food (FFF), a Calcey customer and a London-based startup that specialises in delivering bespoke healthy meals to suit a given caloric requirement of a customer. Every day, thousands of fitness-addicts in and around London, including former England and Wasps rugby player James Haskell, depend on FFF to satisfy their nutritional requirements. 

When you are in the business of delivering healthy meals to fitness junkies, it is really important to ensure that each and every meal suits the needs and dietary preferences of EVERY SINGLE CUSTOMER. To do so, bespoke meal services usually ask customers for information such as height, weight, metabolic rate, allergies and more.

Collecting this data is often a cumbersome process. To make things worse, the human brain is notoriously bad at estimating, as many a scientist has pointed out before.

But, what about the wearables on our wrists? These tiny devices manage to gather a treasure trove of information on us with every passing day, and soon, medical professionals could use the data to even predict illnesses. Why can’t services such as FFF tap into this treasure trove of data instead of relying on inputs from customers?

Integrating wearables with apps can provide a few distinct benefits such as:

Access to real time data

Wearables can provide apps with continuous access to a stream of real time data, thus allowing them to deliver an optimal user experience at all times. For a custom meal service like FFF, access to real time data will allow it to tweak meals to a customer’s shifting health attributes on a daily, weekly or monthly basis.

Better user experiences through precise data collection

For companies and apps operating in the health-tech or fit-tech space, the data collection process is the starting point of the value chain as well as the customer journey. As such, the accuracy of this data is extremely important, and more precise data makes for a better user experience. When paired with a fitness tracker, apps such as Fitbit Coach and Nike Training Club can deliver a vastly superior experience that very closely reflects the needs of the user (based on their physical attributes) compared to when they are used in isolation and depend on user input alone.

Insurance giant AIA’s Vitality programme is a great example. By integrating insurance with fitness trackers, the company can incentivise users to take care of their health and use the data to fine tune their underwriting practices over time.

All major wearable manufacturers such as Apple, Fitbit and Garmin provide developers with access to APIs that make it a breeze to integrate wearables with web and mobile apps. Given below are the basics of what you need to know if you ever intend to integrate a wearable with an app. For the sake of simplicity, we will only be focusing on integrating the Apple Health, Fitbit, and Garmin platforms with an iOS app.

Integrating Apple Health

Of all the wearable platforms, Apple’s HealthKit platform is probably the most feature-rich and easiest to integrate. Due to its laser-like focus on privacy, Apple requires developers to obtain the explicit consent of users before accessing data. In true Apple style, the company provides developers with a set of guidelines for the purpose, and developers are expected to inform users of exactly how and why their information would be used. Typically, this can be accomplished by making amendments to the app’s Info.plist file.

HealthKit relies heavily on subclassing. At its most basic level, this is how a code snippet would look:

class HKQuantitySample : HKSample

HealthKit has several different data types of which ‘Quantity Samples’ is the most common. This data type grants access to data such as a user’s height and weight, pulse rate, etc. which can then be used by services such as FFF to build a user profile.

Here’s a sample of how the code for a query to find out the basal energy burn would look like:

guard let quantityType = HKObjectType.quantityType(forIdentifier: HKQuantityTypeIdentifier.basalEnergyBurned) else {
  fatalError("*** Unable to create a step count type ***")
// Create the query
let query = HKStatisticsCollectionQuery(quantityType: quantityType,quantitySamplePredicate: nil,options: .cumulativeSum,anchorDate: anchorDate,intervalComponents: interval)

Integrating Fitbit

Fitbit is somewhat different to Apple in that it does not allow developers to access historical data. To get around this problem, developers can use Fitbit’s Health API (now known as the Web API) 

The Fitbit API uses OAuth 2 as its authentication protocol. Since integrating a service through the OAuth 2 protocol can be messy, developers can rely on Swift’s OAuth library to complete the integration. This method should serve well in most instances, and doesn’t take much time to implement as well.

Once a connection is established, the Fitbit APIs Profile and Activity endpoints (or any other endpoint) can be used to obtain the necessary data.

Here’s an example of a GET request that can be entered to obtain information about activities completed by the user:


Once processed, the API would spit out this response:

            "name":"Treadmill, 0% Incline",
            {"activity":"tracker", "distance":1.32},
            {"activity":"loggedActivities", "distance":0},
            {"activity":"veryActive", "distance":0.51},
            {"activity":"moderatelyActive", "distance":0.51},
            {"activity":"lightlyActive", "distance":0.51},
            {"activity":"sedentaryActive", "distance":0.51},
            {"activity":"Treadmill, 0% Incline", "distance":3.28}

Here’s another example of a GET request through which developers can obtain details about the user’s profile:


And the response:

    "user": {

Integrating Garmin

Unlike Fitbit, Garmin’s Health API uses OAuth 1 as its authentication protocol. Don’t worry though, because Swift’s OAuth library supports both OAuth 1 and OAuth 2 protocols.

To fetch data, developers can use the Garmin API’s Activities and Dailies classes. Here’s a sample code snippet that can be used to obtain a daily summary of the user’s activity.

Here’s the GET request:

GET api/rest/dailies?uploadStartTimeInSeconds=1452470400&uploadEndTimeInSeconds=1452556800

And here’s the response:

{ "summaryId": " EXAMPLE_67891", "calendarDate": "2016-01-11", "activityType": "WALKING", "activeKilocalories": 321, "bmrKilocalories": 1731, "consumedCalories": 1121,
"steps": 4210,
"distanceInMeters": 3146.5, "durationInSeconds": 86400, "activeTimeInSeconds": 12240, "startTimeInSeconds": 1452470400, "startTimeOffsetInSeconds": 3600, "moderateIntensityDurationInSeconds": 81870, "vigorousIntensityDurationInSeconds": 4530, "floorsClimbed": 8, "minHeartRateInBeatsPerMinute": 59, "averageHeartRateInBeatsPerMinute": 64, "maxHeartRateInBeatsPerMinute": 112, "timeOffsetHeartRateSamples": {
    "15": 75"30": 75,
     "3180": 76,
     "3195": 65,
     "3210": 65,
     "3225": 73,
     "3240": 74,
     "3255": 74
"averageStressLevel": 43, "maxStressLevel": 87, "stressDurationInSeconds": 13620, "restStressDurationInSeconds": 7600, "activityStressDurationInSeconds": 3450, "lowStressDurationInSeconds": 6700, "mediumStressDurationInSeconds": 4350, "highStressDurationInSeconds": 108000, "stressQualifier": "stressful_awake", "stepsGoal": 4500, "netKilocaloriesGoal": 2010, "intensityDurationGoalInSeconds": 1500, "floorsClimbedGoal": 18

And that’s all there is to it, really (at least from a developer’s point of view). Happy coding! 

If you are interested in finding out how we can help unleash a new wave of growth for your company with the smart use of technology, contact us via our website.


Get Hooked on React Hooks

A handy primer on React Hooks / React Hooks is what happens when you bring a cannon to a knife fight

A little over a year ago, React 16.8 shipped with an additional API that lets developers use state and other features in React without writing a class. Known as ‘Hooks’, this additional API has grown in popularity amongst developers, and is now a common feature in everything from open-sourced applications to enterprise apps.

Crucially though, React hooks are completely opt-in, which means there is no need to rewrite existing code. Hooks are also 100% backward compatible and don’t contain any breaking changes.

Why Use React Hooks?

Hooks were developed with the intention of solving a range of seemingly unconnected problems, which were hampering the evolution of React—a language that is not yet a decade old.

Hooks make it possible to:

  • Reuse stateful logic between components
    Hooks allow you to reuse logic between components without changing their architecture or structure.
  • Understand components easily
    When components become larger and carry out many operations, they become increasingly difficult to understand. Hooks solve this problem by allowing developers to separate a given component into various smaller functions which are related to each other.
  • Navigate classes (without tearing your hair out)
    To the novice, Classes in React can become quite confusing. To complicate matters further, computers also tend to get confused by Functions and Classes. For instance, minifiers/unglifiers don’t play well with Classes and can cause problems. With Hooks, developers can use more of React’s features without opting for Classes. This makes sense because when you really think about it, React components have always been conceptually similar to functions. In essence, Hooks embrace functions without discarding everything that is great about React.

Before going any further, there are two main ‘rules’ that need to be kept in mind.

  • Make sure to not use Hooks inside loops, conditions, or nested functions;
  • Only use Hooks from inside React Functions.

The Different Types of Hooks

React 16.8 ships with 10 in-built hooks, but the most basic and commonly used ones are:


The useState() hook allows developers to update, handle and manipulate state inside functional components without needing to convert it to a class component.


The useEffect() hook accepts a function that would contain effectual code. In functional components, effects like mutations, subscriptions, timers, logging, and other effects are not allowed to be placed inside a functional component. Doing so would lead to a lot of bugs and inconsistencies when the UI is rendered.

When useEffect() hook is deployed, the effectual function passed into it will execute right after the render has been displayed on the screen. By default, effects are executed after the render has been completed, but you can also execute them when certain values change. 


The useContext() hook accepts a context object, i.e. a value that is returned from React.createContext, and then returns the current context value as appropriate.

Prior to the introduction of the useContext hook, developers would need to set up a contextType or a to access the global state passed down from a provider in a class component.


The useRef hook is a function that returns a mutable ref object whose .current property is initialized with the passed argument (initialValue). The returned object will persist for the full lifetime of the component.

Experienced developers will recognise the useRef hook as something that is used to access DOM nodes or React elements. However, it can also be used to keep any mutable value around similar to how you would use instance fields in classes.

Before vs. After: A Code Example

In order to demonstrate how effective Hooks can be, let’s try to build a simple counter. If we were to use Classes, this is how the code would look:

class Example extends React.Component {
  constructor(props) {
    this.state = {
      count: 0
  render() {
    return (
        <p>You clicked {this.state.count} times</p>
        <button onClick={() => this.setState({ count: this.state.count + 1 })}>
          Click me

But, if we were to rewrite this using Hooks, this is how it would look:

 import React, { useState } from 'react';
  function Example() {
     const [count, setCount] = useState(0);
     return (
        <p>You clicked {count} times</p>
        <button onClick={() => setCount(count + 1)}>
         Click me

Note the following:

  • Line 1: The useState Hook from React is imported. It lets us keep the local state in a function component.
  • Line 4: Inside the Example component, a new state variable is declared by calling the useState Hook. It returns a pair of values, to which names can be given. We’ve called our variable count because it holds the number of button clicks. We initialize it to zero by passing 0 as the only useState argument. The second returned item is itself a function. It lets us update the count so we’ve named it setCount.
  • Line 9: When the user clicks, we call setCount with a new value. React will then render the Example component again, passing the new count value to it.

Bringing It All Together

Here is a little tutorial on how to implement a few basic hooks. In order to illustrate how each hook can be used, we will be attempting to build a small app within React.

import React, { useState, useRef, useEffect } from "react";
export default function Alarm(props) {
 let snooze = 600;
  const intervalRef = useRef();
  const [alarm, setAlarm] = useState(props.alarmInSec);
  useEffect(() => {
    const id = setInterval(function () {
      setAlarm(alarm => alarm - 1);
    }, 1000);
    intervalRef.current = id;
    return () => {
  }, []);
  return (
      <p>{new Date(alarm * 1000).toISOString().substr(11, 8)}</p>
      <button onClick={() => setAlarm(alarm + snooze)}>

Done! You, young padawan, are now on your way to becoming a great React ninja. Congratulations!


Scaling from prototype to final product

A few tips from us on how to scale an app as an MVP gains traction

“Premature optimization is the root of all evil.” – Donald Knuth

 Building an app and scaling it to millions of users is tough. As any seasoned developer knows, there is a lot that can go wrong, which is why it is always better to follow an iterative approach starting with an MVP (minimum viable product). The logic is sound: assemble a small team, develop in small increments to gather customer feedback with fewer costs, and validate business and technical hypotheses before committing large resources to an idea.

But what happens after the MVP is out? What then?

The reception to the MVP may show that there is a business opportunity to pursue. The logical move at this stage is to put the pedal to the metal and allocate more resources towards the project.

This is when the trouble starts. It is normal for startups to adopt shortcuts in the engineering and architecting process in order to ship an MVP on time while making do with extremely limited budgets. Unbeknownst to them, this approach can often lead to costly setbacks such as those below:

  • New development efforts are hampered as new developers get lost in pieces of code that were hastily put together and are now difficult to understand;
  • The number of bugs keeps increasing and the development team starts spending more time fixing bugs than on developing new features;
  • Resource intensive processes such as AI modules may have been implemented in sub-optimal ways to reduce development complexity and time, but turn into a headache for developers to fix later on 
  • the app starts to slow down as the number of concurrent users increases, sometimes even crashing under moderate loads

It is at this point that founders, CTOs, and developers advocate for a complete rewrite of the app which is seldom realistic. The product has just started to gain momentum, and the pressure on both the top line and the bottom line of the company would be too high.

In the search for a quick remedy, developers typically consider scaling the app using hardware, which is now quite cheap thanks to large volumes of AWS/Azure credits that are doled out by service providers for free in order to drive sign-ups. Though this approach will make scalability issues go away for some time, it won’t actually solve the problem. In effect, it ‘kicks the can down the road’, thus leading the original problem to snowball into something much bigger and harder to fix.

That is why we at Calcey are strong advocates of Scalable MVPs and techniques. 

Most people fail to understand the thinking behind MVPs / Credit:

Most people fail to understand the thinking behind MVPs / Credit:

When first building an MVP, it really does not make sense to build an app that can cater to millions of users, when you aren’t even sure if you can sign up ten users. On the other hand, building an extremely limited MVP will almost always result in a costly rewrite, in the event the MVP manages to gain traction. In this context, Scalable MVPs constitute a middle-of-the-road approach, and allow developers to limit the effort that goes into building an MVP while leaving the door open for easy scalability, should the need arise.

Even though an MVP is typically developed in haste, adhering to core design principles (SOLID) and best practices is important. When best practices such as separation of concerns, dependency injection, interface segregation, and the open-close principle are already in place, it is much easier to extend the application beyond the MVP stage.

Scalable MVPs and techniques deliver the following benefits:

Horizontal Scalability

A scalable MVP allows developers to manage server loads cheaply and efficiently through horizontal scaling. Compared to vertical scaling, horizontal scaling is less cumbersome and comes with the inherent benefit of elasticity, enabling development teams to add resources as needed. Developers can also turn to orchestration services such as AWS Elastic Beanstalk to automatically handle capacity provisioning, load balancing, scaling, and application health monitoring in the background, with minimal need for human intervention.

However, there is a caveat. Horizontal scalability is largely dependent on the database the MVP or app is built on. If there is a reasonable chance of user numbers growing rapidly, it is important to be mindful of the database’s need to be able to cater to a large number of parallel requests, a common scenario with multi-tenant applications. Therefore it is worthwhile to consider opting for NoSQL databases such as AWS DynamoDB and Azure Cosmos DB that support horizontal scaling out of the box, thus allowing for throughput to be easily increased based on demand.

From a technical standpoint, the difference in performance between a database with 1000 records or 10 billion records is marginal at best. However, NoSQL databases are not silver bullets. As with everything, they do come with some limitations. Designing your data model with a NoSQL mindset is tough, and requires the presence of developers with prior experience. But, paying attention to such factors early on, will make scaling up much easier later on.

Reduced Re-architecting

As an app moves through its cycle of maturity, re-architecting becomes almost unavoidable. However, re-architecting is a tedious process, but if correct principles have been followed in building the MVP, the degree of re-architecting required will be less because performance testing is easier. Once current performance levels and bottlenecks have been identified, the next steps usually reveal themselves. For instance, an MVP that was originally written in Cordova may have to be re-written in native iOS and Android in order to accommodate a better user experience and features that draw on functionality native to a given device. Since a scalable MVP follows the same logic as building blocks, it becomes easier to decide which components must be developed, modified, or done away with, while making sure that the core functionality of the app remains unchanged in the eyes of the user.

Unit Testing

Once they gain traction, MVPs tend to expand rapidly, adding lots of features within a very short time. This will make it necessary to refactor the existing code, which can be very dangerous. However, scalable MVP’s make it possible to carry out unit tests, which make it safer to carry out refactoring. Writing unit tests does consume more time and would definitely have a negative impact on the delivery timelines of the MVP. But, if the development team has the experience and is comfortable with writing unit tests, it eventually offers great payback allowing the team to both develop and test faster, without getting bogged down in manual regression testing every time they need to release a new feature.

Launching an app and scaling it to handle requests from millions of users is hard. However, using scalable MVPs and techniques from Day One can make life a tad easier.

For more ideas on cutting edge technology from the minds at Calcey, follow us on Facebook, Linkedin, and Twitter


Transforming Businesses On A Budget With AWS Lambda

Here’s how Calcey helped a London-based food-tech startup transform their business with AWS Lambda

When you think about it, the process of ordering food through an app does seem like magic. A few taps here and there, and voila! Your food is already on its way. But unbeknownst to us, there is a lot that goes on behind the scenes. Take the case of Fresh Fitness Food (FFF), a healthy meal delivery service based in London with whom we have had the pleasure of working with. Every day, FFF delivers thousands of bespoke meals to its customers across London.

To borrow a metaphor, if the complexity of a regular meal delivery app can be equated to the experience of driving a car on a busy road, the complexity involved in ensuring a bespoke meal delivery service such as FFF runs smoothly is akin to piloting a helicopter. Every minute adjustment from the user’s end can set off a chain reaction in the algorithm that powers the company.

Like most other technologically powered services, FFF too is powered by an algorithm whose main function is to carefully put together a set of bespoke meals to suit a given daily caloric requirement, which can vary from customer to customer. The actual meals are then prepared accordingly and delivered on a pre-set schedule. At first glance, this looks easy, but when you have to tweak thousands of meals a day, it quickly becomes a nightmare.

On a given day, FFF has to balance and create meal templates for anywhere between fifty to hundreds of new orders. While the existing infrastructure was capable of managing this workload, any change to existing recipes or meals invalidated all previous meal/recipe templates due to changes in the nutrients between meals. This created a need to re-balance and create new meal templates for a large number of orders within a short timeframe, and the existing infrastructure could not cope with this increased demand for speed and simultaneous processing power.

When we first spoke to the FFF team, we found that FFF was running its own legacy meal balancing algorithm on a regular server which was also used to host all their backend IT infrastructure. As a result, whenever the resource-intensive algorithm was run, it slowed things down enormously for the entire company. With the algorithm needing 2-3 minutes to process each order, re-balancing FFF’s full order volume would have taken up to 4 days, and left quite a few Londoners hungry and disgruntled in the process.

Our Solution

Once we realised that FFF’s ability to scale and grow as a business significantly depended on the efficiency of the meal balancing algorithm, it became clear that whatever solution we came up with must also be scalable seamlessly. Since FFF was not a large corporation with deep pockets, we also had to be mindful of running costs.

After careful deliberation, the Calcey team zeroed-in on using AWS Lambda to host the new meal balancing algorithm. AWS Lambda is a server-less service provided by AWS, and is used to isolate time consuming computing activities away from regular IT infrastructure. A process running on Lambda is easily scalable, provided the underlying dependencies can support it.

How AWS Lambda works /Credits: Amazon AWS

In deploying the retooled meal balancing algorithm for FFF, we had to throttle the performance of the Lambda service, in order to ensure harmony with the capabilities of the existing database. But we also gave FFF the ability to increase the number of concurrent executions by increasing the resources available to the database, should it ever become necessary.

Even with performance throttled, Lambda has been successful in speeding up FFF’s meal balancing algorithm tenfold. What would have taken four days will now take only eight hours. That’s good enough for FFF’s current scale of operations and near term growth plans. And the operating cost of this dramatic performance enhancement? USD 15 per month. Not to mention the significant cost savings reaped by shifting meal balancing from the existing servers to Lambda.

Our experience retooling a key business process using AWS Lambda is also a great lesson for developers and executives everywhere. Having understood FFF’s requirements, there was no need to overhaul the entire IT infrastructure, as suited up consultants may tell you. Instead, with a little bit of ingenuity and pragmatism, it is possible to fashion outstanding IT solutions to business problems without burning a huge hole in a company’s budget.

If your business is also looking to move key business processes to the cloud, talk to us and we will be happy to help!

Cover image credits:


Demystifying Redux: A Beginner’s Guide What Next?

A guide to understanding Redux Thunk, Saga, and Observables

Redux is an extremely popular JavaScript library which can be used to manage an application state. An extremely loyal friend to the React ninjas amongst us, think of Redux as the middleman between the frontend and the backend, whose job it is to store data temporarily. In this blog post, we will be examining Redux itself, along with its other components such as thunks, sagas, and observables.

Created by Dan Abramov, Redux provides a predictable approach to managing state that benefits from immutability, keeps business logic contained, acts as the single source of truth, and has a very small API. To use an analogy, if you equate Mario to React, Redux is what would tell the game how long Small Mario can remain in his Super form after making use of a Super Mushroom. The beauty of Redux lies in how easily it allows developers to scale a simple app to a large, complex one.

Redux is built on three main components, namely:

  • Actions: Payloads of information that send data from your application to your store. They are the only source of information for the store. You send them to the store by dispatching actions using the redux-connect library.
  • Reducers: Are responsible for modifying the store (i.e. state) according to the actions dispatched.
  • Store: Stores the whole state of the app in an immutable object tree.

The typical Redux app would have a single store with a single root reducing function. As an app grows, all you have to do is to split the root reducer into smaller reducers independently operating on the different parts of the state tree. This structure allows Redux to be simple yet powerful, because it is possible to trace every mutation to the action that caused it. You can even record user sessions and reproduce them just by replaying every action.

Redux Thunk

Remember, Redux is not an application framework, and does not dictate how effects should be handled. For that, developers can adopt any preferred middleware, and redux-thunk is arguably the most primitive of them. Redux-thunk is noteworthy in that it allows you to dispatch actions asynchronously. Written by Dan Abramov himself as part of Redux before being split out into a separate package, redux-thunk’s original implementation is tiny enough to quote in its entirety:

In simple terms, redux-thunk is a functional programming technique used to delay computation. Instead of executing a function right away, redux-thunk can be optionally used to perform a function later.  

See for yourself:

redux-thunk can also wrap calculations that might be slow, or even unending, while other code components can decide whether to actually run the thunk.

The key benefit provided by redux-thunk is it allows us to avoid directly causing side effects in our actions, action creators, or components. Potentially messy code can be isolated in a thunk, leaving the rest of the code uncluttered. Middleware can later invoke the thunk to actually execute that function. Employing a code structure of this nature makes it easier to  test, maintain, extend, and reuse all components in a given codebase.

But, while redux-thunk works well for simple use cases, it may struggle to handle more complex scenarios. This brings us to…

Redux Saga

redux-saga is a different kind of middleware which can be used to handle asynchronous executions, and is an alternative to redux-thunk which comes with the added benefit of being able to easily handle complicated scenarios. redux-saga works by listening for dispatched actions, performing side effects, and dispatching actions to be handled by the redux reducer. 

Because redux-saga relies on ES6 Generator functions, its code is simpler and more readable. However, asynchronous calls which would normally be directly inside an action creator in redux-thunk will have a clear separation in redux-saga.

The benefits of using redux-saga are many. Testing is much easier. The code is much more readable and test cases become simple without needing to mock asynchronous behaviour, thus making redux-saga a great fit to handle complex scenarios. However, redux-saga also brings in a lot of added complexity and additional dependencies.  

Redux Observable

redux-observable is the new kid on the block and can accomplish pretty much everything redux-saga can. Both are middleware. But, the difference between the two stems from how they operate— redux-saga uses the generator function, while redux-observable doesn’t.

redux-observable relies on ‘epic’, which is a function that takes a stream of actions and returns a modified stream of actions. You can think of an epic as a description of what additional actions redux-observable should dispatch. An epic is very much similar to the concept of a “saga” in redux-saga.

The benefits of redux-observable lie in its high function reusability and easy testing. However, in contrast to redux-saga, tests in redux-observable require mocking.

Which One Should I Use?

This is where things get tricky. As a rule, don’t bring in redux-saga or redux-observable before you need them. For most simple cases, redux-thunk will serve you well (and is very easy to learn, too). As the async becomes more complex, that’s when you should start thinking about bringing in redux-saga or redux-observable, because that is where they truly shine. 

And how should you choose between redux-saga and redux-observable? 

That, young padawan, is a balancing act. Our advice is to weigh up the pros and cons, and go with the one that promises a higher marginal benefit. 

Happy coding!