Major Issues When You Use Mobile App Builders

Having a brick-and-mortar location isn’t enough for the average business anymore. Rather, both large and small businesses need to take the time to build an online presence for themselves. This connects them with their customer base directly and makes it easier for potential customers to find the business. 

Specifically, apps have a special level of potential. When a company has an app, they’re likely to see higher profits, increased customer loyalty, greater brand recognition, and more business from each customer. Smart Insights put the benefits and cost of mobile apps well in their infographic.

However, there is more than one way that developers can tackle building an app. One of the first answers that come up in response to the need for an app is often to use a mobile app builder. Yet, these have some key disadvantages that you need to know. 

Limitations of Template Design

Mobile app builders put a focus on beginners and busy teams that don’t want to worry about custom coding. While convenient, this comes with an unfortunate drawback. It’s difficult to make a striking and unique product when starting off of a generic base. This is a major risk in a market in which, according to Statista, there are currently almost 2.5 million apps with additional ones being released every day. 

In addition, it’s very hard to fundamentally change a template. So, even if developers have the expertise to make changes, it’s going to be difficult if not impossible to achieve the same results as an app developer company when using a mobile app builder. Once again, this limits individual creativity because it won’t allow developers to heavily adapt to the company’s distinct tastes, aesthetics, and needs. 

Access to Limited Features

The features that mobile app builders offer also come back to the downfall of their simplicity. Because users are catered to in a way that doesn’t require them to custom code or program anything into their apps, many mobile app builders are designed with a drag-and-drop feature.

In these cases, there are a number of predetermined features available in the app builder. When developers find a feature they want in their app, they basically drag it into their workspace and drop it where they need it to go. The exact way that the builder works vary from software to software but the general concept is usually the same.

To be fair, there are plenty of mobile app builders that have wide libraries of features to use in apps created on them. That being said, any library of pre-set features is, by nature, limited. Much like templates, this inset limitation isn’t inspiring when it’s juxtaposed with the need to stand out from a crowd of other apps.

Dependence on the Platform Used In Development

When an app is created from scratch by a development company or team, there isn’t a platform that the app is dependent on. On the other hand, when an app is developed on a mobile app building platform, it’s dependent on that platform. If the platform changes or, in the worst-case scenario, shuts down, your company may struggle to update or even regularly maintain the app without transferring it to a new platform or system.

This also comes down to ownership as well as functional convenience. If your company uses a mobile app builder to create an app, it only partially owns that app. After all, the app isn’t just created with the company’s intellectual property but with the technical property of the app builder.

The problem with this is that many mobile app building platforms hold some control over the content created on them. If a problem arises or if the company that owns the platform isn’t entirely trustworthy, the platform is well within its rights to delete or lock a user out of their account or even refuse to continue future service with them. If your business loses progress on an app, it can cause a noticeable decrease in profits, damages to customer relations, and the cost of recreating the app in a different form.

mobile app

Dedication to a Single Platform

As just mentioned, when a company builds an app on one of these app building platforms, they give up some of their ownership rights to that app. One of the other consequences to these terms is that many companies struggle to transfer their app from one platform to another.

If your company is using the app builder to create an Android app, for example, this can be a particular problem. This is because if they decide to expand the app, such as creating an iOS version, by taking it to another builder, they may run into problems with the terms of service for the builder they’re already using.

Additional Charges from a Mobile App Builder

A surprising fact for many developers is that building a custom app with an app development service can oftentimes be less expensive than using an app builder. A big part of this is thanks to the set fees that app development services set out at the beginning of their time working with a company.

Mobile app builders vary slightly here. Of course, they have an upfront cost of using the platform but this often changes over time. For instance, as the app grows, it will need more space for data storage. Also, certain features may need to be upgraded to handle higher volumes of traffic.

mobile app

When this happens, though, mobile app building platforms may charge additional fees for these additional features. This means that the investment in the tools used to create, maintain, and upgrade the app can exponentially increase over time. 

