Categories
Tools

Android cryptography tools for beginners

android cryptography tools

Mobile applications draw the attention of hackers more and more each day because they have something that the attackers want, user data. Hard-coded secret keys, personal information stored in plain text on SD cards, usernames and passwords found unencrypted in databases, analytics collected and sent in the clear to remote servers, are just a few cases that make the life of an attacker easier. This post focuses on Android Cryptography tools for beginners

android-cryptography-tools-for-beginners

How do you go about protecting your users’ data? Take the Developer Economics Survey and let us know. You might win amazing prizes and new gear.

Cryptography is the right tool to use in order to protect sensitive data, and ensure confidentiality and/or integrity. On the other hand, [tweetable]cryptography is hard to use and easy to misuse[/tweetable]. Note that broken cryptography (e.g. using insecure algorithms or hard-coding keys into binaries), is listed in the top 10 mobile risks for 2014. So what’s the lesson to be learned? Well, whereas not using cryptography can be bad, not using cryptography in the right way is just as bad (not to mention time-consuming).

Let’s see then how cryptography can be used in a way that’s both easy and appropriate, in order to develop secure applications for the Android platform.

First, an overview of some popular cryptographic libraries that can be integrated into Android applications. Cryptographic libraries can be seen as cryptographic toolsets that contain tools, such as encryption algorithms, padding schemes, and hash functions.

Bouncy Castle

The Legion of the Bouncy Castle is a charity from Australia that has written Bouncy Castle, a widely used library that provides both a light-weight cryptography API and a Java Cryptography Extension (JCE) provider. The Android platform already ships with a cut-down and outdated version of Bouncy Castle (with small changes in order to make it work on Android). Consequently any attempt to build and use the latest full version of the library in your application, results in classloader conflicts.

Spongy Castle

The motivation behind Spongy Castle is to allow Android developers to bundle any version of the Bouncy Castle library they want with their applications. Spongy Castle is basically a repackage of the latest version of the Bouncy Castle library; all org.bouncycastle.* packages have been renamed to org.spongycastle.*, and the Java Security API provider’s name has been changed from BC to SC.

OpenSSL

OpenSSL is an open-source toolkit that provides implementation for the SSL and TLS protocols, as well as a general-purpose cryptography library. OpenSSL has been ported to many platforms, including Android. As an alternative, you can also build it from source (using the Android NDK) and bundle it with your application.

Let’s assume now, that for application purposes, you want to encrypt some data. What encryption algorithm should you use, AES or DES? How long should your key be, 128 or 256 bits? Which encryption mode should you use, ECB or CBC? If you do not have an answer to all these questions, along with a good reason for each answer, then it seems that you have found yourself in a position where, although you probably have all the tools you need, you are not absolutely sure which ones to use and how.

This is exactly the point where cryptographic toolkits for dummies come into play. These toolkits do not implement any exotic cryptographic functionalities, nor do they intend to replace the cryptographic libraries presented above; they rather built on some of them with the sole purpose of making cryptography easier and safer to use.

Contrary to a general-purpose cryptographic library, such a toolkit normally supports only a subset of the algorithms, modes, schemes, parameters, and other cryptographic tools that are out there. Instead it provides you with sensible defaults in case you (a) know what you want to do but don’t know how to do it, or (b) don’t really care as long as you end up with a safe solution. Let’s examine some of these toolkits to better understand their role.

Keyczar

Keyczar is an open-source toolkit originally developed by two members of the Google Security Team. It has implementations in Java, Python and C++. It supports authentication as well as both symmetric and asymmetric encryption. Keyczar provides safe defaults for algorithms, key lengths and modes, key rotation and versioning, automated generation of initialisation vectors and authentication codes, and internationalisation. This specific toolkit is based on JCE, and its demo for Android (available here), uses Spongy Castle’s security provider.

AeroGear Crypto

AeroGear Crypto is a small Java library provided by AeroGear. It supports authenticated symmetric encryption, elliptic curve cryptography, and password-based key derivation. It also provides sensible defaults for algorithms. AeroGear Crypto depends on Spongy Castle for Android and Bouncy Castle for other platforms. The library is also available for iOS, Windows Phone and Cordova.

Conceal

In an attempt to find a fast and memory-efficient way to encrypt and authenticate large files on SD cards, Facebook developed Conceal. Conceal supports both authentication and encryption, and provides default implementations for key management. It uses OpenSSL, but includes only the necessary parts of it, thereby keeping its size at 85KB. Results published on the site of the library show that Conceal outperforms Bouncy Castle.

A summarised view of the libraries presented above is given in the following table. Note that, although all these libraries aim to safely fill in the gaps for developers that are new to cryptography, advanced developers can skip the defaults and specify all the details themselves (as they would do when using any crypto library).

Library Company License
AeroGear Crypto AeroGear Apache 2.0
Conceal Facebook BSD
Keyczar – Apache 2.0

To sum up

If you are a mobile developer, you need to spend time making your applications usable, functional, and attractive BUT you also have to spend time making your application secure. If you do not know how to do so or if you’re worried that you might not get it right, then use one of the libraries described in this article in order to get started. No matter what cryptographic tools you decide to use, avoid implementing your own cryptographic algorithms and/or protocols; use only algorithms and protocols that are widely used, accepted, and ones that users have already spent enough time trying to break.

 

Which skills you can develop to be more effective in protecting your data?Take the Developer Economics Survey and we will let you know. Plus you may win new gear.

Categories
Platforms Tips

4 out of 10 sites unaware of the Google’s new Mobile Ranking Signal

mobile ranking signal

A variety of mobile devices have flooded the Web in the past years. To no one’s surprise, Google announced that starting April 21st, they’ll expand the use of mobile-friendliness as a mobile ranking signal, in fact penalizing all sites that don’t have a mobile strategy – dubbed “Mobilegeddon” in the recent press.

Furthermore, Google just paid $25 million for exclusive rights to the “.app” top-level domain. Although the company hasn’t yet announced any specific plans for .app, this could be the signal that the Mobile Web will evolve beyond Responsive Web Design (RWD) and lean more towards rich UX/UI and mimicking of the native environment.

Presumably, [tweetable]the update to their algorithm will have a significant impact on Google’s mobile search results[/tweetable]. If you’re like me, you’d want to go all the way and find out the specifics: what is the current distribution of mobile web strategies, how many websites will be impacted by this change and to what degree? If you already have a mobile web strategy in place or just started developing one, you’d probably also want to know how to optimize it: how “lengthy” should your pages be or how “heavy”? And what Google’s PageSpeed Insights has to says about it?

We have searched the answers to these questions by analyzing the top 10,000 Alexa sites, from 5 different categories: News, E-commerce, Tech, Business and Sports. What we discovered was no less surprising and we felt like this is something worth sharing with the community. Before diving into the data let me tell you a few words on the methodology.

As per Google’s guidelines, we have taken into consideration three types of configurations for building mobile sites:

google-table

Google recognizes three different configurations for building mobile sites. (Google Developers)

  • Responsive web design: serving the same HTML code on the same URL, regardless of the users’ device; render the display differently based on the screen size.
  • Dynamic serving (also known as adaptive): using the same URL regardless of device, but generating HTML code dynamically by detecting the browser’s User Agent
  • Separate URLs (also known as mobile friendly): serving different code to each device and a separate web address for the mobile version

To detect the strategy used by different websites, we have crawled them using an iPhone User Agent.

Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3

On top of that, we also identified those sites that implemented a Smart App Banner meta tag in the head of their home page, to market their iOS app:

