Versapay: Digital Payments Mobile Strategy

Discover why more and more companies are choosing React Native to build innovative digital products.

Why CTOs Should Choose React Native as Mobile Platform

I’ll be honest, for the first eight years after iOS was released, building an application natively within iOS made sense and was the only proper decision to make. 

 had promise but lacked many core features and UX experiences that it didn’t make sense to switch over.

Native apps are considered the gold standard and offer the best overall performance, user experience, and access to hardware-related features such as support for multi-touch gestures, access to the camera, GPS, calendar, accelerometer, and much more.

But now the mobile world has moved on and React Native is the right decision for many companies.

React Native has transformed the whole dualistic notion of iOS vs. Android by creating beautiful apps for both platforms from one codebase—without compromising on the UX and UI. On a React Native app, everything you see and touch is native.

So unless you are Uber or Airbnb and can afford to spend money and time on exclusive native mobile development, your business really should be using React Native as its development platform of choice.

The reason is fairly straightforward. With React Native, you have a best-in-class framework that is optimal for 95% of all business use cases.

React Native is especially good news for CTOs and VPs of Engineering because instead of hiring two additional development teams for Android and iOS, you can leverage your existing web development team to build your mobile app. React Native represents the best organizational choice for CTOs and VPs today.

I didn’t want to start with this because I don’t think “

” is a valid excuse, but the maturity of React Native makes it an easier business case for your organization.

React Native was introduced in 2015 and underwent the initial stable release in July 2019. Over the past four years, it has become a robust worldwide open-source community with over 

 contributors on GitHub—and, of course, with the backing of Facebook. It’s also the 

 of contributors for any repository on GitHub in 2018.

React Native developers are continually building new libraries, updates, and projects. With cross-platform compatibility, shorter development cycles, faster releases, live code pushes and updates, and overall performance improvements, many have come to see React Native as the future of mobile development.

Facebook originally developed React Native as a hackathon to support its cross-platform needs. The beauty of React Native is that, unlike “hybrid” mobile app solutions, it uses native UI elements instead of rendering the entire application inside of a WebView. Your business logic is run in a separate JavaScript thread, which then controls the native UI elements. In the “old days,” companies had to develop native apps for both Android and iOS from scratch.

React Native allows developers to write code in just one language, JavaScript, then build binaries for Android and iOS. It eliminates the need to hire both iOS and Android developers to write dual applications, and this represents a huge benefit in terms of productivity, costs, and time to market. Not to mention the reduced hiring burden!

As a CTO, you’re most comfortable managing a company you understand. If you happen to be an Android “guy and need to hire an iOS developer, you’re not speaking the same language and have to work extra cycles to get everyone on the same page. This can easily lead to operations hang-ups and production slowdowns.

Being able to write once and port across each major platform means a considerable improvement in the operation of your organization. The ability to place resources on different projects and not have to worry about skillsets and whether a developer can write Swift, Objective-C, Kotlin, or Java is a huge relief.

Nearly 67% of all developers use JavaScript already, so it’s an easy sell for using React Native to improve operational efficiency across the enterprise.

There are many ways React Native saves organizations time and money. Obviously, the “one code for all” is a huge advantage as it cuts down on the learning curve and the number of hands on deck required for developing an application. It’s also open source and has a robust and growing community of ready-made components and support.

In fact, something like 95% of the React Native codebase is shared between iOS and Android. These are just some of the many reasons why React Native leads to significant improvements in ROI over hiring native developers.

As good as React Native is for all-around performance, cost savings, and portability, a few use cases will stand out that require a pure native look and feel. These are going to be the high-end enterprises, such as Airbnb and Uber that have money to spend on super-polishing their native application.

For the “rest of us,” which means 90%-95% of the business use cases, React Native will provide your organization with a highly engaging enterprise application. In other words, the reasons for not using React Native are going to be negligible.

In terms of cost-savings, increased efficiencies, and the overall native look and feel that users experience, React Native is a no-brainer!

Yes, not every app should be built with React Native. Here are some reasons to go full native:

You’re creating something with complex animations and interactions, like an interactive game.

