News and Resources Tools

Oculus previews a new untethered VR headset

Welcome to DeveloperEconomics’ weekly news roundup. In this edition Oculus previews a new untethered headset, Cyanogen shifts business strategy to a modular OS program and online furniture store Wayfair releases its first API. Read on for the full news rundown.


Oculus working on cheap untethered headset


Oculus revealed plans to release an untethered VR headset during its developer conference last week. The new VR device is intended to sit between mobile and full PC experiences, without relying on a separate smart device, like Google Daydream. The device is currently in a prototype stage and Oculus has remained silent on a release date.


Cyanogen shifts to Modular OS program


Cyanogen has appointed a new CEO and says it will shift its business model toward a Modular OS program. The new Modular OS program gives developers more freedom to borrow from Cyanogen’s technology, removing the limitations of the full Cyanogen OS stack. The company previously admitted it was having difficulty scaling its userbase and laid-off 20% of its staff earlier this summer.


iOS 10 adoption outpacing all other iOS versions


iOS 10 is now installed on 66% of active devices, according to marketing firm Fiksu. The adoption of the latest version of Apple’s mobile OS has been faster than all previous versions, according to the company. A Fiksu representative said: “We’ve never seen this kind of acceleration in the adoption curve for an iOS upgrade.” Apple’s official numbers dispute Fiksu’s and claims the OS has reach 54% of devices.


Oculus introduces $499 VR-ready PC


Oculus showed-off an VR-ready PC costing just $499, during its developer summit last week. The rig meets new Oculus minimum requirements, enabled by asynchronous spacewarp technology, which lets 45 frames per second look like 90 frames per second. The new price point is half the cost of the VR-ready PC Oculus introduced last year.


WaveMaker enhances app tool API integrations


WaveMaker has updated its platform to allow enterprise devs to create hybrid mobile apps. The update supports integrations of apps on any stack, including Java, .NET, PHP, Python and Node.js. WaveMaker says its new platform also doesn’t require the deployment of server-side components, required to access data from systems independent of the technology stack.


Wayfair launches 3D model API


Online furniture retailer Wayfair has released its first API. The API gives developers access to over 10,000 “realistic” 3D furniture and décor models. Wayfair says it’s also working on its own VR and AR app that allows customers to view its catalogue of furniture in their own home.


NetBeans 8.2 releases ahead of Apache hand-off


Oracle has released version 8.2 of NetBeans. Version 8.2 is the last NetBeans release before the Java IDE leaves Oracle and becomes part of the Apache Software Foundation’s Incubator Project. New features include ECMAScript 6 support, Docker Support, PHP7 support and NodeJS enhancements.


Facebook open-sources Yarn, a JavaScript package manager


Facebook in collaboration with Exponent, Google and Tilde has open-sourced Yarn, a new Javascript package manager. Facebook are already using Yarn in production. It greatly improves speed compared to the official npm client and adds security by comparing checksums of the modules installed.


Visual Studio Code updated with TypeScript 2.0


Microsoft released version 1.6 of the code editor, bringing TypeScript 2.0 and more. Other improvements include Format on Save, Switch Windows (partially addresses this issue), search term history and more.


Facebook launches Workplace, enterprise social networking


Facebook has launched Workplace, an enterprise-focused messaging and social networking service. Workplace has chat, live video and audio calling, multi-emotional reactions and automatic translation services. Workplace has the Graph API for building custom integrations

Sign up for our weekly newsletter, with the latest facts and insights on the app economy.

News and Resources

Google planning hybrid Android/Chrome OS tablets

Welcome to DeveloperEconomics’ weekly news roundup. In this edition Google is reportedly planning hybrid devices that run both Android and Chrome, game developers boycott Oculus due to its founder’s support for Donald Trump and Google takes its Daydream SDK out of beta. Read on for the full news rundown.


Google planning hybrid Android/Chrome OS tablets

Google is reportedly planning hybrid devices that run both Android and Chrome, according to 9to5Google. The Andromeda project bakes Chrome OS features into Android and is reportedly being released on a Nexus-branded tablet and a convertible laptop. Rumours suggests the laptop device will launch in Q3 2017.


IBM releases IBM Bluemix Runtime for Swift

IBM has introduced a production-ready Swift runtime on the IBM Cloud. The release allows enterprises to take advantage of the server-side capabilities in Apple’s programming language, for building microservice APIs on its cloud platform. IBM says by unlocking Swift for enterprises it’s “reached another milestone” in its “shared journey with Apple.”


Microsoft announces 400m Windows 10 users

