Buildfire Technical Questions: Mobile App Development FAQ

You don’t need to learn anything new. Buildfire runs on all of the technologies that you’re already familiar with:

• JavaScript
• HTML
• CSS

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.

With JavaScript, HTML, and CSS, you’ll be able to build for both iOS and Android.

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.

Buildfire uses native technologies—Swift for iOS and Kotlin for Android.

However, you would never know this from a development perspective. Buildfire has done extensive work behind the scenes to abstract away the complexities that typically come with native development—like OS versioning, platform-specific updates, and SDK configurations. For example, you don’t even need a Mac to build for iOS.

Buildfire handles all the heavy lifting associated with native app development, allowing you to focus entirely on using the Buildfire web tool and framework. This means you get the performance and flexibility of native apps without having to manage the native build environments yourself.

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.

Buildfire does not restrict you.

If you want to use React Native or Angular, that’s fine. You can really use any JavaScript framework that isn’t dependent on a server-side rendering. Any of those will work just fine.

Buildfire provides a wide array of backend services to developers.

The entire platform is built on our mobile app building software, 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.

Technically, yes. But there are some contingencies.

It all depends on how you built your web application. If your web app relies heavily on JavaScript, HTML, and CSS, then it will port over fine. But if the web application is heavy in PHP or .net, you’ll probably need to tweak it a little bit before porting over.

We work extremely hard on developing our platform to be highly 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 you must 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.

Yes.

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.

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.

Yes.

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.

No.

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.

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. 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.

Yes.

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.

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.

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.