<meta name="apple-itunes-app" content="app-id=myAppStoreID">

For analyzing the performance, we have used the PageSpeed Insights API, which takes into consideration not only the size of a webpage, but also compression, server response time, browser caching and landing page redirects, among others.

We also wanted to see how long mobile pages have become. Since RWD relies heavily on scrolling, we asked ourselves if this is an effective way to display content and what can be considered an optimum page height. Throughout the rest of the article, you’ll see references to “X5” height rate, which means that a site’s main page height is 5 times the height of the viewport on iPhone 6 (375 x 667). This is an indication of how much scroll needs to be done in order to reach the last piece of content.

visionmobile-infographics

Overview of Mobile Strategies on the Web

It’s 2015 and if you think that RWD is winning over mobile friendly sites (separate URLs), you’re spot on. Nearly 28% of the sites we’ve researched are responsive, while 26% have opted for a separate mobile address. The gap is indeed there, but it’s not as wide as we might have assumed. The surprising fact is that 40% of the researched sites have no mobile web strategy whatsoever! To me, that’s HUGE! Since Google’s new algorithm update is just around the corner, we can easily imagine that ignoring mobile users will no longer be an option.

Deeply buried in the data, we’ve also found another interesting fact: approximately 4% considered that being adaptive (serving different content under the same web address) is the right strategy for their mobile web presence.

2% of the researched websites have chosen to target their mobile users through applications (iOS). The number may in fact be bigger, but the inconsistency in promoting their apps makes them difficult to track.

Let’s dig a little bit more and see the variations between different categories and the impact that each strategy has on the overall mobile experience.

Newspapers – resistive as always

Being “stuck in the past” seems to be rightly attributed to the publishing industry, especially to newspapers: 38% of the websites from this category are mobile-friendly (separate URLs) and only 25% responsive.

In the PageSpeed Insights (PSI) results, adaptive comes on top with 75% scoring between 40 and 60 (although only 15% are above 60). Interestingly enough, mobile-friendly sites score even better (19% with PSI > 60), while only 11% of responsive sites have a score higher than 60. In fact, most of the sites that score under 20 are responsive (10%).

Wait, what? I thought Google loves responsiveness, right? There are countless articles about how Google recommends RWD as the best way to target mobile users. Surely, something doesn’t add up!

Or maybe most of the responsive sites don’t comply with Google’s own recommendations. A plausible explanation might be that developers have mistaken Google’s love for good mobile experience with the love for responsiveness, thus taking Google’s guidelines for granted. Instead of taking advantage of RWD, they end up producing sites that score poorly on all aspects.

When looking at sites’ height distribution on mobile devices, we see that the average for mobile-friendly ones is X8, which is pretty close to the X7 average rate represented by adaptive sites. However, 54% of adaptive sites have a less than X5 height rate.

In all fairness, “old” doesn’t necessarily mean wrong for newspapers sites and this time it might be working in their favor: 47% of responsive sites have a X10 – X15 height rate and 14% even over X15, which means that mobile users have to do a lot of scrolling before reading a certain piece of content.

So why are mobile friendly pages shorter? Did they notice that not so “lengthy” pages are more suitable for reading content on mobile? Is that the reason behind choosing mobile friendly (separate URLs) over responsiveness? But if that’s the case, why not going all the way towards adaptive? They’re doing a better job in terms of producing closer to optimum mobile pages (averaged at 2.5MB for both mobile-friendly and adaptive, compared to 3.7 MB for responsive) so perhaps it’s the ease of managing a separate mobile site all together.

Looking at Alexa’s popularity ranks, we notice that as the rank decreases, the number of responsive websites grows. The majority of sites with a low popularity rank are in fact responsive (14%), while 53% of the analyzed adaptive sites place themselves among the top ranked ones.

Tech sites – leaning towards RWD

In contrast with the above findings, responsive sites predominate in the “Tech” category (33%), while only 12% are mobile friendly (separate URLs).

In addition to that, 58% have page sizes under 2MB and consequently – a higher score on PageSpeed Insights: 51% mark over 60 and only 1.5% under 20. A page size of 2MB might sound a bit too much, but in fact, caching and other factors are influencing the overall PSI score.

When comparing the results to the newspapers category, tech websites show a major improvement. Yes, responsive sites still have the biggest height ratio (X6), but the average is significantly lower than what we’ve found earlier (X8).

Unfortunately, the “Tech” category also has the biggest percentage of sites that have NO mobile strategy whatsoever: 51%. It would seem that we have either modern responsive sites or nothing at all.

Overall, adaptive sites are still the most efficient in terms of score, but responsive sites are stealing the 1st place when it comes to height ratio, with a slightly bigger percentage of websites having a height rate of X5.

E-commerce sites fare better than most

For the “Shopping” category, mobile-friendly (separate URLs) and responsive sites are at a tie: 26%. Surprisingly though, adaptive e-commerce sites scored the biggest percentage of all categories: 6%. What would cause e-commerce sites to lean towards adaptive?

One plausible reason can be their appetite for improving conversion rates, thus their attention to optimize everything related to the buying funnel, which is influencing their mobile strategy as well.

If we analyze the height distribution for all three configurations (separate mobile URLs, responsive and adaptive), we see a pattern emerging: e-commerce sites, regardless of their mobile strategy, have the biggest percentages for under an X5 height rate: 90%, 58% and respectively 81%.

One could speculate that the reason for keeping their pages shorter is related to the influence that a lower height ratio might have on conversion rates. On top of that, PageSpeed Insights offers the highest score for all three mobile strategies: ~90% of mobile friendly/adaptive sites and 75% of the responsive ones have scored at least 40 points.

[tweetable]Clearly, e-commerce sites are doing a great job at optimizing for mobile[/tweetable] and, regardless of their favorite strategy (adaptive sites seem to be leading by a low margin), they’re mastering it like no other.

Apps – still luxurious game to play

Among other categories, we’ve found that mobile applications are appealing too: close to 6% of sites from “Business” and “Sports” have created their own iOS application, even if most of these previously opted for mobile friendly sites: 9% respectively 15%.

As a general rule, regardless of the category, if a site doesn’t have a mobile web strategy, chances are it won’t go for an application either. You’d expect it to be the other way around, but if a site owner ignored all previous mobile web strategies at his disposal, would he really be open to a more laborious and expensive approach (apps)? Not really.

Optimum Height and Page Size on Mobile

Analyzing ~10,000 sites in various categories surfaced a couple of guidelines that you might want to take into consideration when implement your mobile web strategy. In essence, what’s the maximum height and page size that your mobile friendly, responsive or adaptive site should have to ensure a 50+ PageSpeed Score?

If we analyze page sizes less than 2M, we realize that mobile-friendly sites, particularly in the Sports category, come on top with little over 91%. We also notice that only 30% of responsive sites score over 50 on PageSpeed Insights. Again, just keeping the page size at this level isn’t enough to ensure a high PSI score since caching can be equally important, but it’s a good place to start.

Interestingly enough, the “News” category is the only one where the majority (52%) of the adaptive sites with scores over 50 has page sizes between 2MB – 4MB. Even if adaptive sites seem to be able to “carry” more weight, their height rate should be kept at the minimum (X5) to ensure a good score.

Applying the same logic to height rates, clearly X5 seem to be the optimum rate for scoring 50+ on PageSpeed Insights. Once more, responsive sites seem to have the least chances of scoring over 50, even if they aim for a lower height: 62%.

Is the Mobile Web Heading Towards “Appification”?