Mobile App Builder: Conclusions

A mobile app builder is enticing, in large part, thanks to the convenience and ease of use. However, it would be misleading to think that these are the perfect tools. From the inconveniences of limited design choices to the legal challenges of sharing ownership of the app, these platforms make the development and maintenance process more challenging than it needs to be. As an alternative, working with an app development service will offer companies a custom app with less red tape to complicate the process.

Additionally, there are various tools you can use for app development. If you are into ARVR apps, we have created a list of Top 5 Tools for Augmented Reality in Mobile Apps.

What has been your experience of working with mobile app builders?


Popular ICEs for mobile hybrid app development

If you want to target multiple mobile platforms without having to maintain a separate code base for each one of them, mobile hybrid apps is one way to go. What mobile hybrid apps won’t do, though, is relieve you of the need to manage and use multiple tools, e.g. building your app for a specific mobile platform requires installing the platform’s native SDK on your machine.


ICEs are here to take this headache away. ICE stands for Integrated Cloud Environment and it’s essentially an IDE that does some of its work in the Cloud. A typical ICE for mobile hybrid app development provides you with tools to design, write, test, debug and profile your app. It also allows you to configure the build settings of your app, manage its signing keys and compile it for various platforms.

[tweetable]One of the most popular features of ICEs is building your app in the Cloud[/tweetable] – they grab your code, upload it to the Cloud, build it and come back with the produced app bundle(s). Since the build process no longer takes place on your machine, there is no need for you to install any native SDKs. Apart from building, ICEs may also use the Cloud for storing your app or for pushing it to a device for testing purposes.

A mobile hybrid app development ICE traditionally comes with a companion mobile app that can be downloaded for free from all major app stores. This companion app acts as a container for your own app (your app runs inside it, so you not need to install the former on the device) and also provides some extra functionality (e.g. checking for new builds of your app).

So, here are four of the most popular ICEs for mobile hybrid app development (PhoneGap Build is not really an ICE as we’ll explain later on). But before diving into the details, the following tables provide a handy overview of these tools.

Tool Owner Free? Type
AppBuilder Telerik No Desktop-based (Microsoft Windows), Browser-based
Intel XDK Intel Corporation Yes Desktop-based (Microsoft Windows, Ubuntu Linux, Apple OS X)
Monaca Asial Corporation Yes * Browser-based
PhoneGap Build Adobe Yes * Browser-based

* A free subscription plan is offered (among others).

AppBuilder Intel XDK Monaca PhoneGap Build
Code editor
Drag-and-drop tool(s)
Source version control
Device simulator
On-device debugging
On-device profiling
Companion app


With AppBuilder (previously known as Icenium) you can develop your app in collaboration with other members of your team, using both a code editor and a drag-and-drop tool (experimental and limited to apps that use Kendo UI).

AppBuilder allows you to test your app on a built-in device simulator, on native emulators installed on your machine, as well as on real devices (both connected and remote). In the case of real devices, you can either install your app or run it inside the AppBuilder companion app.

While your app runs on the simulator or on a connected device, you can debug it using the bundled debugger that’s based on Web Inspector. AppBuilder also allows you to automatically reload your app as you make any changes to its source code.

❢ AppBuilder offers Cloud-based storage and version control for your apps.


Intel XDK

Intel XDK contains a bundle of tools: a code editor that is based on Brackets, two drag-and-drop tools that help you design your user interface (one supports App Framework, Bootstrap, jQuery Mobile and Topcoat, while the other is limited to App Framework), and a device simulator that is based on Apache Ripple.

In addition, Intel XDK allows you to test your app on real devices that are connected to your machine or are in the same wireless network as your machine. In both cases, you need to have App Preview (Intel XDK’s companion app) installed on your device. Similarly to Telerik’s AppBuilder, Intel XDK automatically reloads your app (if you’re using an Android handset) as soon as you make changes to the source code.

