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