[tweetable]Today, mobile web consumption occurs mostly from in-app browsers[/tweetable]. Just look for example at the Facebook app, that used to open links by using an external browser. Now, they have embedded a browser directly in the app and it makes sense – they don’t want their users to have a broken experience.

With that in mind, shouldn’t mobile websites offer a more app-like experience? Isn’t the linear scrolling experience we see on responsive sites a bit outdated?

In all fairness, what we’ve concluded thus far doesn’t take into account various UI/UX aspects and doesn’t answer some critical questions: When scrolling becomes too much for a mobile site? What’s the impact of having a long scroll and is this the reason for poor mobile reading experience on the web? What else can we do to ensure that mobile users have a good experience on the web?

That’s why in the second phase of the study we’ll analyze how much scrolling is actually being done on a responsive page, on mobile devices. After gathering relevant information on how mobile users interact with responsive sites we’ll be able to complete the next phase of the study by answering some key questions:

  • What’s the mobile device and browser they’re using for accessing a site?
  • How much time they spend on a particular page?
  • What’s the maximum scroll height they reached on a site?

From “Nice To Have” To Mandatory

We’ve seen that 40% of the top 10,000 Alexa sites from 5 categories (News, Tech, E-commerce, Business, Sports) don’t do anything when it comes to their mobile users. However, we’re in the middle of a big shift: [tweetable]having a mobile strategy on the web is no longer just “nice to have”[/tweetable]. If we take into consideration the impending change of Google’s mobile ranking algorithm, we can conclude that at this point any mobile web strategy is a good strategy.

As far as this first part of our study is concerned, from a technical point of view, a page that fits within 2MB and has a height rate of X5 has a good chance to score 50+ on Google’s PageSpeed Insights. Although adaptive websites are overall the most efficient ones regarding these aspects, they are not very popular either. Even though the study clearly shows that RWD is far from being optimum, responsiveness is the leading strategy adopted when targeting mobile users.

If we add to the mix the “.app” top-level web domain bought by Google, the line between native apps and web apps is getting thinner and thinner. The Mobile Web is already evolving beyond responsiveness into something new and exciting where everything is an app instead of a site, where user interactions are more important than just page views and ultimately where all apps are interlinked into a Web of apps.

If you are interested in learning more about mobile app development read the third post of our series on Mobile App Marketing, on Business Models.

Categories
Languages Platforms Tools

Why JavaScript will win on mobile

javascript will win on mobile

JavaScript is not the world’s most elegant programming language. So much so that one of the world’s top experts on the language wrote a book about “The Good Parts”. The book carries the headline “Unearthing the Excellence in JavaScript” because that excellence is quite deeply buried. Even so, it has rapidly become one of the most popular languages in the world. That popularity is deserved, because despite the flaws in the language, JavaScript gives developers significant advantages that they can’t get with other languages. Some of those advantages were created when browser vendors agreed to standardise on JavaScript (OK, technically ECMAScript) as the language for the web. Others are inherent to the web app programming model and more yet have been created through tooling enhancements. However, despite the fact that native apps are dominating web apps on mobile devices, JavaScript’s advantages are steadily transferring to mobile. Will it eventually dominate there too?

why-javascript-will-win-on-mobile

Popularity not priority

The latest TIOBE Community Index has JavaScript in 6th place amongst all programming languages and rising. The TIOBE method of ranking tends to favour older, more established languages and is not so quick to pick up trends. By contrast, the Redmonk rankings have JavaScript in first place. The Redmonk method is somewhat biased towards languages with strong open source communities but more accurately reflects current interest and trends. Our own Developer Economics surveys have shown that [tweetable]HTML5/JavaScript combination is the second most popular language amongst mobile developers[/tweetable] with 55% using it, just narrowly behind Java (at 57%). However, even if we combine those who prioritise HTML5 and JavaScript (19%), they’re still a long way behind Java (29%) on this metric. It seems likely this is going to shift significantly over the next few years. [What do you think? We have a new survey out, so take the survey and let us know your thoughts]

JavaScript breaking free from the browser

This is not a standard “the web will win” argument. I don’t believe that browser or webview-based apps will eventually dominate on mobile devices. Use will grow but they won’t be the norm. If true open web standards are to dominate in the future then they need to move on from the Document Object Model (DOM). The DOM is a base for building documents, not apps. Of course you can build an app around a platform originally designed for documents but you’re starting from a position of handicap. Look at the modern frameworks that allow you to build fairly performant apps for mobile browsers/webviews: React.js, Famo.us and Ionic. All three share the common feature of touching the DOM as little as possible.

Yes, there’s WebGL (or HTML5 Canvas if you must) too but those are low level graphics APIs. You need large, probably multi-megabyte, frameworks on top to create a good platform for building most apps. That’s not a good fit for the web app programming model, where the latest application code lives on a remote server, particularly not in a mobile environment. It’s true that you could have a hybrid app with a large framework on top of WebGL stored locally and just fetch the application specific code from the server but then why use the browser at all? Why not just JavaScript on top of some other cross-platform framework built for hardware graphics acceleration (hint: Qt has a nice offering here). One with a higher level API so there’s not so much overhead bridging between languages. Perhaps also one that’s less restricted when it comes to accessing device specific functionality.

There are now a couple of really interesting new options that fit this description, React Native and NativeScript. These work in different ways but both build apps with a native UI using JavaScript. Appcelerator’s Ti.Next may also be interesting, although they’ve been talking about it for a couple of years without an actual release yet, so we’ll wait and see.

The JavaScript exception

Here is where Apple has restored JavaScript’s advantage on mobile. A key thing that has prevented most developers from adopting an agile, web-style continuous delivery model on mobile is Apple’s ban on code downloading. Without that iteration is significantly slowed and split testing is much harder to do. This effectively means developers, particularly startups, learn slower. Until very recently, the only ways to get more rapid iteration were to go Android first, or build a hybrid app, since Apple made JavaScript downloaded in a webview an exception to the code downloading rule. In the first case it means moving away from the platform with the most early adopters. Unfortunately in the second case the UX trade-offs are too great, with most developers that went that route for a consumer app failing or switching to native. But in iOS 7 Apple added the JavaScriptCore interface to their own JavaScript runtime and in the latest iOS Developer Program License Agreement they modified the exception to code downloading rules to include JavaScriptCore.

This makes sense from a security perspective. Apple can audit and update their own runtimes, whereas if they allow 3rd party runtimes to download code they have no effective way of monitoring or dealing with security issues. Since JavaScript is Apple’s only scripting option and they can’t allow native code downloading, JavaScript is restored to a privileged position – the only option for those that want to iterate fast. The availability of JavaScriptCore triggered efforts like React Native and NativeScript and the timing of Apple’s relaxation of the code downloading policy has been perfectly timed for their public release.

Will open win?

Web advocates sometimes suggest that the open-standards-based web must eventually win because open always wins in the end. However, Linux is a very clear case where an open ecosystem thrives without a committee agreeing standards. With React Native, Facebook appears to be very rapidly building a developer ecosystem around their open source project. Already having a rapidly growing community around React.js obviously gives them a headstart but the NativeScript team at Telerik are working with Google such that Angular 2.0 should integrate seamlessly. Google are going to support non-DOM environments whether the web standards go in that direction or not. Microsoft and Google might take a long time to agree on the standards they’ll implement in their future browser versions but they’re working together on TypeScript, to make it easier to build complex apps with JavaScript (it turns out compilers are much better than people at spotting type mismatches).

