Building the Aquicore Mobile App

Launching the Aquicore mobile app was a massive undertaking, requiring more than a year of work and the efforts of almost everyone on our development team. Unlike the new features on the Aquicore roadmap, the app had to be built from the ground up, making it a particularly rewarding challenge. We sat down with Trevor Atlas, one of the developers who spent the most time working on this project, to find out what it was like.

Aquicore: So first of all, are you excited to have gotten the mobile app out the door?

Trevor: Yeah, it’s cool to work on something for so long and then finally people can use it; it’s a real thing in the world. You can go to the app store and you see this thing we’ve been working on. So yeah, it’s pretty cool.

Aquicore: How would you say that working on the app is different from working on the rest of the Aquicore platform?

Trevor: The main differences come from the fact that our platform is mainly a web application, so you don’t really have to think about things like, will the device camera work in every case? Is there a specific driver for Android or iOS that causes an issue that we need to account for? Does the way the mobile app handles notifications work with the way the platform thinks about notifications? There’s always little minutiae that you have to account for that either don’t exist in the platform as it exists and so we have to build it or that come from differences between mobile devices.

Aquicore: Is there something fundamentally different about starting a project from scratch versus adding new things on top of an existing platform?

Trevor: Yeah, [with work on the platform] it’s just another module in a giant existing application. With the mobile app, it’s totally different because you’re writing code that is essentially going to run on mobile device hardware, versus on the platform it’s all in the web – we don’t have to think about hardware at all.

For example, when we do mobile app releases, a lot of the time we’re checking for specific bugs; like, the camera might not work for a specific model of Android phone and you have to debug that. In the platform, we don’t have to think about cameras; there isn’t a camera.

Aquicore: What kind of challenges did you face in building the app?

Trevor: There are two kinds of challenges that you really run into. First, there’ll be architectural challenges, where you’re trying to solve something that has not been solved yet. And so you have to sort of pave the way forward, even if it’s a little less than perfect or not how you’d want to do it.

The other half of that is taking in user feedback and requests and figuring out questions like, ‘what does that even look like? How do we achieve this goal in any capacity, architectural or not? What does this screen in the app need to do so that we can accomplish this goal that they have?’

Aquicore: Can you talk a little bit about cross-platform development versus native or hybrid development and why you chose the path that you did?

Trevor: Really, I think it came down to the fact that we want to service as many users as possible as quickly as possible, and none of us had done platform-specific mobile development – like, Android only or iOS only. The platform we’re using, React Native, does both of those at the same time and it’s technology we’re already familiar with, so [cross-platform development] just made the most sense with the work experience we have. React Native basically abstracts away iOS- and Android-specific stuff; we just write an app that runs on both and it handles all the intricacies of making that work.

Aquicore: You used React Native for the app and something called Angular for the web app. What did you like or not like about using React Native versus Angular?

Trevor: The main differences are that React Native is just a UI library, which is basically how everything looks, whereas Angular is a full framework that does everything; it does HTTP, making web requests, it has polyfills for literally everything you can think of, like making sure something is a phone number or an email address, for example. To boil it down, Angular is like the kitchen sink – it’s everything – and React Native makes nice UIs across mobile platforms.

Aquicore: So was working in React Native new for you? What was the learning process like?

Trevor: React Native, yes. React [the web app version], no. And React and React Native are very, very similar. The biggest difference is that the mobile app uses something called “redux,” which is a new way of thinking about how your application saves things and recalls them later, like a list of users for example. It’s a very different way of thinking about it, so that was probably the hardest learning curve.

Aquicore: If you had to start again from scratch, with the lessons you’ve learned in making the app, is there anything you’d do differently this time around?

Trevor: Well, it would probably go a lot faster because we have a general sense of how we’ve done the architecture up to this point. And most of us hadn’t worked on a mobile app – or at least I hadn’t – so a lot of it would just be clearer. I think we have a much better idea now of what users want the app to do and what makes sense for them.

Aquicore: Are there any features or elements that you’re especially proud of?

Trevor: I think Notes is a pretty cool feature. We’re hoping it becomes a main part of the app, because we’re building it into everything pretty much. So you’ll be able to take a note about the energy curve and optimization or use it as a conversation starter for an alert or just create one with a photo because some piece of equipment is malfunctioning and you want to document it. It’s very flexible.

The Aquicore mobile app is available for Apple iOS and Android.