Application Development

Behind the Software with Embarcadero Technologies' Director of Product Management

The wealth of mobile devices and browsing platforms makes users more accessible than ever for businesses, but optimizing your site for each possible platform can be a challenge for developers, who often have to choose between the  ease of having a single source code and the flexibility of native applications. We talked to Embarcadero Technologies’ Director of Product Management John “JT” Thomas and learned how Embarcadero’s latest product, RAD Studio XE4, brings the best of both worlds to developers.

How did Embarcadero get started as a business and how did you personally get into this segment?

Embarcadero started up in 1993 with the focus on database management tools. In 2008, Embarcadero purchased the group from Borland that created the popular application developer tools. Delphi and C++Builder. When I was a young programmer, I grew up on Borland software, which built products that focused on Windows development and provided a really compelling development experience on Windows to compete against Visual Studio. If you ask anybody who’s been programming for more than 10 years or so, they all have a very strong, positive, emotional tie to the Borland software. Everybody’s used it who has ever done programming around C++ or Pascal. So it’s fun to go to conferences and remind people about Borland. They get very excited.

Since Embarcadero’s purchase in 2008, the focus of these developer tools has really been on enabling multi-device app development and going beyond just Windows development. Our approach is unique because we come from the desktop application road where we’ve had millions of customers writing hundreds of thousands of apps over the years, and we’re helping to bring these guys to mobile, and help enterprises bridge that gap between mobile and PC- form factors on Windows and Mac.

How is your product unique among other developing tools? It sounds like you take a big-picture look at things, from desktop, bridging the gap and trying to kind of create a more unified experience.

I think where more of the uniqueness comes from is in how we do it and the benefits of that approach. If you look at the mobile space today, developers have to make a choice on how they approach multiple operating systems and multiple devices. The fact of the matter is they have to support more than one. There’s not a single developer I’ve talked to out there that said “I can just deliver on iOS” or “I can just deliver on Android.” It’s both. And for the enterprise customers in particular, Windows is still very well supported and deployed within their enterprise. So they have this problem of trying to manage all these different types of devices across all of those operating systems.

With mobile developers, for instance, their two choices are using tools that are provided by that platform vendor – Apple has Xcode, Android has Eclipse Environment called ADK, Microsoft has Visual Studio- or developing those apps using a common source code approach like HTML and JavaScript. The challenge is that for each of these platforms, with vendor tools, they have to manage a completely separate language, code base, and development environment for all of them. It’s even more challenging several years down the road when they have to fix a bug or add a feature, and they have to do it in three different places or four different places, depending on how many they’re targeting, so it’s a very expensive way to approach multi-device. The other approach of using a common source code approach has business benefits of managing a single source code base but it is full of compromises on the app user experience due to the performance penalties of using a JavaScript scripting engine.

Can you elaborate more on some of the major problems companies face right now, in terms of mobile compatibility, that Embarcadero has been addressing?

As I said, a lot of companies have taken the approach of looking at HTML5/JavaScript as a way to gain the benefits of managing a single source code base, but there’s a lot of compromises in that approach. The biggest compromise is that they rely on a scripting engine for JavaScript language that has a lot of deficiencies in terms of delivering a great user experience. The same goes for virtual machine approaches, too, where there’s something that takes that code dynamically at runtime and converts that into something that runs on the CPU. So they don’t have as much tunability. Their reliance on essentially a black box to run their app, and they don’t have a lot of levers to work with to tune their app for best performance– and this relates to predictability, knowing how well your app is going to run, for instance, most virtual machine approaches have what’s called garbage collection, and that goes through at unknown times and eats CPU time trying to clean up your memory. So, now you have to share CPU time with another process that you’re using to run your application, and you have no idea when and how long this is going to run for or how much CPU it’s going to use. It affects the predictability of your application.

Ultimately, this affects the overall user experience, which is becoming even more critical for success on these mobile platforms. Either you’re able to write an app with a great user experience but you’re managing multiple code bases or you’re trying to manage a single code base but you’re giving up a lot of other features and/or performance benefits by taking this approach. So where we’re really unique is that we combine the benefits of both. We provide a mechanism to deliver native applications, which that run directly on the hardware, and the business benefit of being able to write this with a single source code base that you can simply retarget and recompile for each platform that you need to support.

 It sounds like you’re attempting to give users the best of both worlds…you get to keep transparency and control over your development, but you don’t have to compromise on user experience, which is extremely important these days.