Apple has built some fairly impressive tooling for their new Swift language, particularly the interactive playgrounds. However, Facebook possibly already has a better developer experience with React Native in terms of immediate feedback and rapid cycle times whilst coding. Apple will continue to iterate on that tooling alone, whilst the developer community can now enhance the tooling for these new JavaScript environments. Android may technically be open source but it’s not open in terms of community contribution. Google are enhancing the Android platform and tooling alone. [tweetable]Perhaps it’s really open developer communities that win[/tweetable] and genuine open source based communities can iterate faster than open standards based ones. For these “native UX built with JavaScript” environments to succeed, the platforms don’t have to lose. Apps will still be tailored to the platform look and feel and adopt new platform-specific APIs.

Javascript will win on mobile.

At the moment it looks like the very open JavaScript developer community will win because they get to build apps with native look, feel and performance but a web-style development experience. The closed platforms also win because apps are still being tailored for their captive ecosystems. For now, open web standards lose. It seems likely they can only win if the mobile browser vendors can agree to new standards that enable the creation of apps that genuinely offer an equivalent experience to native ones.

Update: Where we right in our predictions? Here is a latest update on the popularity of Javascript.

What do you use?

Do you think JavaScript will dominate on mobile in the future? Or Java, Objective-C and Swift will continue to lead? What about for the Internet of Things, or on the backend via Node.js? Let us know what you’re building your apps with by taking our survey.

Categories
Platforms

How Soon Is Now For The Mobile Web?

This may be the year when the mobile web apps finally go mainstream. Or, at least, their hybrid cousins will.

how-soon-is-now-for-the-mobile-world

Not because the technology will finally be ready. For most apps, it already is. Rather, the web will finally hit the big time with mobile apps precisely because we’ll talk about it less and use it more.

Time for HTML5
Oh, sure, there are good reasons for the mobile web to finally hit its stride. Sencha’s Nick Harlow offers five:

  1. High quality WebViews are now available on most platforms (and getting dramatically better thanks to Apple’s new WKWebView in iOS 8). While low-quality WebViews persist within the Android device base, on balance things are looking up;
  2. Broad platform support is only economically feasible using web tech;
  3. Web tech bridges the desktop-mobile divide;
  4. Using web tech helps to simplify application management and security; and
  5. Device fragmentation is accelerating. The web helps developers keep up

But before we herald the future of hybrid, it’s worth pointing out that some believe that future is already here. As EmberJS co-creator Tom Dale tells me, “”The dirty little secret of native [app] development is that huge swaths of the UIs we interact with every day are powered by web technologies under the hood.”

While Dale may be getting ahead of himself – [tweetable]the reality is that the web still has a long way to go to achieve mass-market app adoption[/tweetable], and maybe constitutes 10% of apps within the app stores – the trends do point toward more hybrid apps, especially among the enterprise set. VisionMobile’s own survey data shows that today 30% of developers are using some kind of cross-platform tool, of which 60% are using PhoneGap.

This is great, but it doesn’t obviate the need for the mobile web to get better to erase complaints about performance. And it will.

Getting better all the time
Summarizing the Google Chrome Developer Summit, Divshot CEO Michael Bleigh says, “Google is doing everything it can to get mobile web to 60fps, which gives you about 16ms per frame to do everything you need to do. It’s hard to even enumerate all the different ways they’re working on this.” Speed will bolster web app performance, perhaps eliminating the “jank” that many associate with web apps.

But it’s not just about accelerating the mobile web.

We also need to rethink how we approach mobile web apps, as Ionic (based on Google’s AngularJS) and React Native (from Facebook) do. While the latter is not “web technology,” strictly speaking, these frameworks are actively advancing the state of the art for web apps.

The result, as Mozilla (and longtime native app) developer James Long puts it, is impressive:

It only takes a few minutes playing with React Native to realize the potential it has. This works. It feels like I’m developing for the web. But I’m writing a real native app, and you seriously can’t tell the difference. At the UI level, there is no difference; these are all native UIViews beautifully sliding around like normal.

Indistinguishable from native performance… but with a far more accessible development platform. That’s powerful.

A question of competence
But let’s be clear: [tweetable]if your development team isn’t any good, it really doesn’t matter which development platform they choose[/tweetable]. A bad iOS programmer is going to lose every time to a good HTML5/web programmer, and vice versa.

Indeed, one of the primary problems with the web is that it so dramatically lowers the bar to development that virtually anyone with Javascript and CSS skills can build a mobile app.

A lame one, that is.

Mobile developer Nic Raboy nails this:

All my applications, native and hybrid, have mostly positive reviews and if you visit the apps on Google Play, you’ll see no reviews include mention about how the application was crafted. This is an important thing to notice because many haters will attack developers on the idea that hybrid applications do not perform or look as good as native applications. This is simply not true. Native or hybrid, if the developer or designer is no good, the application will suffer regardless.

So as fantastic as advancements like AngularJS and ReactJS will be for web app development, they’re not going to be enough if developers underinvest in learning them. There are already exceptional hybrid apps like Instagram that demonstrate what strong developers can do with the web. We just need more of them.

Or maybe what we need is better tools.

That’s one primary takeaway from VisionMobile’s “How Can HTML5 Compete With Native?” report. As report author Dimitris Michalakos concludes, “The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps.” Given that “HTML5 is like driving a car without a dashboard,” the key is to deliver better dashboards, or tools, to make it easier to build great web apps.

This involves significant improvements to the debugging, profiling, and memory management tools available, but it’s also something the web frameworks can help with.

As such, it increasingly looks like a question of WHEN, not IF, mobile web apps will take off.

And the answer to that question is either “now”, if you’re paying attention to how developers actually build apps today, or soon, if you’re waiting for them to start talking about the fact that they’re building with the web.

Categories
Community Tools

Developer Interview: Building Apps for Wearables Isn’t about Tools

apps for wearables
Digital magazines

Softeq Development is involved in everything mobile: from business apps, digital imaging and utilities to mobile games, wearable technology, sensor-rich equipment and its remote management. They have built dozens of embedded solutions, web, and mobile applications for such clients as Nike, NVIDIA, Omron, AMD, Atlas Copco, EPSON, Disney Parks and Resorts. T. Our associate author, Alkis Polyrakis, discussed with Softeq’s CEO, Chris Howard.

What is the philosophy that you employ in order to assist companies take advantage of the full potential of the latest technology?

To me, our philosophy is to be ahead of the curve. It means we try to know and adopt new APIs, tools, and technologies before customers actually need it. We obtained and evaluated Google Glass, EPSON Moverio, Oculus Rift, LEAP motion controller and many more new tech novelties long before the first project came along. Once a customer approaches us with a project for those new technologies, Softeq is already the most competent tech provider the customer can possibly find on the market. Having close ties with many companies in Silicon Valley, we were one of the first tech firms in the world to access and implement, for example, Microsoft’s high speed video APIs on Windows Phone before they were available to the public.

Digital magazines
Digital magazines

What are the benefits of implementing a Proof of Concept in business projects?

A proof-of-concept (PoC) is a great first step on the way to a new product, device or technology that was never seen before because it’s a low-risk and low-investment approach. Often, it requires a 10-20 times smaller budget than actual new product development.

In our business, we have come across two different goals, or approaches if you like, to building PoC apps. One is when a customer is looking to prove the feasibility of his new business idea. At times, our clients need to demonstrate a working prototype of an upcoming product at a trade show, board meeting, or at an investor meeting. Prototypes later can become Minimum Viable Products (MVPs) and both can be stages of a full product development cycle if the idea gets approval.