Microsoft says Windows 10 now has over 400 million active users. The last update on user growth was in July, when the OS hit 350, just before it ended its free upgrade period. Microsoft’s original goal was to have one billion devices running Windows 10 by 2018, but the company has since backtracked and is not specifying when it will hit the one billion milestone.


Oracle announces new products for cloud platform

Oracle unveiled 20 new products and services for its Oracle Cloud Platform at the annual OpenWorld conference last week. New products include the cloud-based Oracle Database 12c Release 2, along with an SaaS offering, which combines third party data with real-time analytics for “adaptive” app development. During the announcements, Oracle’s CTO Larry Ellison said Amazon now has “serious competition going forward.”


SoundCloud devs must submit application for API access

SoundCloud has announced changes to its API policy, requiring devs to apply for access. The application form asks devs what categories their app falls under, how it makes money and whether the app plays content from the SoundCloud API. SoundCloud says the changes were made to stop apps from using content without the permission of creators.


Mopub modular ad SDK reduces app sizes

Twitter’s MoPub ad network has announced a new SDK that lets devs cut out the ad formats they don’t use. The modular SDK means devs can save up to 60% on disk space for Android apps and up to 35% for iOS apps, without losing any functionality. MoPub says the space savings will be particularly useful for Asia-Pacific devs, where expensive data plans can impact bigger apps.


Google takes Daydream VR tools out of beta

Google has released a new VR SDK, allowing devs to build VR experiences for Daydream-ready phones and headsets. The Daydream VR SDK 1.0 supports “integrated asynchronous reprojection, high fidelity spatialized audio and interactions using the Daydream controller.” The release also supports native integration in both Unity and Unreal Engine 4.


Facebook rolls-out Profile Expression Kit SDK

Developers can now integrate Facebook’s Profile Expression media into the apps. The Profile Expression Kit lets users turn media – such as Vine videos, Bommerang GIFs and Lollicam stickers – into profile pictures. Facebook says profiles are the second most visited surface on Facebook, allowing Expression Kit apps to generate a lot of exposure.


Onsen UI 2.0 now available

The Onsen UI team has released version 2.0 of its UI framework, which helps developers create native mobile apps with HTML5. While Onsen 1.x was based on Angular JS, the new version has no library dependencies, as well as new Material Design components. The team has also released new and improved documentation to make it easier for devs to get to grips with the framework.


Developers boycott Oculus over Trump-supporting founder

A number of Oculus developers are boycotting the VR platform due to the political views of its founder, Palmer Luckey. According to a Daily Beast report, Luckey funded a pro-Trump activist group, which posted anti-Hilary Clinton ads. Developer Scruta Games said it will “cancel Oculus support” unless Luckey steps down from his position at Oculus.


What the logs don’t tell you

In a world that is increasingly dominated by mobile applications and cloud services, APIs are becoming crucial to developers and service providers alike. But what are developers actually getting? And is this what service providers think they provide?



Developers want to use APIs that extend their service without having to either build the technology themselves or comply with required legislation or security (think payments or anything to do with storing large amounts of personal details).

[tweetable]Developers want simple, scalable, well-documented APIs that are as reliable as possible[/tweetable]. They do not want API they use to make their service unreliable, buggy or slow, i.e. make them look bad. Poorly-performing APIs can harm a developer’s reputation but also the API provider’s, should the branding of an API be visible to the world (think Twitter, Facebook, Instagram).

API Providers

API providers grant access to a service or services through the use of public or private APIs; a private API being a service that is not for public consumption for privacy or security reasons. Why grant access at all? To allow developers to use services and functionality that they do not have to build themselves and provide stickiness to an existing user base. Salesforce has done an amazing job of allowing third-party developers to use and extend the functionality that is provided and has even allowed developers to build a thriving apps and plugin community.

API providers look to balance the load on their servers that may also be dealing with other services. They are trying to provide minimum response times whilst maintaining the access and integrity of the data and the service for the developers.

Schrodinger’s API, it both works and doesn’t work at the same time

Here lies the problem; when an app that relies on an API performs badly whose fault is it? Is the app performing how the developer expected or is the API not responding and thus slowing the service? I[tweetable]t is very easy for the API provider to believe that just because the green light is on that the API is working[/tweetable]. Many systems behave completely different from the theoretical under load, when exposed to extreme conditions or elements beyond normal operation or even users doing unexpected things to the API.


System logs, either from servers, application monitoring tools or other conventional developer operating systems are excellent at hiding things because there is usually a lot of data to digest and identifying the issues from the noise can be nearly impossible.

Some examples include:

Averages – Whilst an average latency of 300ms may look ok its not if you are still getting a number of calls that take 10 seconds. To understand whether or not your slow performaning outliers are an issue means you have to look at the distribution of latencies and the frequency of the outliers.