Exactly right. We’re seeing more and more people talking about this, where they’ve put a lot of effort into HTML5 or scripting solutions and they had to give up and start over with the native solution because they weren’t able to deliver on the user experience that they needed to.

You mentioned you have some enterprise customers. What’s your ideal customer? Is Embarcadero designed specifically for enterprise businesses?

Historically, we have sold very well to enterprises, mostly on a departmental level, as well as to SMBs and independent software vendors (ISVs) that are targeting consumers or enterprises as well. There’s a new category in the mobile space, especially around consultancies or value-added resellers who are basically helping enterprises get to mobile because they have the expertise where enterprises don’t necessarily have that expertise yet. I think that we’ll continue to be able to target both because we have a solution that crosses those boundaries. You could easily write a consumer-oriented application with some subset of the framework, or you could use a whole application framework including all the database connectivity, cloud support, multitiered kind of solutions that enterprises need.

I think enterprises are going to find us particularly interesting because more than ever they’re tasked with supporting more than Windows, and getting on these mobile devices. It’s a huge challenge to pick the right technology that allows you to deliver that user experience and the performance that people want and at the same time do it in a cost-effective way with an ability to move to new platforms as they become available.

Security is a huge issue. Our readers always ask us about it, and in general it’s a big concern in tech. Why should users feel really confident developing with your product from the security standpoint?

Obviously, security is paramount if you’re an enterprise, because your assets are out there, and that’s your data or your customers’ data, and you can’t let that fall into the hands of hackers. One thing that we wanted to remind people about is that a technology choice can help mitigate your risk. When you’re selecting a solution that utilizes a virtual machine or a runtime interpreter, it becomes a high-yield target for a hacker. In other words, a hacker is more likely to go after something like a Java VM or a JavaScript runtime interpreter because he knows if he can crack that, it will basically enable him to attack hundreds of thousands of apps as opposed to just one app.

So the difference between that type of target versus a native approach like ours is that when you build a native binary, it’s essentially one of a kind. A hacker has to work around your specific binary on each platform to hack into it. So the risk is lessened because it’s just not as interesting of a target. It’s kind of like you see a lot of worms and viruses on Windows than you do on Mac, and the reason is because there’s more yield if you attack Windows than you do Mac.

And additionally in security, connectivity is critical, so our connectivity solutions support all of the standard security standards around SSL and HTTPS, etc., but we wanted to point out to people that when you make a technology decision that is dependent on something that’s a hacker target, you’re at a higher risk, and building a native app puts you at a much…makes you much less of a target.

We mentioned the heterogeny of devices and different platforms on the market right now. What challenges do you think that’s going to present for developers and for companies who want to create apps in the future?

Well, I think there are a lot of challenges. The first would be, how am I going to deliver the ultimate app experience on the selected device? And then the second one is how do I do this in a way that is feasible and/or cost effective and completive…I can get to market faster than my competitor? That kind of goes back to that original discussion about the two choices that people make. Either they’re need to get the best app onto the device and go down the road of using platform vendor tools, or they want need to try to do this in a way that is either more cost effective or allows them to get to market faster.

I think those are the two primary issues that people who need to support multiple devices are going to be faced with. Ultimately, I would argue that going down the path of finding a single source code base is going to benefit you in the long term because there’s a lot of investment that goes into writing code and you can spend time trying to optimize that over time. At the same time, the app experience is becoming more and more important than it ever has.

It seems like in the last year or so this has become something that developers and end users are really starting to talk about because the first generation of applications were really just about enterprises saying “I need to go on these devices as soon as possible. Let’s just take our web asset and make it work inside of a mobile web browser.” And then the followup generation was largely enabled by platform vendors because they provided a way to package web content into an app container. They took their web content that they’ve already invested in, put it into these app containers, and made it look more like an app that’s supposed to run on the device because it can be distributed to the app store and it can have an icon that you can use to launch it.

But end users are a lot more sophisticated than they had been. You can really tell the difference between using something that’s web content or HTML 5 and JavaScript driven versus something that’s truly native. So this third generation says, well, how do we get to that next level of app user experience? I think developers are also starting to recognize that they can do a lot more on these devices than they’re doing now. They’re so powerful. They’re not really taking advantage of that capability in terms of raw CPU horsepower and GPU horsepower that they have on these devices.

So they’re looking at ways to offload things that they would otherwise have to do on a roundtrip back to the server. Let’s say, for example, a fictitious credit card company in the past would offer the ability to generate charts on your spending. Well, that would have to be done on a back-end server somewhere because it’s pretty computational, and then an image would have to be streamed over the wire to get onto the device. Well, now they can do these kinds of things locally and instantly because there’s so much horsepower available to them, and that just delivers a much better app experience. So I think they’re looking for a lot more ways to bring more of that power to the client, and they really need a native solution to deliver on that.