Xamarin framework Business apps development
Atlassian Jira Project management
LabView – LabWindows – MathLAB Wearable devices
Flurry – Google Analytics – Localytics – Adjust – Parse Monetization
Unity Games development

Softeq’s Toolset

The second typical need is when a technically advanced company researches next-gen ideas, software or hardware they’re looking to jump into. Here, building a proof-of-concept in the first place is a way to test the feasibility of their vision for the application of new technology, a hardware component, or form factor. Just like that, our R&D teams have been working for Nike, Intel, and EPSON to help then visualize their new ideas and prove it is actually possible to do what they envision.

Do you have a specific development procedure when working on a PoC?

As a PoC is always something pretty innovative and non-standard, generally the development procedure is to identify the key features of what a client is trying to do in a bigger project, focus on only testing and proving out the specific new APIs or new hardware, and building a very simple framework in order to demonstrate that specific capability. After the PoC is approved by the management team, the investor, or the end-client, we proceed to flesh out the rest of the features and ship an actual product.

Which development and project management tools do you employ in order to facilitate your needs in cross platform development?

There are several cross-platform frameworks trending on the market now, and this is fair enough. The mobile market is no longer dominated by one platform, and most of our customers, both in the B2B and B2C segments, need to target wider audiences with various OS preferences. We use the C# based Xamarin framework for business apps, and Unity for games. Speaking of project management tools, we use Atlassian Jira by default or any other tool the client is more comfortable with.

Our readers would like to hear some examples that show how you managed to pump up a company’s marketing efforts with your apps.

Marketing apps for Blizzard and Branson Ultrasonics
Marketing apps for Blizzard and Branson Ultrasonics

Marketing apps vary, and we’ve delivered several dozen of them: from Blizzard’s BlizzCon event management app for helping improve the guest experience, to mobile CRM, promotional games, mobile magazines for corporate clients, and demo apps for tech events and industry-specific trade shows and all the way up to international tech summits and even Mobile World Congress where companies present their new or would-be products. We’ve built several kiosk apps for in-store demonstration of new gadgets to buyers. One of them was for NVIDIA’s SHIELD – the world’s first Android TV console. The kiosk mode allows demonstrating all functional features, including games, videos and music playback, while blocking access to system settings.

What are the main challenges that you face when you attempt to build solutions for wearable devices?

We’ve been working on embedded devices for a very long time, over 15 years now, that’s why the era of wearables came very natural to us. The challenges anyone designing a wearable device inevitably faces are technical limitations of the form factor, such as short battery life, small amount of memory, insufficient performance, custom communication protocols (infrared, Bluetooth low energy) and more.

However, Softeq is uniquely positioned in this market and beyond, in the Internet-of-Things (IoT) space, because we do everything from hardware, low-level and firmware to web backends and mobile apps covering all our departments end-to-end. To extend that further we have a game department, and that even gets mixed in with wearables and the IoT.

Hardware Design and Embedded Development Lab deployed in Softeq's HQs in Houston, Texas
Hardware Design and Embedded Development Lab deployed in Softeq’s HQs in Houston, Texas

Can you tell us about some of your wearable device projects and the tools that you employ?

One of our current projects involves embedded touch panels, and we do both firmware for the panels and Qt-powered games for them. Another product we helped create – the BlinkFX Wink, which is a wireless control LED light wearable device – is being used for an upcoming game show at CBS.

There’s a wide range of tools and instruments, mainly in C, that we use for such projects. For instance, recently we started receiving multiple requests for projects involving drones. We suggest using such behavior modelling tools as LabView, LabWindows and MathLAB, but it’s not the tools that matter most. The most complex part is building math models and algorithms based on them.

Do you provide consulting services as to which model can maximize a game’s revenue?

The monetization system of a game is usually built by a tandem of experts – a game designer and a marketer. The game designer is responsible for building game mechanics in terms of monetization and balancing economics while the marketer drives user acquisition campaigns.
To ensure we deliver the maximum amount of effort on our end to ensure the game’s success, our game designers invest a lot of time in research, comparative analysis of top apps, exploring best practices and efficient mechanics to put them in our arsenal. From the game design perspective, we certainly consult developers at the early stages of building the monetization system: building the core loop, the in-game store, retention mechanics, economics balance, analytics, A/B testing system implementation, etc. For instance, we work with such analytical tools as Flurry, Google Analytics, Localytics, Adjust, Parse and the selection of tools depends largely on the game specifics and client’s preferences.

Thank you very much for taking the time to share your strategy with our readers.

Categories
Business Platforms

Microsoft’s Mobile Opportunity

Microsoft’s Mobile Opportunity

Microsoft was slow to react to the step change in user experience provided by iOS and Android versus the first generation smartphone platforms. Windows Phone was then late to market and has finished a distant third in the smartphone platform wars. Smartphone adoption was consumer led and in the race to catch up Windows Phone skipped some enterprise friendly features. This has left it out of the running for business adoption too. In tablets, Windows RT was largely rejected by the market and Intel processor based devices running Windows 8 have only managed a weak third place in the market so far. In terms of their share of the mobile OS market, Microsoft is a long way behind Apple and Google. However, as enterprises are increasingly making big investments in mobile, Microsoft’s mobile opportunity is still not lost.

infragistics-2-cover

If you can’t beat them, join them

Microsoft’s new CEO, Satya Nadella, has made it clear. The company’s focus is now mobile-first and cloud-first. This includes aggressively rolling out their services across iOS and Android.

In fact they already have more than 100 apps across the two platforms and that number is growing fast. Nadella has not been hesitant to acquire technology where previous strategy has left gaps. The new Outlook apps for iOS and Android is based on the Acompli apps that Microsoft acquired late last year. It will likely be enhanced in the near future with the technology from recently acquired calendar app Sunrise.

In addition to filling out their offering and buying in talent for their competitors platforms, they have also moved to protect their dominance in productivity software. Microsoft Office is free for consumers on mobile platforms. To sweeten the deal for those who pay they’ve added unlimited storage via OneDrive. They then removed reasons to switch by opening up to competing storage solutions such as Dropbox and Box.

Following the old adage that the best form of defense is a good offense, these moves help keep Microsoft’s central position in the daily life of business users whilst starving startups hoping to topple them of revenue. No-one without Microsoft’s scale can compete directly on price whilst offering similar value.

Developers, developers, developers!

The other key to protecting Microsoft’s core enterprise revenues is keeping their technology stack at the heart of enterprise app development. For this to happen, third party enterprise app developers need to stick with .NET and related tools to build apps for iOS and Android. Developer loyalty is where Microsoft has been very strong.

Slashdata’s Developer Economics surveys repeatedly show Windows Phone with massively higher developer mindshare than the installed base of devices merits. That mindshare also continues to grow despite ongoing lack of traction with device sales.

One of the reasons for this developer loyalty is that Microsoft makes top class developer tools. They’ve invested heavily in this area for a very long time. Most developers don’t want to downgrade their tools and productivity in order to target another platform.

While Microsoft didn’t do the groundwork necessary to let developers target iOS and Android with their tools, Xamarin did. Microsoft and Xamarin have a global partnership to enable C# developers (and to some extent Visual Basic developers) to target iOS and Android via Visual Studio. Microsoft open sourced their state-of-the-art Roslyn compiler technology for .NET, presumably mainly so that Xamarin could integrate it. It seems likely that the partnership between the two companies will deepen at some point, probably through investment or acquisition. In any case, it seems to be working.