With Intel XDK you can also debug and profile a running app. On the device simulator you can use a debugger that is based on Chrome Developer Tools (CDT). On a real connected Android device (with both App Preview and App Preview Crosswalk installed on it), you can use weinre (WEb INspector REmote) and a built-in profiler that helps you identify hot-spots in your Javascript code.

❢ Intel XDK supports live layout editing. While your app is running on a connected Android or iOS device, you can preview the result of the changes you make to your HTML and CSS files as soon as you hit save.



Monaca allows you to collaborate with other testers and developers on developing your app. You can chat with them as you write code, and share your thoughts, as well as screenshots of your running app, while debugging it on a real device.

With Monaca, you can preview your app in a browser (with different device screen sizes and orientations) or run it on real devices inside Monaca Debugger (the companion app of Monaca). In both cases your app gets automatically reloaded every time you make changes to the code and save them.

You can debug your application in preview mode, using the debugger that comes with your browser. Alternatively you can debug on a real device, using Monaca Debug Panel, a tool based on Web Inspector. Some debugging features are also available on the real device; for example, you can view the source of the current page or inspect the application log.

❢ Monaca stores your code in the Cloud, and you can access it at any time and from any place using WebDAV.


PhoneGap Build

PhoneGap Build is not really an ICE, but rather a build service that works in the Cloud. It pulls the source code of your app from either a .zip file or a (private or public) Git repository, and then allows you select the platforms you want to build your app on. Throughout the building and testing process, PhoneGap Build enables you to collaborate with testers and developers from your team.

PhoneGap Build allows you to build debug-enabled and/or “hydrated” versions of your app. With debug-enabled builds you can remotely debug your app using weinre, whereas new hydrated builds can be automatically pushed to the devices and replace older ones.

❢ PhoneGap Build does not store the passwords for your signing keys for more than one hour since the last time you used them.


To sum up

Mobile hybrid apps allow you to target multiple mobile platforms with less code, in less time, and with fewer programming languages. ICEs for mobile hybrid app development move parts of the development process in the Cloud (e.g. they build your app there), thereby adding one more benefit to the above list: fewer tools.

There are several reasons for trying out an ICE – the choices differ according to what you’re trying to achieve. If you enjoy writing code on the Web, you can use Monaca, while if you want to spend less time on writing code, AppBuilder’s and Intel XDK’s drag-and-drop tools might make your life easier. Keep in mind that using an ICE does not require abandoning your current editor or IDE – you can use any editor or IDE you like and then import your code into an ICE to test, debug or build your project. Finally, there are some cool features in this post that might have caught your eye – e.g. Intel XDK’s remote profiler or Monaca’s collaboration tools. So, get started with an ICE – and let us know what you think!

Update Dec 15, 2014: Monaca kindly informed us they also provide full debugging functionality via USB, using Chrome on Android and Safari on iOS devices.


Cross Platform Apps – Qt vs. HTML5

Although building a separate native app per platform is currently proving to be the most successful approach for mass market consumer apps, there are still a lot of situations where it makes more sense to go cross-platform. In this article we’ll look at the most popular option, hybrid web apps built with HTML5, versus an up-and-coming challenger, Qt.


How do you build web apps? Take the Developer Economics Survey and let us know. Cool prizes await you.

Why Qt?

Those who know the history of Qt may be surprised to see it described as “up and coming”. Qt was originally designed for building cross-platform desktop apps, it’s creators started working on it in 1994! However, Qt became interesting for mobile development after Nokia bought Trolltech, the company developing Qt at the time, and invested heavily into making it the ideal toolkit for building mobile apps. Unfortunately, Nokia was making this strategic decision shortly before the iPhone launched (the acquisition was completed afterwards). This changed the game from building apps for devices with numeric keypads and Qwerty keyboards, to large touch-screen based devices. The former Trolltech engineers recognised that they needed a very different way of creating apps for Nokia’s offering to compete.