Errors rates – hopefully these are low. Even a low error rate in a popular API can represent a huge issue. Consider an API that deals with 2 billion transactions a day at 0.2% error rate still has 4 million failed calls a day.

Logs only measure calls – If the API is not frequently used then the logs are not going to tell you anything. If the bulk of transactions are say only done on a Friday but the services failed on a Thursday then the detail will not be in the logs. Only frequent monitoring will notify you of issues before they hit your users.

Basically what the logs don’t tell you is how APIs work end to end, in different geographic regions and what the end-to-end latencies are when using real transactions.

Some simple rules

Monitoring is for life not just for Christmas.

An API that is switched on may not stay on but may be on every time you check.

The reliability of an API is inversely proportional to the number of people using it and the number of developers trying to do things that may break it.

The use of server logs is a function of user base and the amount of data being recorded.

Test the API like it would be used in the wild, end-to-end across a range of cloud services and apps. In this instance cloud services means hosting platforms like Google Apps Engine, Amazon Web Services and Azure to name a few.

Key question to ask is whether the servers are being tested for performance or the API and the impact on users and the overall experience?

As a developer and a user of services it’s the experience that matters. Poor experience equals poor brand perception, which leads to trying a different API or app, losing the client whether it’s a developer or a guy with an iPhone migrating onto the next app.

Things to consider when testing

Where is the data being served and where are your users?

An app that works in San Francisco when the server farm is in Mountain View may show differences when the same server farm has to serve the app in Europe. Test the API from different locations.

I got a HTTP200 response that means everything is fine, right?

Whilst most of us have seen HTTP 404’s, page not found, we also know HTTP 200 indicates an OK response from the server. The challenge comes from when a HTTP 200 means that things are not OK. For example, in order to avoid browser problems, some APIs only return HTTP 200 with an error message which needs to be parsed. Alternatively, the API might be returning invalid content which could cause an App to fail.

API search function comparison


In the above figure it can be seen that the average latency for search using the Facebook and Twitter API is approximately 2 seconds apart with Twitter being the faster and less erratic. Whilst we can only guess at what is happening in the background the reality is Facebook Graph Search appears to be less responsive to anyone using this feature in an app.

Regional server response variation


The above figure shows Facebook Get response across 6 regions globally. It can be seen that Asia and particularly Japan are poor cousins when it comes to regional performance. This behavior has been viewed with other APIs that have been tested in this way.

Caching data


The above figure shows the effect of caching on server response. After caching was implemented on the server it can be seen that response improved, even during refreshes (the spikes) overall performance was up.

Server issues


The above figure shows intermittent server issues over time. This can be indicative of load balancing issues or a problem with a server in a server cluster.

What is the future?

[tweetable]The number of APIs is only going to increase and developers are likely to rely on 3rd party services more and more[/tweetable]. It is also likely that more than one API from more than one provider will be used in an app. How can we mitigate against the response of one API compared to another? We see a need for intelligence in the app that can let that user know that something may be awry with the service trying to be accessed. This should be utilized as part of the UI flow to warn that ‘hey looks like is not responding, please bear with us’. This would be enabled by pinging the monitoring service to determine if there are any issues reported or the app being alerted automatically on a fail scenario that is outside pre-determined boundaries.

Intelligence in the monitoring will also lead to better understanding of the results and give a heads up to the API providers when issues occur or when the data is showing that a server is about to fail and allow providers to avoid downtime.

Disclaimer: Data was provided by who focus on API Performance measurement, testing and analytics. John Cooper is advisory board member at APImetrics

APIs Languages

Websites vs Web apps: What the experts think


Definitions of web sites vs. apps

Web sites are so deeply embedded into our daily culture that it is impossible to imagine life without them. Even as a developer, I find it hard to remember the times from my childhood when my chubby little hands didn’t yet know how to type. In the last two decades, the Internet has grown, expanded, exploded and became impossible to ignore, making any keyboard without an Internet connection pretty much useless.

In the last few years, the web brought with it a new term that can be exciting and confusing at the same time: “web app”. But what is a “web app”, how does it differentiate from a “web site” and why does it matter?

Understanding this difference ultimately makes us better users or developers? Is a business going to blossom just by marketing its online presence as a “web app” instead of a “web site”?