You’re building something that’s CPU intensive, like editing photos. In that case, you could either go full native or write the complex logic in native and bridge it to React Native.

You’re creating something out-of-the-box with unconventional UI patterns. Native might be a better choice in that case.

For CTO’s, quickly getting the right products to market is all that matters. As a “learn once, write everywhere” framework, React Native cuts down enormously on the cycles required to develop and deploy user-friendly and engaging products to market. React Native is arguably one of the biggest breakthroughs in mobile application development in recent years.

, this cross-compatible platform has transformed the way companies develop enterprise-grade applications—with less learning curves, shorter development cycles, faster releases, and overall cost savings.

We’ve been using React Native since I founded the company and aren’t looking back anytime soon. You can learn more about our React Native development services 

P.S. If you’re trying to decide between React Native and other cross-platform mobile frameworks, 

Why CTOs Should Choose React Native as Their Mobile Development Platform

Nearly all business executives today believe that Agile is critical to business success. If you’re launching a digital product (or considering one) then you won’t want to miss this recent podcast on Enterprise Radio where our CEO Rob Volk discusses why more and more companies are choosing Agile and React Native to build innovative products. 

The Agile and Mobile Revolution with Rob Volk, Founder of Foxbox Digital

In July 2017, Forbes interviewed more than 500 senior executives from around the world, and 92% said they believe organizational agility is critical to business success. If you’re considering a digital product or roadmap, or are just curious about what Agile is and how it helps companies grow, then this podcast is a must-listen.

I sit down with Eric Dye of Enterprise Radio

 to talk about Agile and why more and more companies are adopting this transformative approach to mobile development.

Please listen to the podcast in the link above, and for those that like to browse ahead, check out our show notes.

1:49 — My goal in building Foxbox Digital was to help large companies build with the agility of a startup while using modern development practices.

2:15 — React Native is a really phenomenal cross-platform mobile framework and the reason I like it is because I think it's well-suited to 90% of the apps out there. It's something that gives you the benefits of cross-platform so you have one code base and one team building for both iOS and Android.

3:47 — Typically, the reason companies decide they need Agile is because they’re experiencing some symptoms, such as late project delivery or reliability issues that come up during the integration phase (or worse, when the product has gone live).

4:53 — In order for Agile to work for everyone, the entire organization has to be bought in. This means the UX folks, the product owners, the developers, DevOps, etc. must be brought out of their silos—so everyone is bought into Agile from the start.

5:36 — What doesn’t work with Agile is to just choose one group, say your UX team, to adopt this approach. It must be all or nothing.

6:10 — In order to do real work, you must have an extended period of time of uninterrupted focus. That's when you can really get your “deep work” done—things that matter.

6:40 — So Slack is a perfect avenue for people to interrupt you. It's become part of our culture for people to expect immediate responses. But that's unfair to you because that prevents you from doing actual work.

Many stakeholder ideas sound amazing in the moment, but deciding which ones move forward and which ones do not can give you a panic attack. Here are a few ways we keep quality ideation without being overwhelmed by quantity.

How I Prioritize Product Features From the CEO & Founder

A Simple Way to Prioritize Product Features

It was like clockwork. The CEO would message me daily, if not hourly, on new feature requests, slightly changing product direction each time. He messaged me on every communication channel you can think of: Slack, iMessage, WhatsApp, and email. Whenever it was the most convenient for him, regardless of time of day, he would send me these requests.

These emails contained not only vague future ideas, but small tweaks and non-critical bug fixes, etc. Essentially, anything that came up mid-sprint, he would send me a quick note with his ideas.

A big reason why I enjoyed working with him was his excitement about the product we were building, and he was constantly thinking of new ideas. However, that came at a cost. I was drowning in new things to build, and I didn’t know how to focus these requests.

I appreciated his willingness to share his ideas, but at the same time I had to make sure we were building the right things. I wasn’t necessarily in a position to say no to these new features, even when I was only halfway done with the features we started weeks prior. I actually did care about what he wanted to build, I just didn’t think many of these features were the right decision.

I needed to ruthlessly prioritize our feature requests.

 But, again, who was I to decide what feature was right or not? So, I thought of something to help me alleviate this pain.