When Steve Jobs said that the iPhone was 5 years ahead of the competition at launch, he was not far wrong. Android had managed to close some of that gap, probably due to executives at Google having some advanced warning about the iPhone. Unfortunately, Nokia eventually gave up on it’s own Qt based devices in favour of Windows Phone as the software efforts were taking too long and they were falling a long way behind in the ecosystem wars. They sold Qt to one of their major services company suppliers – Digia – who have recently established a fully-owned separate entity for the product, The Qt Company. Only after being fully disentangled from Nokia has Qt been able to return to its roots as a cross-platform framework and start supporting the major mobile platforms. However, in the mean time, others had seen the great foundation for mobile apps that Nokia’s investment created. As a result the BlackBerry 10, Jolla Sailfish, Ubuntu Mobile and Tizen platforms all have Qt as a core framework.

From a personal perspective, I re-wrote a popular iOS game for Symbian using Qt in early 2011. The UI design and general debugging tools were a bit immature at the time but it was one of the simplest learning curves and most pleasant development experiences I’ve had on any platform (note: I was not paid to say that), even though the core of Qt is using the less than developer friendly but high performance C++. I was able to achieve smooth 60fps performance on some rather low-spec hardware. It was easy enough to learn their new UI technology, Qt Quick, and build the menu screens for the game with it in a couple of days.

Why HTML5, or why not?

HTML5 is the most popular option for developers building cross-platform mobile apps, however, it appears to be falling out of favour a little. Web browsers and web views are available on every platform and web developers are able to transfer their skills from building websites to building mobile apps. Open source frameworks like Cordova (PhoneGap) allow developers using HTML5 to access additional mobile specific functionality and make it easy to package apps in a native format for each platform. The added bonus is that you can usually have a version of your app on the web as well as in the app stores for minimal additional effort. HTML5 is generally more productive for building UI centric applications than native apps. There is also an embarrassment of riches when it comes to libraries and frameworks for building mobile web apps. Hybrid web apps are in the privileged position (on iOS at least) of being able to update their code directly, avoiding the App Store review process for all but major changes.


Given its ubiquity and large developer base, why isn’t HTML5 the default cross-platform approach? [tweetable]Despite many advantages, hybrid web app developers have been struggling with performance[/tweetable] (partly due to crippled or outdated webview implementations, an issue which has been fixed in the latest versions of iOS & Android, although this will take a while to penetrate the entire installed base). There is also an issue with varying levels of support for standards across mobile browsers (again, this is something that’s improving but not entirely fixed yet). Web technologies have also not really been designed for the highly animated UIs that are now expected by mobile users. This is something that the much hyped framework aims to resolve.

A number of very high profile consumer startups have publicly switched from web hybrid to native mobile app approaches. The most common reason stated for these switches has been lack of adequate tooling. It’s certainly possible to make web apps perform well on mobile devices within their limited memory budgets but with the current state of debugging and profiling tools, that’s still not an easy thing to do compared to producing native apps. This said, not all apps need flawless UI animations and we’re not comparing HTML5 with native, so lets look at how it goes head to head with Qt.

Qt vs. HTML5 – Pros & Cons

Supported platforms:

  • HTML5 is supported almost everywhere.
  • Qt is supported on all major platforms (and minor ones that happen to use it for their UI).

Although in theory you can target more platforms with HTML5, this is not how most developers are using it in the real world. [tweetable]HTML5 developers are increasingly abandoning the browser and building hybrid apps[/tweetable]. Most mobile developers are targeting some subset of Android, iOS, Windows Phone, Windows 8 and BlackBerry 10. Qt supports all of these and more. In fact, in practice our data shows that Qt developers actually target fractionally more platforms on average than HTML5 developers. As a result, this is basically a tie for most developers with a significant advantage to HTML5 for those who really want to run their software everywhere (feature phones, Smart TVs etc.).