To figure out the boundaries between websites and web apps, I interviewed several prominent figures in the web technology domain who contributed with their experience and professionalism to help guide the debate: Dominique Hazael-Massieux (Mobile Web Initiative Activity Lead at World Wide Web Consortium), James Pearce (Head of Developer Advocacy at Facebook), Michael Mullany (CEO at Sencha), Christian Heilmann (Principal Developer Evangelist – HTML5/Open Web – at Mozilla Corporation) and Stephen Pinches (Head of Learning Technologies – ELT at Pearson plc and Group Product Manager – Mobile & Emerging Platforms at Financial Times). In this article I pieced together their expert input to help answer the web site vs web app debate.

The difference between Web sites and Web apps

In the pre app store era, the word “applications” had been applied to Web sites that provided advanced user interactions and capabilities previously available only through installable software. Early examples of web applications include Webmail, Google Maps and Google Docs. Compared to the classic web, i.e. blogs and news sites, web apps provided a richer user experience and access to advanced browser capabilities.

Today single-page web sites might still be referred to as web apps, but it’s more about the task focus than the technology itself. From this perspective, as Christian Heilmann explains, “The use case of an application is always to DO something with it”.

The task centricity of web apps is easier to understand if you think of smartphones or tablets: an app’s purpose is to achieve a specific task, like making a call, checking your email or finding a taxi nearby.

Some may argue that we can simply classify Web sites as being read-only and Web apps as being read-write. That certainly seems simple enough: Web sites are for consumption what Web apps are for creation. Does it sound right?

For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:

  • self-contained
  • rich/interactive user interface, possibly mimicking the native UI of the device,
  • using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing,
  • action oriented rather than information oriented
  • not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar),
  • working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database.

Mozilla’s Christian Heilmann argues that the offline attribute is not a technical necessity in terms of definition, but rather a crucial usability distinction:

“Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online”.

But how can we explain the difference to non-technical users? And, do we need to?

According to Dominique Hazael-Massieux, a Web site can be presented as a Web app as long as users consume it in a similar way they do a native app. If it’s exposed as an iconified app and used for a specific task, it shouldn’t matter whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web apps. I‘ve summed up his arguments:

Creation versus Consumption

Pearce asserts that read-only interaction should be classified as a site, but this criteria is not sufficient to distinguish between web sites and web apps. We still have cases like Flipboard (clearly oriented towards consumption) or Twitter and Facebook (with entirely user-generated content) that do not fit in any box.


Since both web sites and web apps can be launched by entering a URL into a browser or from a home-screen icon, this is clearly “not a reliable way to distinguish between web apps and web sites” according to Pearce.

User Experience

Visual pizzazz is an important argument, one that users might particularly relate to, but is also a fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list appears as hyperlinks instead of ‘tappable’ items? What if I use plain scrolling instead of smooth fancy bars?


In the case of single page webapps, is SEO the price to pay when choosing to give the browser far more autonomy and responsibility and take advantage of its HTML5 APIs like storage? Do Web sites have SEO capabilities while Web apps don’t? We are back to explaining the differences between the two by using technical terms.

Should you be building web apps or web sites?

This question might be regarded as a technicality with a pinch of marketing to spice it up. This reminds me of the “HTML5 is ready” contest by Sencha that was announced a few months back, encouraging developers to draw inspiration from native apps and create similar web apps that show off the capabilities of HTML5.

The creators of the competition correctly argued that “the mobile web is the most fertile ground for leading edge web development because it doesn’t have the legacy of the older internet explorers that the desktop does. You can start your development with the assumption that your app or your content will be used in a fairly recent browser, so you can take advantage of a whole host of features like Canvas, inline SVG, HTML5 video, CSS3 styling etc. that bring the experience alive for the user”, as Sencha’s Michael Mullany explains.

Would it be safe to argue in favour of building web apps instead of web sites especially on mobile? Mobile users perform specific tasks on their devices, so a web app that offers the same experience as a specialised native app might gain more interest compared to a regular website.

Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”

The ‘app-ification’ of the Web

Whatever your preference may be, there is an increasing number of mobile developers targeting web apps. Based on VisionMobile’s latest Developer Economics survey of 6,000+ developers, already 23% of HTML5 mobile developers develop web apps, compared to 38% who develop mobile websites.

With browsers increasing support for device APIs, and with a growing number of developers going direct to native with PhoneGap, Icenium or Appcelerator, or even with the recently launched Firefox OS, the web world is clearly moving in the direction of apps.

As Sir Tim Berners-Lee said in 2012, “the solution is in your hands: develop web apps!”

APIs Platforms

Facebook’s Mobile App Install Ads – will they work for developers?

Back in August, Facebook announced a beta for a new ad unit to help drive mobile app installs on iOS and Android. That product was made available to all developers recently and the early user reports are very positive. Is this early success likely to translate into a long term win-win for both Facebook and the mobile developer community?