After a few panic attacks, I created what I called the inbox system. This was a place in our project management board where I collected all of his, and the team’s, ideas. It gave me a chance to say, “Great idea! Let’s discuss later.” He knows that his idea isn’t lost, and I don’t feel the pressure to act immediately.

In the next sprint planning meeting, we would go through all of these ideas, weigh them against all of the other issues (i.e. features, bugs, cards) in the backlog, and prioritize the things that will have the biggest impact towards achieving our company’s objectives.

The inbox system aims to solve the problem of changing the plan mid-sprint and allows you to slow down and consider your next steps. You don't want a reactionary engineering team where the latest ideas from the stakeholders are implemented over things that have been planned for weeks.

CEO sends feature request (and wants it built ASAP).

Acknowledge her feature idea and document the request in your project management board (AKA, the “inbox”) before committing to building the idea.

During the sprint review meeting, instead of asking the validity of the idea ad nauseum, discuss the priority of this request compared to everything else that needs to be built or fixed.

It was a small tweak, but it made a substantial impact. I was heard. He was heard. And together, we made the best decision for the product and the company.

Some Features Just Aren't Worth Building, Regardless of How Genius It Is

Every feature can certainly not be a winner.

This isn’t 3rd grade where everyone gets a participation trophy and feels like a winner at the end of the soccer match.

Implementing the wrong feature can significantly impact the trajectory and traction of your app. Not just because users don’t like it, but for simply how much effort and time it took to complete.

As a Product Manager or Project Manager, you’ll get a lot of input from your stakeholders. For us, it’s our clients. For businesses, it could be your CEO or boss. It used to give me anxiety when I heard all these lofty feature requests: I felt like I needed to implement all of the ideas my CEO threw at me over email, text, or Slack.

Many ideas sound amazing in the moment, but the luster wears off quickly. If it’s still a great idea during the next sprint planning, then consider implementing it. If not, then discard it—that’s okay to do, it’s part of innovation. All ideas can’t be winners!

When you set out to build a product, there's a disconnect between what you think people need and what they actually need.

How to Define your Minimum Viable Product (MVP)

When you set out to build a product, whether it's a mobile app, website, or a physical product, you'll envision how people will use your product and what qualities they need of your product. What often happens when building products is 

If you take the Lean Startup approach to designing and building your first product, 

, you're more likely to build exactly what your users need, and eliminate waste from building features they don't need.

), and when you're building a startup company, you have real constraints with how much money and time you have to build something. These constraints force you to be smart about what you spend time building; any wasted effort could put you out of business.

The classic model to create a product is called Waterfall, and it doesn't work. With Waterfall, you start by defining all requirements, then design the product, then build it then launch it. This sounds completely logical, but problems arise if requirements change at any point in the process. 

 When this happens, your project goes way over budget and you blow past the deadline.

With a lean approach to building a product, the idea is you take the steps in Waterfall and repeat them many times over. You divide up the problem into several product phases, where each phase fully delivers on a set of objectives.

 objectives of your project. People start using your product early on in the development cycle, 

 People tell you what's working and what isn't, and you can respond by altering the product roadmap.

Think of it this way: if you set out to build a car to get people from here to there, you don't start by building a wheel. That doesn't get you to where you need to go. You could start by building a bike. From there you could build a scooter, then finally a car. At each phase of the project, people are able to use your product to achieve the main objective: transportation. They'll give you feedback along the way ("it's too slow!"), and you'll incorporate that feedback and iterate the product.

This process allows for changes in your product roadmap during active development. Changing requirements doesn't mean pushing back your delivery date - because the process accounts for change. After people use your MVP, you might decide to cut entire features, and improve other features that they actually use.

After the MVP, you'll continue iterating the product in mini releases - every week or so. The product takes shape, change by change, until you've achieved all of your objectives. The product is tested in realtime during active development, so at the end, 

you'll have confidence that you hit the mark.

At Foxbox Digital, we take a lean approach to building mobile apps. We tap into our entrepreneurial experience of building startup companies, and apply that experience to how we build products. We'll help you 

build your product with a lean, agile approach

At the end, you'll have a product that meets your objectives, has the features you need, and eliminates the features you don't actually need. 