In the Q1 2015 Developer Economics survey, Xamarin was the second most popular cross-platform tool, behind only PhoneGap/Cordova.

The survey data also shows that C# is clearly on the rise as a language for mobile development.

Microsoft’s Mobile Opportunity: The next best thing

If you can’t own the OS and platform APIs then the next best thing is to own the developer tooling and thus the key relationship with developers. If you want to introduce or drive new features or standards (that don’t require new hardware or OS level support) then it’s the developer relationship you need to own rather than the platform itself.

Arguably a lot of innovation in mobile going forward will be achieved through cloud services. Microsoft would love to own those APIs. This only goes so far in the consumer space. Apple and Google can veto Microsoft’s moves at the public app store interface. However, in the enterprise, where most apps are not distributed via the public app stores, anything goes. This is where Microsoft’s biggest mobile opportunity lies. It’s also where the bulk of the revenue in app development will end up.

If Microsoft can keep a huge pool of developers fed and happy on mobile then they’ll be in a much better position for whatever comes next in computing.

Categories
Languages Tools

The Rise of Mobile C#

mobile c#

Microsoft have been struggling to get traction with their mobile computing efforts, with Windows Phone stuck at around 3% share of the smartphone market. Windows 8 is doing a little better in the tablet market but is still a distant third to iOS and Android. Despite losing in the platform wars, Microsoft’s developer ecosystem is still strong and they’re not showing much sign of wanting to give up their tools. The latest Developer Economics survey showed that 38% of mobile developers were using C# for some of their work and 16% use it as their main language. Those developers are not all focused on Microsoft platforms by a long way. They’re not all building games with Unity either. So what are they doing?

thumb

Not just Windows Phone, particularly not for pros

Whilst 30% of all developers in the survey were targeting Windows Phone, that doesn’t quite account for the majority of those whose main language is C#. Also, more than half of the developers targeting Windows Phone are Hobbyists and Explorers[bctt tweet=”more than half of the developers targeting Windows Phone are Hobbyists and Explorers” username=”DevEconomics”] – i.e. those not working on mobile apps full time. If we focus on full time professional mobile developers, as we will for the rest of this article, then just 50% of those that use C# as their main language are primarily targeting Microsoft platforms. Apple’s iOS (with 23% of developers) and Google’s Android (14%) are in fact more popular targets than Windows 8 (10%). So, how do developers use C# on other platforms? With cross-platform tools, particularly Unity and Xamarin.

More enterprise apps than games

Unity is by far the most popular engine for mobile games, in fact in the Q3 2014 Developer Economics survey a massive 47% of game developers were using it for some of their projects. C# is the most important language in the Unity developer ecosystem, although there are two other languages supported (UnityScript – a JavaScript variant with type annotations – and Boo – a statically typed language with Python-like syntax). However, a lot of developers are using Unity to build games in their spare time. When we look at the full time pros we find that games are only the 4th most popular category of app. The top 3 categories are Business & Productivity tools, Enterprise-specific apps and Utilities, all staples of the enterprise-focused app developer. Developers are either building these apps for Microsoft platforms, using Xamarin to reach iOS and Android with them, or both. Indeed it’s the combination of a familiar language (and code portability) and tooling for many enterprise app developers with the cross-platform reach they can get with Xamarin that’s making C# such a popular choice in this area.

A flexible cross-platform approach

A lot of popular cross-platform tools for mobile development only support iOS and Android. As such, for those also wanting support for Windows Phone and possibly desktop Windows and Mac too, Xamarin is one of very few serious options. That said, it’s not just a default choice. Using Xamarin.Forms, developers can get the write-once-run-anywhere efficiency that drives many decisions to use a cross-platform approach. The downside to this approach is that it can give a lowest common denominator of functionality; not allowing developers to really optimise for the unique features of each platform. However, Xamarin also directly wraps the native platform APIs, allowing developers to call anything in the native SDKs. They can even automatically create bindings for popular third party libraries on each platform. The other key reason developers often go with a native rather than cross-platform approach is performance. However, a recent independent performance test (by an early Google engineer) showed Xamarin’s compiler produces raw performance that’s comparable to native on iOS and Android. Raw performance isn’t the only thing that counts of course – a garbage collection pause causing a stutter in your animation is jarring, however fast the the code is executing otherwise. Enterprises customers will usually put up with mild inconveniences of that nature to get the cost savings and maintenance benefits of a single code base across platforms though.

Better revenues

Possibly the best measure of the success of C# on mobile devices is the revenues of the developers using it. Whether you believe the same level of smoothness in the user experience can be achieved or not, it only matters if it costs users and revenue. Here there is no room for debate. The revenues of full time professional developers whose main language is C# are comparable to, or better than, those of other developers targeting the same primary platform with the native language. For example, the revenue distribution for C# developers on iOS is extremely similar to that for Objective-C developers and the average revenues are higher. This is both because there are more C# developers earning more than $10K (46% vs 36%) per month and while there are slightly fewer earning more than $100K per month (16% vs 17%), a significantly greater fraction of those using C# earn more than $500K per month (14% vs 6%).

This is not to suggest that C# is somehow a better language for targeting iOS than Objective-C. This is correlation and not causation. The cause of the better revenues is that the C# developers are much more likely to be targeting enterprises than the Objective-C developers and that’s where the higher revenues are most likely to be found. There’s an enormous pool of developers trained in C# and related Microsoft technologies. A lot of them are working on desktop enterprise apps or the server side. As it becomes increasingly clear that C# is a viable language for successfully delivering cross-platform mobile solutions, C#’s rise on mobile looks set to continue for several years yet.

The Rise of the Mobile C#

Infragistics

Categories
Tools

Developer Interview: Which tools is WillowTree using?

The official University of Virginia app for Android

WillowTree (www.willowtreeapps.com) is a leading app development company that has produced over 300 titles since 2007, such as My Pregnancy Today that has seen more than 12 million downloads. Our collaborator, Alkis Polyrakis, discussed with their Systems Architect, Alex Shafran, who led the development of projects for GunBroker, Quintiles, the Red Cross and the NBA, about their strategies and tools of preference.

Please begin by giving us some information on a few of WillowTree’s most successful apps.

WillowTree has helped clients succeed in a variety of markets. Johnson & Johnson’s Baby Center apps have been a worldwide success, grossing over 10 million downloads and consistently ranking high in the App Stores. We recently released the new version of the official NCAA app, which is the main source of college sports scores and news. In the enterprise, we built an app for the AOL marketing team that auto-generates sales slideshows based on a quick questionnaire. This app saves each salesperson hours each day and allows them to prepare less and sell more.

BabyCenter Birth Class offers advanced video integration
BabyCenter Birth Class offers advanced video integration

WillowTree claims to tackle complex enterprise-grade mobile deployments by beginning with a simple question: “Where should what logic live?”. Can you explain what this quote means to our readers?

Even the simplest “mobile apps” require infrastructures to support them. Ordinarily, this “backend infrastructure” is software running on a collection of servers in a data center. By asking where should live, we are referring to the separation of concerns between the app on the phone and the backend servers. Consider Pandora, the popular music streaming app. When the Pandora app is downloaded from the App Store, the phone now has the code to run the app. However, the phone must get the music from somewhere — the entire music catalog is not stored on each user’s phone (that would be redundant…and impossible). This is where backend servers come into play. At a basic level, Pandora has a collection of severs that store the millions of songs in their catalog. When the apps need to play a song, they use the internet to download the song in real time from one of these servers.