Learning curve:
This one depends whether you’re already a web developer. If you are, learning to build mobile web apps is probably easier than learning Qt. However, if you’re new to either then Qt has significant advantages in terms of having one framework to learn rather than 10s of them to choose from before you even start. Qt also has great documentation, which isn’t necessarily true for all web frameworks. In a fair contest, this is a clear win for Qt.


  • HTML5 is open standards based and there are multiple open source implementations.
  • Qt is open source but dual licensed and effectively controlled by a single vendor.

Clearly HTML5 is more open than Qt. This isn’t always an advantage. The process of creating standards and getting multiple vendors to implement them is slow, Qt can be more agile. If you really need something fixed or a new feature added in open source you can do it yourself or pay someone to do it. If you need to support Internet Explorer and there’s an issue with it, you have to work around or wait for Microsoft. Then again, there’s no vendor lock-in with HTML5 and the web isn’t going anywhere. Someone else could buy Qt and take it in a direction that doesn’t align with your goals. Or they could just put the price up beyond your budget. HTML5 has the edge but it’s not a clear win.


  • Building for HTML5 is free. There are some non-essential paid tools that can help.
  • Qt requires a commercial license for most commercial use on mobile.

Qt’s open source licenses are not compatible with distribution on most app stores. Although the iOS port of Qt is developed in open source, you need a commercial license to ship apps in the store. The lowest cost subscription that allows developing mobile apps for the iOS & Android stores with Qt is $25/month. HTML5 wins.

Cross-platform compatibility:

  • HTML5 has multiple independent implementations of a standard.
  • Qt has one vendor implementing the same runtime on multiple platforms.

Multiple implementations, with several in open source and a large community reporting on and working around compatibility issues makes for a very robust platform. Even so, having a single vendor making sure all platforms behave in the same way is almost always better for compatibility of your app. Qt wins.


  • HTML5’s DOM was not built for modern mobile apps.
  • Qt Quick’s (QML) scene graph is built directly on top of OpenGL ES.

Both environments use JavaScript. However, with Qt it’s much easier to drop down to native code if you really need native platform functionality or performance. The performance penalties for switching between JavaScript and native code are much lower with Qt. The biggest difference however, is graphics performance. People looking for serious graphics performance with HTML5 resort to complex schemes to avoid touching the DOM as much as possible. Building the entire UI on top of WebGL seems like the most promising path to future performance, now that WebGL has much wider support (Apple adding this in iOS8 is key). Qt has a massive advantage here, it also has more extensive animation options than CSS3 for web app developers.

Native user experience:

  • With HTML5 you rely on either a 3rd party framework like Ionic or building your own clones of native interface elements.
  • With Qt you can use components that clone native interface elements, or use real native UI calls.

Being able to call native APIs in Qt potentially gives it the advantage here but in reality this loses cross-platform compatibility. In practice neither option is really well suited to situations where you need a genuinely native user experience. Both can emulate one adequately for a subset of possible apps. In general it’s best to use a cross-platform approach where a fully custom UI is needed, or a native look and feel is not essential.


Comparing across these metrics, Qt has a slight edge over HTML5. However, there are other metrics you could use that would give the opposite result. In practice the technology needs to be selected to fit the project. Both options have merits and if you’re an HTML5 developer who’s not already familiar with Qt’s offerings, they’re worth a look. I also didn’t mention that Qt apps can display HTML5 content in a webview, meaning that it doesn’t have to be one or the other, it can be both.


Which one do you prefer? Take the Developer Economics Survey and let us know.

Platforms Tools

Mobile Platform Wars: Winners & Losers in 2012

[This post first appeared on the VisionMobile blog on 9 July 2012.] The game of ecosystems is in full bloom, with each player attempting to draw as many developers as possible around their platform. As we finally see some signs of consolidation, VisionMobile Senior Analyst Andreas Pappas, talks about mobile platform wars, the rules of engagement and identifies the winners and losers in this game of ecosystems in 2012.

Moreover, we’re proud to introduce VisionMobile Visualisations – live. These are interactive graphs with tons of data from the Developer Economics 2012 research!