This is how you build a product that hits the mark and deliver it on time.

After you've designed and built your mobile app, you have to monitor, maintain and support it for the life of the app.  What's involved?

The Total Cost of Running & Maintaining a Mobile App

After you've designed and built your mobile app, you have to monitor, maintain and support it for the life of the app. What's involved? There's a lot more effort than you might think.

Mobile apps usually need a server in order to operate, called an API. The API is responsible for storing and retrieving data. For example, when you create a new account as a user, the mobile app talks to the API to create that user.

At Foxbox Digital, we host our client's APIs on 

. This is a server farm that has redundancy built in on every level, so that if any single component fails, your app still runs. If the API server goes down, there are more just like it that continue to operate. If the database server goes down, there's a failover server that takes over automatically. Even if the power goes out, there's a backup generator to keep the servers running!

This type of hosting is called high availability, because your app is available as close to 100% of the time as possible. Building and configuring this type of high availability infrastructure is not a trivial task, but it's critical to ensure your app always works.

If your app goes down for any reason, the engineering team needs to know about it. At Foxbox Digital, we have a monitoring system that constantly checks to ensure the servers and the API is running 24x7. If anything happens, 

it immediately notifies our engineering team

. When this happens, we respond to the problem and take action.

It's common for errors to happen when users interact with your app in a way that you didn't anticipate. We call these bugs, and usually they are small, but sometimes they are serious.

Both the mobile app and the API needs error monitoring to ensure that when an error happens, an alert is triggered and the tech team is notified. At Foxbox Digital, 

we actively monitor our clients' apps and the API and trigger alerts when an error occurs

. We respond quickly to fix the bugs in order of urgency.

Here's a view of the error dashboard of one of our apps. The tool is called Sentry and it notifies the team on Slack, our internal chat tool. The first one is happening frequently, and the engineering team is working on a fix as we speak.

You need your API to be fast so that when users interact with your app, the experience is as fast as possible. This is why we actively monitor the performance of your API. We're able to identify performance issues in any part of the app and we use tools to give us detailed insights into what's happening.

For example, if you have a surge of users, we'll scale out your servers to support the added usage. Or if just one component, like searching, is really slow, we'll dive in and figure out why so we can fix it.

We don't compromise on application performance.

Upgrade App to Support Latest iOS & Android

Every time Apple and Google releases a new operating system, apps need to make changes to support the latest specifications. If you don't, you risk Apple or Google pulling your app from the App Store or Google Play. These upgrades can take a lot of time and are sometimes complicated.

Apps are built by using a set of frameworks, tools, and reusable components. On occasion a security update is released for one of these components, and the application developer needs to upgrade the app and apply the security fixes. Without regularly patching your app and API, the security of your app and data are compromised, and that is unacceptable.

At Foxbox Digital we regularly upgrade all of our clients' apps to apply the latest security upgrades and bug fixes. This keeps our apps running fast, smooth, and secure. As soon as we patch each app, we release it to the App Store and Google Play.

It's normal for an app to have some bugs - even the most well-tested apps do. When a bug is identified from our error alerting system, we respond quickly to fix it.

At Foxbox Digital, you have a direct line to reach out to our support team. If you need to make changes to your app, or if you just need help with something, we're here for you, when you need us. Our clients have 

At Foxbox Digital, we handle the hosting, monitoring, maintenance, bug fixes for you. We also specialize in 

. You'll also have unlimited access to our premium support. You'll have the 

 of knowing that your app is running smoothly, forever. And if anything happens, you know that someone is actively monitoring it and working on a fix.

We're your trusted partner, for the life of your app. 

Let's compare the best cross-platform app frameworks (React Native, Ionic, Cordova, PhoneGap) to develop for iOS and Android at the same time.

Comparing Ionic vs Cordova vs PhoneGap vs React Native

I set out to build an app for myself called 

 (it’s the insider’s guide to the city).

I looked into the cross-platform frameworks available so I could build it for both iOS 

 — Apps created with these frameworks are basically websites created with HTML, CSS, & Javascript, smushed into app form. It 

 like an app. When you interact with the app, it feels slightly sluggish and not responsive.

 — This framework take an entirely different approach to hybrid cross-platform apps, and uses native UI elements, powered by Javascript. You write your app in Javascript, then 

 works some magic and turns the user interface into 