What is Embarcadero doing to anticipate and address any of these challenges?

I think we’ve recognized that native is the answer, and it happens to be something that we’ve been really good at for a long time because we’ve built compilers, we’ve built native developer tools, and we’ve built frameworks. And so we looked at this and said, well, how do we help people do this in a common way across all platforms? So that’s when we built a framework and a runtime library that’s common between all of them. So that’s really how we deliver a solution that helps them solve both of these primary problems. That’s the combination of a framework that they recognize as common between all the platforms and the ability then to compile that app down to a native, executable that’s going to run directly on the CPU.

Right now you’ve just released RAD Studio EX4- how is this latest release different from previous iterations of this product?

In XE2 we first introduced FireMonkey, the cross platform application framework. It’s not just a UI Toolkit, it’s a full application framework, which means it has facilities for generic application development like data structures and containers. It has a full database access layer so that people can talk to their databases and pull data in a common way. It has support for communicating over tiers or on all these common communication protocols. So it’s a very full-featured framework. We started with helping our Windows developers go from the current framework onto the FireMonkey framework so they can start supporting Intel-based devices that were running Windows and Mac. What’s interesting is that Mac – despite the decline in PCs that we’ve been seeing lately –laptop usage of Macs are growing. So this is an important target for application developers, and we started there because it has a common CPU that we had already built compilers for.

In XE3 was Windows 8 coming out and a new version of Mac OS 10 with retina displays. We upgraded the framework to support the latest versions of these operating systems. And we did a bunch in the framework to basically prepare it for getting onto mobile. And so what you saw in the previous version was something that supported the latest standard from Windows which was Windows 8 as well as the latest standard from Apple which was Mountain Lion with the retinal displays.

We took a next step in enabling that framework to not only deliver visually the vast differences between these two operating systems but to prepare us to bring this to mobile. While we were doing that we were building new compilers that could target our processors. And so that was critical to delivering native apps on mobile devices because they all run ARM processors not Intel processors.
Now we can have developers take source code that they’ve written with FireMonkey and compile it and target it on ARM, targeting Apple iOS. So this is the next step in our multi-device strategy. And in later half of this year, we’re going to deliver an Android developer kit that re-uses everything that they’ve written for iOS, all they would have to do is retarget it for Android. No change in the source code. And they have a native app running on both iOS and Android with a common code base across all of them. The thing that we’re doing that’s different than others is that we’re saying if you build iOS apps now with XE4, your basically building Android apps with FireMonkey (our framework) now, because as soon as we get you that compiler, you retarget it and rebuild and you’re done.

Anything else you’d like to tell our readers about your product?

Our tooling has always delivered a visual design experience, which means you are visually building your application, not just the UI layout but also all the actions to move between; when you move between one form and another, what kind of code drives that? What kind of application logic is driven there?

We call it rapid prototyping because it’s unlike current prototyping tools where you have a designer working on his own to mockup an application and share with somebody on PowerPoint or in a tool like Photoshop or something. Then he hands that over to a developer, and the developer goes, “wow, how am I going to possibly deliver this when the designer had no constraints like I do? He didn’t understand the challenges of making something look like this on iOS, for example, or work like this across multiple operating systems.”

So the difference between that type of approach and ours is that when people prototype with our tool, they’re actually building an app. They’re designing their actual application that uses real framework objects. It generates real code for them, they compile a real application that they share with their customer as the prototype to get that feedback. And so it’s a much more genuine experience with your end user because it is the app, it’s the skeleton of the app. And you get they buy-in really early, which is important, absolutely important for actual practices today and mobile because they’re such quick iterations to deliver applications. Prototyping is one of those practices that really enables that.

With RAD Studio EX4 you can get that feedback very quickly and you’re already halfway there because you’ve already used the framework to generate a bunch of the code and now all you have to do is plug in your application logic to finish the application. Rapid prototyping is a key part of our solution that can’t be understated. In addition to one team on code base and the ability to deliver a native application that has full application framework support around database connectivity and security, you also are able to do this in a much more cost-effective way through this rapid prototyping feature.

Want to learn more about Embarcadero? Check out RAD Studio XE4 and the rest of their products at www.embarcadero.com. If you’re looking to get more info about some of the other application management platforms out there try taking a look at our Top 10 Application Lifecycle Management Software report.