Pandora is the most obvious example of “where logic should live” — clearly the entire music catalog should not be on each phone. But we encounter different flavors of this problem everyday, from “Should the phones store the user’s password” (the answer is no, NEVER), to something as basic as “Should we use the phone’s clock or the server’s clock in our realtime bidding app?”. While the answers might come easy to us, talking through these details can help our clients understand the benefit of adding an additional component to the system.

The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world
The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world

The sheer number of mobile apps that you have developed for major clients is impressive. In addition to quality project management, this is a clear indication that you are using the right development tools. What are those, and how do they make your job easier?

Development tools are only part of the story. They are critical to keeping projects on track, but they must be used as a supplement, not a replacement, to in-person communication. Our entire development team is colocated in Charlottesville, Virginia, which gives us massive efficiencies. When possible, we like to share those efficiencies with our clients. We regularly send entire project teams to client sites, and their development teams visit us just as frequently. There is no replacement for in-person collaboration.

Of course, we also make regular use of phone checkins and online tools. We use Teamwork for project management and communication. It is so simple and powerful that many of our enterprise clients have also adopted it internally. Project/sprint planning is done in Jira, which helps us gauge project burndown and overall progress.

Our continuous integration system (CI) is the most automated tool in our process. When a developer commits code, the CI downloads the newest code, builds it, runs the auto-mated tests, and releases it to our QA team (and the client, if appropriate). This entire process can take under a minute, but the same tasks could take a developer half an hour.

Is prototyping part of your development process? If so, which tools do you prefer for your apps?

Absolutely. We try to get usable software into our client’s hands as quickly and as often as possible. Prototyping is often the fastest way to do this, via static prototypes or even stubbed code. Before development even begins, our UX team uses InVision to turn visual mockups into clickable prototypes. These prototypes run on the phone just like real apps, which allows us to get critical feedback very early in the process. We highly recommend using InVision when possible.

The official University of Virginia app for Android
The official University of Virginia app for Android

Clients often want their apps to support in-app purchases and ads. Do you prefer to build a business model around the project before the development even begins? What is your monetization platform of choice?

There are a several monetization models available on mobile, from: free, ad-supported, in-app purchases, and paid download. The first goal of any application is to get the user to download the app, and we have found that a price-tag of even $0.99 can be a deter-rent for apps in saturated markets or lower-income demographics. In these situations, our clients should consider alternate monetization policies. If the basic functionality can be provided at a low cost, then it might be a good idea to consider a “freemium” model, where the app is free to download but premium features must be purchased (e.g. Evernote). Ad-based models (Facebook, Flixter) can also work, and companies are getting very creative with “native” ads that look like real content. The freemium-ad hybrid model is also popular, which is where a user can pay to remove the ads. However, the paid-download model, like the Dark Sky realtime weather app, can succeed if the app provides functionality that is otherwise unavailable.

Compare the development tools that were at hand when WillowTree started out 8 years ago to the current ones.

When WillowTree first started out 8 years ago, mobile was a very small (but rapidly-growing) industry. The tools we used were either provided by Apple/Google (the xCode IDE) or ported from other tools (Eclipse for Android). There was no third-party ecosystem of tools to modify for our needs.

Now, we use Android Studio, which is an extension of IntelliJ specifically for Android development. xCode for iOS is more robust (and hardly crashes), and both tools are a core part of our Continuous Integration (CI) workflow, which took years to fine-tune. It allows us to automatically (and safely) ship tested code to clients and to the App Stores. Our build distribution tools, TestFlight and HockeyApp, now allow us to see which versions of the app the client has installed/tested. These automated workflows take the burden off developers and allow them to focus on writing quality code.

Categories
Tools

API Management tools: How to find the one for you

Launching an API is hard. You need to make sure your service is reliable, secure and well-documented. This is where API Management tools come into play. They provide the means to expose your API to external developers in an easy and affordable manner. One of the best definitions of API management is the one introduced by APIacademy:

But first, let us know which are YOUR favourite API management tools. Take the Developer Economics Survey and you may win amazing prizes and gear.

api-management

“Creating a centralized API architecture that makes the process of composing, securing and managing high-performance interfaces significantly simpler and more consistent.”

Features of an API Management service

API management services have a multitude of features. Their main focus is to make designing, deploying and managing an API easier, as well as to ensure that it is safe, secure and functional. Some of these tools facilitate integrations, transformations or API orchestrations. Ideally, an API management service should at least cover most of the below basics:

  1. Documentation – Sounds boring, right? Still, one of the most common problems of developers is figuring out how an API works. Development time is too precious to waste in trial and error of an undocumented API. An API management service has to provide an easy way to read the documentation and enable developers to “try before they buy”. In some cases it is even possible to provide interactive documentation. Simplicity and usability are the keys!
  2. Analytics and Statistics – It is critical to understand how people use your API and get insights for your business.
  3. Deployment – Should be flexible and support public or private clouds, on-premises implementations, or combinations.
  4. Developer engagement – Engaging with your API consumers, developer or partners is important. Getting an easily accessible developer portal will significantly facilitate onboarding.
  5. Sandbox environment – This feature will increase both the value of an API and its adoption rate. What better than being able to develop and test your code.
  6. Traffic management and caching abilities.
  7. Security – APIs carry sensitive data, so it is important to protect the exposed information. The service has to at least provide identity and access management for users and developers.
  8. Monetization – Provide the capability to monetize your API.
  9. Availability – Should be available, scalable and redundant. An API environment can become demanding and the service should be able to deal with any kind of errors, problems or temporary traffic spikes.
  10. Support of Legacy systems.

To Proxy or not to Proxy?

The vendors in the API management space provide a number of solutions across the above main categories but that does not mean they support everything. They are implementing their solution in three different ways: Proxies, Agents or Hybrid.

  1. API service providers that use the concept of a Proxy. Their solution “sits” between the customer and their users and the traffic goes through them. Proxies provide caching capabilities and protection of customer’s back-end infrastructure from traffic spikes. The main criticism they receive is that they increase the cost and bring up privacy and latency issues. Apigee, Mashape and Mashery are examples of such implementations.
  2. API service providers that use the concept of agents. Agents are plugins that integrate with your server. They do not get in the way of the API calls like proxies. As a result they do not introduce network latencies or 3rd-party dependencies. On the other side, features like caching are not easy to implement. 3scale is an example of such implementation.
  3. API service providers that use a hybrid approach. This means you may get an agent and a proxy. For example you may want to use a proxy for the caching and the agent for authentication. Companies like Apigee or 3scale we talked before are also moving to hybrid solutions.

13 API management tools

Deciding on an API Management Tool, you are faced with lots of choices. Available solutions may focus in one or two or cover many of the features discussed above and vary greatly in price. There are tools that were acquired by bigger vendors like Intel or CA or Microsoft. Open source tools are also available. Last but not least, some tools are heavy enterprise focused and other much less so.

Name Type License Stackoverflow questions Market segment Strong Points
3scale Agent, Proxy Commercial 15 Startups to Enterprises Wide range of tools
ApiAxle Proxy GPL 9 SMBs to Enterprises
Apigee Proxy Commercial 598 SMBs to Enterprises Powerful Analytics
Axway Proxy Commercial 9 SMBs to Enterprises
CA Layer7 Proxy Commercial 35 Enterprises Advanced support for mobile applications
IBM API Management Agent, Proxy Commercial 17 Enterprises Large Scale, User friendly
Mashape Proxy Commercial 106 Startups to Enterprises Monetization, discoverabilty
Mashery Agent, Proxy Commercial 57 SMBs to Enterprises API strategy services
Microsoft’s Azure API Management Agent, Proxy Commercial 262 Startups to Enterprises
MuleSoft Proxy Commercial 134 Enterprises Based on proven open source technology, programmableweb
Oracle SOA Proxy Commercial 213 Enterprises Large scale, SOA
Akana (formely SOA Software) Proxy Commercial 3 Enterprises
WSO2 Agent, Proxy Apache 4421 Startups to Enterprises Open source

