As the CTO of BuildFire, I get asked dozens of technical questions on a daily basis.
I decided to take some real questions from actual developers and turn them into an FAQ-style guide for BuildFire’s platform.
The questions and answers in this guide are definitely geared towards those of you who are technically-inclined. They were asked by developers who, at a minimum, have a basic understanding of coding—even if it’s just web development.
Let’s dive in.
You don’t need to learn anything new. BuildFire runs on all of the technologies that you’re already familiar with:
We made it super simple for web developers who are trying to go mobile for the first time. Plus, mobile developers can keep everything consistent with the languages they already know.
BuildFire does not restrict you.
Technically, yes. But there are some contingencies.
Yes. BuildFire is using Cordova under the hood.
However, you would never know this. BuildFire does a ton of work to tweak Cordova to ensure you won’t have to deal with versioning, OS updates, and things of that nature. For example, you don’t have to actually develop on a Mac if you’re building an app for iOS.
BuildFire masks all of the headaches that you might have with setting up the Cordova platform and software development kit for it. We take care of that, so you only have to deal with the web tool and BuildFire framework.
BuildFire provides a wide array of backend services to developers.
The entire platform is built on our MBaaS, which is available to all of our developers. However, it’s important to understand that our backend services are not mandatory.
If you want to use your own backend system—that’s fine. As long as your system has a REST API, just go ahead and integrate your own backend.
However, for those of you who are looking for a CMS, BuildFire provides one to you. If you’re looking for a database to house your data, BuildFire has that as well. We have analytics servers, push notification servers, authentication servers, SSO integration, and much more.
All of this is provided as part of the BuildFire platform. But feel free to use anything you have on your own if that’s what you prefer.
BuildFire allows you to build for both iOS and Android, phones, and tablets. It even supports some of your functionality for offline mode, which is very important for advanced features.
PWAs (progressive web apps) are supported on BuildFire as well. So for those of you who want to have more agnostic platforms or solutions for web users, BuildFire provides the PWA experience for those people. Users can install a PWA with an icon on their home screen, just like a native app.
In short, BuildFire supports all three—iOS, Android, and PWA.
We work really hard on developing our platform to be extremely secure.
BuildFire is hosted on AWS, so Amazon has its own security mechanisms in place. We also utilize AWS’s features to test and harden our servers on the backend. Our enterprise customers have the ability to run periodic penetration tests on our servers so they can be sure that everything is absolutely secure.
Obviously, all of this covers the infrastructure that BuildFire provides. But if you’re using your own infrastructure, then it’s up to you to secure it.
In terms of redundancy, BuildFire has a minimum of three copies of your data at any given time—live replicated.
Our primary database is replicated to two secondary live databases. We also grandfather copies of the database nightly to make sure that we have an extra copy in case something were to happen, such as the data center burning down.
In addition to GDPR, BuildFire is also CCPA compliant. We know that compliance is continuously changing, with new rules and regulations always coming in. We’re striving really hard to stay up to date with any compliance issues.
Some parts of your application and some apps will need extra levels, like FERPA or HIPAA compliance. Those particular apps will be built in a custom way to make sure they are compliant through whatever those requirements might be.
We have a wide array of examples that we’ve done this for. It all depends on the level of compliance required for your app.
Publishing can be one of the biggest headaches for customers, especially dealing with all of the policies in place for particular app stores. We completely understand that this can be an issue for you.
While we can never guarantee 100% that every app submitted will go through to the app stores, we’ve developed so many apps that we know how to work within those policies. We’ll help make sure that your app follows the guidelines set forth by Apple and Google.
Guidelines are constantly changing. You can always trust BuildFire to stay up to date with those changes. This ensures that your app goes through smoothly if it doesn’t violate any app store policies. So you won’t have to worry about this.
This is a valid point. Any time you’re dealing with a platform, intellectual property will be a top concern, especially with platforms that are open source.
But think of it like building an application in Amazon. You don’t necessarily need to have Amazon’s intellectual property for you to own yours.
The same concept can be applied to BuildFire.
BuildFire is a platform. Anything you build custom within that platform is your own intellectual property. So for those of you who are building custom functionality, that intellectual property is 100% yours—BuildFire does not own that.
We do have some customers that build on top of shared IPs. Something that’s open-source or shared for BuildFire will stay the same. Anything open source remains open-source. Anything on a shared IP will be shared intellectual property.
Naturally, Apple and Android have particular size limits for what you can put in your app to download. For example, if you have videos in your app and you embed them within the IPA or APK, that has a file size limit.
However, most of your data will be available online. So you only download what the user needs when they need it.
This also helps you with over-the-air (OTA) updates. Whenever you have new content being put out, it’s not going to the phone—it’s going to the cloud, and then being pulled from there. So users can get fresh content.
As mentioned earlier, yes—we support offline mode.
However, BuildFire has a wide array of plugins within the marketplace. So while the platform itself supports offline mode, we don’t guarantee that every single plugin in the marketplace does.
Some plugins won’t make sense to support offline. For example, if you’re dealing with live chat or a YouTube integration, neither of those make sense in offline mode.
But your app and infrastructure will be supported offline.
Yes. That’s one of the most popular integrations that we offer.
For those of you who don’t know what Zapier is, it’s a great company that just deals with integrations. They assist with integrations between databases, email servers, and just about anything you can imagine. I believe they offer over 1,000 integrations at this point.
So if you have some backend database that you want to integrate with the BuildFire servers but don’t want to pay developers to do that, Zapier will be an excellent alternative.
You need to have an invitation to see the BuildFire integration with Zapier. But yes, we do have a Zapier integration for features like push notifications, data, user management, and things of that nature.
BuildFire lets you build on whatever platform you have. We take care of the rest for you.
You don’t need to even own an iPhone or a Macbook to build an iOS app. If you’re working on Linux, Windows, or using Android devices, you can still develop for Apple.
The ability to use whatever device you want is part of the BuildFire platform.
Our authentication servers have the ability to support SSO (single sign-on).
As long as your backend server supports OAuth2, you can integrate an SSO system where you are the single source of truth, and the app sends your servers the user names and passwords to make sure everything is authenticated. If the login information is authenticated, then it ports over to the BuildFire platform.
So your current usernames and passwords should work just fine. But your backend system needs to support OAuth2 and SSO.
It’s basically a list of server-to-server APIs that we provide for enterprise customers who have a backend server and want to communicate with the BuildFire backend servers.
So if you have anything that wants to integrate with the app itself, you can do that with a regular REST API—no problem. But sometimes, for more advanced apps, your backend server might want to communicate with our backend system.
That’s what the BuildFire gateway is for. It’s still APIs, it’s still REST, and you’re still dealing with lots of JSON data, but the gateway is meant for server-to-server communication.
At BuildFire, whatever we commit to, we make sure that it’s supported.
Whenever we build an app for you, there’s an SLA that you enter into. This agreement basically says that if something regresses in your app, BuildFire will make sure that it continues to work. For example, if Apple comes out with a new device with a notch (which they’ve done), BuildFire will make sure that the app still functions properly.
Anything that regresses due to a failure or due to a change in the mobile environment, BuildFire supports through the SLA to make sure it’s always up to date. There is no additional cost to you—the SLA covers it all.
Thanks for all of the questions!
If anything is unclear or you have additional concerns that haven’t been answered, feel free to reach out at any time. Good luck with your next development project!