. This means that when you touch & feel your app, it 

React Native apps are snappy, responsive, and a joy to use.

. I argue that it takes less than half the time to build an app compared to full native apps, because not only do you have to build an app once instead of twice, it’s just faster to build the first app period.

Under the hood, React Native uses Javascript to run the business logic, for example handling a button click or fetching data from a server.

Technically it does this with a headless browser. Because of this if you don’t program the app right, you may see some slowness.

There are ways in which to program the app however that eliminate this problem and the user will never know the difference between a pure native app and a React Native app.

Companies including Instagram, Facebook (parts of their app), Bloomberg, & Skype (

From a technical perspective, it wins some points because it uses technology many developers already know: Javascript and React. Web developers don’t have to learn an entirely new language (Objective C, Swift, or Java); they just apply the skills they already have to a new form factor, mobile.

So how did the app come out? Speakeasy is snappy, responsive, and I bet you couldn’t tell it’s a React Native app.

React Native strikes the perfect balance in creating cross-platform apps because it’s super fast to build them and the apps look 

 feel like native mobile apps. The end result is a polished, snappy and responsive mobile app.

You write the apps in Javascript, which is one of the most popular programming languages and use the React framework which is a revolutionary and brilliant framework.

React Native isn’t great for games or anything with complex animations. But for most apps that simply display and let you edit data, it’s a great choice.

React Native is a great choice for 80% of the apps out there.

I envisioned a mobile app development company that takes a radically different approach to building apps.

How We Create Beautiful Mobile Apps in Half the Time

Here’s the story of why I created Foxbox Digital, a different kind of mobile app development company.

 we needed to build a mobile app to complement our existing web app. We were a team of web developers and didn’t have experience building iOS or Android apps. We reached out to some local app development companies in Chicago to get quotes on what it would take to build the app. The quotes were really high, and that was for 

. And after that, we’d need to have them build the Android app too.

We’re responsible for hosting and supporting the API that actually runs the app. We ended up finding a freelance iOS developer to build the app, and he did a killer job. It cost a ton of money though, and at the end of the day we could only support half our users because the other half were on Android.

 I understand why mobile app development companies charge so much for a mobile app — developers are expensive, and in-demand. But isn’t there a better way?

, Ionic, and Cordova. Ionic and Cordova apps look like native mobile apps, but they don’t feel like them — they’re slow and sluggish. React Native strikes the perfect balance because they’re fast to build, and the apps look and feel like native mobile apps (snappy and responsive). And it’s simply a joy to program the code. 

With a cross-platform framework like React Native, we build both the iOS app and the Android app at the same time. 

This cuts the development time (and cost) in half

Through our engagement with Home Chef, we developed and published both iOS and Android apps using React Native.

This helped them significantly increase app store ratings, meal kit conversions, and user engagement rates. 

The mobile app is only part of the solution though — every mobile app needs an API to power the app. An API is the server and software that the app communicates with in order to do what it needs to do (i.e. get and store data). Once you have an API built, you need to host and maintain it. As a client, do you want to be bothered to maintain an API?

I thought about all of the things that you need to do in order to keep your app up and running in the app stores.

Mobile App — build it, launch it, maintain it (fix bugs and security issues).

API — build it, build servers to host it, maintain it.

Monitor the API to ensure it stays running and respond to issues as they come up.

Upgrade the mobile app every time Apple or Google releases a new phone or operating system. Re-release to both app stores.

Do clients really want to do all of this?

 We’d use reusable building blocks to create the core of the app, and a finely tuned process to develop them. With this approach, it’s much easier to predict how long it will take to build the app.

 that handles everything from design to building clients’ apps to keeping them up & running, for the life of the apps. We’d be a trusted partner to our clients, so they wouldn’t have to worry about anything involved in building or running their mobile apps.

Foxbox Digital creates beautiful cross-platform mobile apps  in half the time. We handle everything involved in running and maintaining your app, for the life of the app.

 and let's come up with a strategy to build it.