3scale

3Scale is very active on the API management space with a wide range of customers, ranging from startups to enterprises. They provide a hybrid solution to help you deploy, manage, distribute and monitor your API. They offer an on premises API management solution along with cloud based API administration, analytics, reports, developer and partner portal.
More about 3Scale: http://www.3scale.net/api-management/

Mashape

Mashape does not offer an API Management service per se. They provide important features that are part of such services though. You may test an API, generate code, and get a developer portal and user management. Most importantly they provide out-of-the-box monetization, a developer community and discoverability through their API marketplace.
More about Mashape: https://www.mashape.com/

Microsoft’s Azure API Management

Microsoft’s Azure API Management became available to the public rather recently. You can provide and manage an API, get developer portals, documentation, security management, performance management, statistics and analytics. They have on-premises and cloud versions (not limited to the Azure cloud).
More about Azure API Management: http://azure.microsoft.com/en-us/services/api-management/

Apigee

Apigee provides a range of services, from free API tools for developers to large API management solutions for enterprises. Their solution can be deployed in the cloud or on-premises. They offer API analytics, developer portal, transformations, traffic and performance management. Apigee seems to provide the richest API analytics platform compared to other companies. In mid-2014, they launched the new version of their big data predictive analytics platform.
More about Apigee: http://apigee.com/

Mashery

Mashery is an Intel company since 2013. They provide an all-around API management solution that supports SaaS and on-premises implementations as well as a few hybrid oriented ones. Their services cover from API technology and infrastructure to business strategy.
More about Mashery: http://www.mashery.com/api-management

CA Layer7

Layer7’s API Management is heavily enterprise directed. They offer on-premises and cloud deployment solutions. Their services range from integration, security management, performance management, mobile API gateways, mobile optimization and developer portals. CA’s support for mobile applications is considered to be more feature reached compared to other solutions.
More about CA: http://www.ca.com/

IBM API Management

IBM’s solution comes either as on-premise or cloud hosted. It covers a lot of the API management needs of a large company and it is considered a much user-friendly platform.
More about IBM API Management: https://apim.ibmcloud.com

Oracle SOA

Oracle provides an API Management solution that consists of its API gateway and SOA suite. The API gateway is used for securing and managing APIs and as a first line of defense in SOA environments.
More about Oracle SOA: http://www.oracle.com/us/products/middleware/soa/api-management/overview/index.html

MuleSoft

MuleSoft’s solutions is based on open source technology. They offer easy API design, advanced integration and testing features. It is widely used and they also work a lot with developer communities.
More about Mulesoft: http://www.mulesoft.com/

Akana (formely SOA Software)

They provide a unified Enterprise level API management and SOA Governance solution. It can be implemented on-premises or in the cloud. They offer a horizontal solution from design and building an API to policies, security and lifecycle management.
More about SOA Software: https://www.soa.com/solution/api-management

Axway

They offer an API Gateway that provides everything you need to develop, integrate and manage APIs. They provide security management and of course an API Portal for developers and partners.
More about Axway: http://www.axway.com/en/enterprise-solutions/api-management

WSO2

WSO2 is considered the most complete open source solution today. It covers API integration, management, identity and mobile. It supports public, private clouds, and hybrid implementations. WSO2 follows an open development process, where customers can provide input.
More about WSO2: http://wso2.com/

ApiAxle

It is an open source API management and analytics solution. It is a proxy that sits in front of your API and manages caching, security, performance and traffic. As an open source project, you may contribute to its code base.
More about ApiAxle: http://www.exiconglobal.com/apiaxle/

Epilogue

Not all companies launch API programs and not all API programs have the same goals. Some APIs are used as a revenue model or part of a product or service, others are free. Certain APIs are used to provide access and information to an ecosystem of companies. As the requirements vary, the tools diversify. So choose your API strategy and pickup the right tool.

 

Which are your favourite tools? Let us know and shape the future of developer economics. Take the survey.

Categories
Business

Developer Corner: Why successful indie developers are becoming a dying breed

I started developing iOS apps 5 years ago, which can be loosely equated to 50 years in a different, non-tech industry, where the pace of growth is much slower. As a sign of the warp speed at which things are moving within the app economy, simply consider that when I started, back in 2010, there were only 300.000 apps and those were only in the Apple App Store; right now there are over 3 million apps across all stores, which goes to show the phenomenal pace with which the app economy is skyrocketing. During this time I’ve developed over 12 apps at Anlock as an indie dev, which have seen 2 million downloads, and more than 4.000 reviews with an average rating of 4.0 across 110+ countries.

indie-devs

Aside from app development, I’ve also been very active in the kids’ educational developer community, starting as a member of Moms with Apps in 2011. Later, I co-founded the Know What’s Inside™ program, dedicated to helping family-friendly app developers implement best practices around privacy and complying with privacy rules. And for many years I was head of the App Friday program, which was created by family-friendly app developers who simply wanted to raise visibility around kids’ educational apps.

Due to this active involvement, I have seen many fellow indie developers come and go. At first, some of them made it big for no reason that I could fathom, but later, as the industry matured, it became increasingly harder to succeed and a very small number of indie devs actually made it. [tweetable]Success in the app industry is the product of hard work and continuous efforts[/tweetable], and most of the indie devs I know eventually tire out and throw in the towel; a couple of months ago it was my turn.

Because of this extremely fast pace with which the industry is growing, I have always been on the edge, trying to cope with the curveballs the App Store has been throwing. At the beginning, the challenge was simple – all you needed to do to succeed was put together a decent app that was centered around the revolutionary concept of users interacting with content through touch on their phone screens. Soon the challenge shifted and the focus was on having appealing graphics and marketing your app. Very quickly, marketing become predominant, if you did not have a marketing plan in place before you even started developing your app you had no chance. At the time, that meant actively using Facebook (before its IPO, when posting was free), Twitter, YouTube, cross-selling between apps, etc.

And then, a few months ago, I realized that the last curveball the market had thrown was beyond our small team at Anlock. Having a good idea for an app, a good UI/UX execution with excellent coding skills and a marketing plan was simply not enough any more. The app idea itself had to be exquisite and its UI/UX execution brilliant to even have the slightest chance of success. Which absolutely makes sense when you consider there are 3 million apps out there. Of course there will always be Flappy Birds that are beyond “logic” and hit a nerve with users and go viral, but that is one app in 3 million, quite literally.

As far as I was concerned, [tweetable]the app market has just reached that hyper-competitive stage[/tweetable] that was simply beyond our team at Anlock, despite our years of experience, our extensive app portfolio and our 2 million downloads. So, when the opportunity presented itself I opted out and left Anlock.

There I was with 5 years of solid iOS development faced with either having to start all over again in a hyper-competitive market or get a job as a freelance iOS developer. Having closely followed the debate about tech talent shortage the past year I decided to go freelance.

It only took me about a month to realize that are a lot of job openings out there and I actually got to pick the role I found most fascinating and challenging. I have now joined Daredevil Project that “makes mobile social games for the ‘real word’”, in charge of the iOS development of Duel that will be launched in the coming months, effectively putting an end on my indie years … for now at least!