Powered By CocoonJS: Elliot Quest

Here at Ludei we try to review and stay in touch with many (if not all) of the developers in our community. We are always amazed by the quality of products that you guys publish and try to provide the best feedback and listen to all your needs in order to improve the platform.

Today, we want to focus on a very interesting project we knew about some time ago as it was a successfully backed KickStarter project that looked amazing and was highly anticipated: Elliot Quest. We have been in touch with the mind behind the project (Luis Zuno) and we are happy to announce that the OUYA version of the game has been published powered by CocoonJS’ Canvas+ technology. In this case the game was developed using ImpactJS, one of the many game development engines Canvas+ supports. The game is also available on Steam now and there is a WiiU version coming out soon. 

Luis has been really kind to write some words about his project and the process of using CocoonJS.

“Since I started working on Elliot Quest, I always wanted to have the possibility to publish my game on a platform such as OUYA, but due to the limitations of the default HTML5 runtimes it was nearly impossible. I was getting 16FPS and the game was unplayable.

Fortunately I found CocoonJS and it’s Canvas+ technology and my wishes became a reality! The performance is simply awesome, the framerate is stable and it supports the gamepad API with the same HTML5 standard API. It is fully compatible with ImpactJS and as a developer it was a relief to find the CocoonJS cloud compiler service. Compiling the game and testing it on the console was a delight and the support team helped me during the whole process.

I recommend CocoonJS to any developer that wants to get their HTML5 products to mobile native platforms.”

We want to applaud the great work behind Elliot Quest and all of the projects that are being published using CocoonJS. Thank you very much everyone, you are the reason why CocoonJS exists and hope to see more great products published in the future!

If you have an interesting project, do not hesitate to let us know about it. We will try to periodically write posts about interesting apps published using CocoonJS.

 

Build Phonegap/Cordova Apps using the WKWebview right now

We recently announced big news in our platform: the possibility to publish standalone apps powered with the iOS 8 new WKWebview. Today, we are glad to announce a new Cordova plugin for publishing Cordova/Phonegap powered with the WKWebView that you can use right in your terminal.

cordova

Webview+ for iOS (and Android!)

Our engineering team worked very hard to create the Webview+ for Android (more info on how to use it here), a uniform webview on any Android 4.x device based on all the power of Chromium. We are glad to announce the Webview+ for iOS, a plugin for cordova apps that provides a replacement for the UIWebView that includes the Nitro JS engine based on the WKWebView.

If you are a HTML5 app developer, you probably know that iOS HTML5 capabilities are still lagging far behind. The WKWebView solves most of the common problems of HTML5 on iOS and even increases the features that you can use.

WebView+

Create a Cordova app using the WebView+

Install the latest version of CocoonJS CLI (this is really important)

$ sudo npm install -g cocoonjs

Create a Cordova project and add the Webview+ for ios:

$ cocoonjs create MyProject
$ cd MyProject
$ cocoonjs platform add ios
$ cocoonjs plugin add com.ludei.ios.webview.plus -d

If you already have a Cordova/Phonegap project just run the following command

$ cocoonjs plugin add com.ludei.ios.webview.plus

And now your project is powered with the Webview+. You can test it by running this command:

$ cocoonjs emulate

or

$ cocoonjs run

More Info

About HTML5 APIs

Latest CocoonJS Releases

New versions of some components of CocoonJS are published. Please, share with us your comments about these releases. Your feedback is important to find bugs and determine next improvements. Enjoy!

Core 2.1.1

iOS

  • iOS ARM64 support
  • Enabled WV+ on 64 bit devices

Services

  • Updated the following third-party services
    • iOS Google Plus SDK
    • Crittercism sdk to version 5.0.5
    • iOS Flurry SDK
    • OpenAL to openal-soft-1.16.0 and enabled OpenSL backend
    • Android-support-v4 updated to 21.0.0 and google-play-services to 6.1.71
    • Parse library to 1.6 in android and 1.4 on iOS (latest ones)
  • Removed Brightroll support.
  • Removed Yume support of iOS.

Canvas+ 2.1.1

  • Fix rare bug where Canvas+ could crash when executing code in onTouchEnd listeners
  • Fixed threading bug which was consuming battery when app was in background
  • Removed support for the GLES1 canvas+ rendering path.

Launcher 2.1.1 for Android

  • Updated to Core and Canvas+ 2.1.1
  • Fixed loading URLs with spaces

Launcher 2.1.1 for iOS

  • Updated to Core and Canvas+ 2.1.1

WebView+ for Android 2.4.0

  • Updated to LudeiChromium_1.0.37.0.2062.94
    • Several bugs fixed for Cordova 3.6 compatibility
    • Added methods needed by Android 5.0
  • Removed unused log and changed exit code.

See repo on github.

Plugins 3.0.5

See repo on github.

CocoonJS CLI now with live reload

At Ludei coding never stops, and today, we’d like to introduce to you the new feature we’ve added to our CocoonJS Command Line Interface: live reload.

We are javascript developers too and we’re aware of the need of being productive. We realized we needed a faster way to iterate over our JS code, so why not include the live reload capability to our CLI?

For those who don’t know what live reload is, this feature reloads automatically the code of your app inside the connected browsers each time you save your changes. This way you forget about saving, going to the launcher, and refreshing the content to see the changes every time.

How do I benefit from this new feature?

First of all you must update your cocoonjs-cli version. You can find more information about our CLI here.

sudo npm install -g cocoonjs

Then, you can create a new project, as always:

$ cocoonjs create MyProject com.ludei.test LudeiTest
$ cd MyProject
$ cocoonjs platform add android
$ cocoonjs serve

You’ll read a message like this one:

[CocoonJS] Executing command ‘serve’
[CocoonJS] A ‘cordova prepare’ is needed before executing ‘cordova serve’.
[CocoonJS] Command ‘cordova prepare’ executed correctly.
[CocoonJS] Static file server running on port 8070 (i.e. http://192.168.0.43:8070)
[CocoonJS] Path: /Volumes/data/hello-world
[CocoonJS] CTRL + C to shut down

Now, open a launcher an point to that web address. In our case http://172.16.100.43:8070. You’ll find the default main page. Also, if you are working in the same machine where the command was executed, you can point to the loopback/localhost interface (127.0.0.1).

Open the contents of the www folder with your code editor, and edit them. Each time you save the code, the launcher will refresh with the new content!

The video below is a good demo.

We hope you’ll love it!

CocoonJS Announces the WebView+ for iOS 8: Publish WKWebView Powered Standalone Apps

Apple’s new iOS version 8 announcement brought many good news for the HTML5 developer community. Safari has improved much (it now supports WebGL for example, yay!) and the system webview now comes in two different flavors: UIWebView and WKWebView. The main difference is related to the JIT optimization for JavaScript. To put it in plain words: the execution speed for JavaScript code is orders of magnitude faster using a JIT compiler and thus, your web app may run much faster inside the new WKWebView than in our older friend the UIWebView. To know more about the WKWebView and to have a glimps of the performance improvements, please, check the following great article by Sencha or check our own tests below.

At Ludei, we immediately started playing around with the WKWebView as we were eager to provide it along with all the great runtime environments we have (Canvas+, WebView and WebView+ for Android). But there was a catch. At least in the current version of iOS, there is no way of deploying a native hybrid HTML5 app using the WKWebView that has access to local files, something that is quite common on Hybrid apps to be able to execute them off-line. But Ludei has always loved a good challenge and we decided to solve the problem and make the WKWebView available to every developer that would like to use it.

Today, we are happy to announce that we have added a way to create WKWebView based completely standalone hybrid applications for iOS 8 in our CocoonJS Cloud Compiler System version 2.1. As far as we know, no other technology allows to publicly create completely offline WKWebView based apps at the moment. We have decided to call the WKWebView based runtime environment: WebView+ on iOS 8. We will still provide Canvas+ and the regular UIWebView, but every CocoonJS developer that wants to take advantage of the WKWebView, is able to do it right now. Whenever the application is running on an iOS version lower than 8.0 where the WKWebView is not available, there will be a fallback to the UIWebView.

We have also added this shiny new WebView+ for iOS inside our CocoonJS Launcher that is still in review by Apple. Meanwhile, if you want to check the awesome performance that it provides, you can build a Custom CocoonJS Launcher using our cloud.

ADDITIONAL NOTE: We are working hard to add the WebView+ to the CocoonJS CLI too! Stay tuned!

WebView+ Vs WebView on iOS 8

We have performed some tests ourselves to check how much of a better option the WKWebView (CocoonJS WebView+ for iOS 8) is compared to the UIWebView (CocoonJS WebView). These are the results:

Canvas intensive operations

All the test were executed on a iPad Air iOS 8.0.2

First test

2000 sprites rotation + translation with sprite animation rotation and random colored vertices

  • Webview+ : 30 FPS stable
  • System Webview: 6 FPS stable

Second test

3000 sprites Rotation + translation. Using 3 framebuffers. Transparency and tint with custom shader and custom clip area

  • Webview+: 20 FPS stable
  • System Webview: 4 FPS with unstable frame timing

Third test

5000 sprites 32×32 using rotation + translation, tinted vertices and MipMap

  • Webview+ 17 FPS stable
  • System Webview: 3FPS with a frame timing between 379 and 400ms

Tests with well known benchmarks

All the test were executed on a iPhone 5 running iOS 8.0.2

Octane 2.0

Octane 2.0: is the javascript benchmark from the v8 team. Lets see the differences between webview+ and webview. The higher the mark, the better.

Octane test Webview+ Webview
Richards 2712 117
Deltablue 2834 125
Crypto 3491 203
Raytrace 3474 365
EarleyBoyer 5118 636
Regexp 382 42,5
Splay 2384 605
SplayLatency 1641 2101
NavierStrokes 3455 323
pdf.js 3025 1006
Mandreel 2407 118
MandreelLatency 1784 702
GB emulator 4593 943
CodeLoad 5315 3912
Box2DWeb 2806 689
zlib 4675 N/A
Typescript 4363 N/A
Octane Score 2819 N/A

N/A means that the benchmark stops or freezes the the device.

Wirple BMark

This is test for webGL performance. The higher the score, the better.

Test Name Webview+ Webview
Canvas test1 61 26
Canvas test 2 38 10
WebGL test 1 17 7
WebGL test 2 14 7
Total score 130 50

Of course, some screenshots of the results ;)

The webview+’s results on Wirple BMark

Screen Shot 2014-10-22 at 18.34.00

The system webview after running Wirple BMark

Screen Shot 2014-10-22 at 18.34.14

Techniques to Optimize Memory Use in CocoonJS Canvas+ Environment

Memory is a critical resource in HTML5/JavaScript game development, especially on mobile devices. In a desktop environment you can load tons of textures but on some low-end mobile devices you can reach the maximum RAM limit quickly. Although JavaScript encourages automatic memory management by using a garbage collection mechanism, you shouldn’t ignore effective memory management techniques. HTML5/JavaScript applications can suffer the same memory related problems as native applications, such as memory leaks, out of memory issues and they must also deal with garbage collection pauses. 

This post will give you some general advice on memory optimization for HTML5 games and some CocoonJS Canvas+ specific tips.

Effective asset loading

Preloading all the assets at the start is the easiest and quickest way to manage the memory but it only works for small games where all the assets fit into the available memory. You shouldn’t preload everything on a heavy game, only the assets that you need each time, and dispose of the unneeded assets as soon as possible. Your game memory usage depends highly on your game engine (some of them do a better job than others). Don’t expect that the browser or the garbage collector will fix all your problems and that you can stop worrying about effective memory management.

Texture packer

Javascript images and canvas objects are backed into OpenGL textures and FBOs, usually using RGBA format, 32 bits per pixel. Think about it, for example a 2048×2048 image eats 16MB of memory!  Some GPUs require POT (Power Of Two) textures for the best performance, so keep in mind that some images could use more memory than their real size and use 2^n size textures whenever you can.

We recommend that you pack all your textures using one of the Sprite Packer tools out there. That way you’ll waste less memory and improve performance (by avoiding the number of context switchings) and loading times. Some HTML5 engines are able to pack all your textures at runtime, others don’t, so please check your engine features first.

Garbage Collection

JavaScript automatically frees objects when it detects that they are not used anymore, this process is called garbage collection. During a collection the execution on your page can be suspended for a moment. If your game creates too many JavaScript objects in each frame it can lead to noticeable pause issues. This is another example that proves that it is a mistake to forget about memory management on JavaScript. You should reuse javascript objects whenever possible.

The dispose method

Image and Canvas objects are disposed when the garbage collector detects that they are not reachable in the JS code. The disposal is not immediate, it may take some seconds depending on the heuristic rules of the JavaScript virtual machine. Using a WebGL context the developer has more precise control over the WebGL texture and buffers disposal but that’s not the case when using a 2d context or when dealing with Image and Canvas objects.

CocoonJS’ Canvas+ environment exposes a method called “dispose” on canvas, image and audio objects. This method immediately frees the associated texture or internal buffer, which is very useful for games with heavy textures or for games that need a greater control over the memory.

Using this CocoonJS Canvas+ exclusive feature is very easy. Imagine we have an image object represented by the “myImage” variable.

myImage.dispose && myImage.dispose(); // The same for canvas and audio objects.

The memory warning event

iOS and Android native applications are able to receive a memory warning notification from the system. The default implementation in Canvas+ and WebView+ environments is to perform a garbage collection and free as many internal cached data objects as possible.

From CocoonJS Canvas +2.1, the environment exposes the “memorywarning“ notification as a window listener. It is strongly recommended that you implement this method and free up as much memory as possible by disposing of cached data objects, images on canvases that can be recreated.

Cocoon.on(“memorywarning”, function() {
  // dispose of cached images and canvases that can be recreated
});

Texture reducer

Texture reducer is a CocoonJS Canvas+ exclusive feature. When your game targets all resolutions you need huge textures for iPad retina like devices and small textures for small mobile devices. A game developer has many ways to handle this:

  1. Create different asset packages, HD and normal. Good solution but bigger app size.
  2. Scale down HD resources. Excessive memory usage and performance impact on small devices.
  3. Create smaller asset packages on runtime rendering to a canvas/texture. Good solution but some JavaScript engines don’t support this.

The CocoonJS Canvas+ texture reducer feature can transparently do the job for you. It uses the third approach and it is highly customizable (for example, you can only apply it to certain resources). Check out the complete API documentation to see how to set it up.

As the texture reduction lowers the quality of the final images to be displayed, an interesting approach that we have recommended to some customers is to apply it only for certain device models, leaving higher resolution for some others (you can use the “navigator.userAgent” property to identify the device model). This, of course, it is not an easy task on Android due to the big number of device types, but on iOS is definitively an interesting option, specially for older devices such as the iPhone4 or the iPad Mini 1st generation.

Max Memory Threshold

This new CocoonJS Canvas+ exclusive feature available from version 2.1 and higher, exposes the “setMaxMemory” utility method. When the max memory threshold is set, CocoonJS checks the total amount of texture sizes (images and canvases). When the runtime memory size reaches the max memory threshold, CocoonJS disposes of the least recently used textures until the memory fits the threshold. It disposes of textures used for JS Image objects (which can be reloaded later if needed or are drawn again). It doesn’t dispose of canvas objects because they cannot be reconstructed if they are used again in a render operation. This extension is designed to be used in 2D contexts, because in WebGL contexts the developer is the one responsible for memory disposal.

Check out the API documentation.

Lazy Loading

Another CocoonJS Canvas+ exclusive feature available on version 2.1 and higher we have added the “cocoonLazyLoad” boolean property to Image objects (we have also added a duplicate called “idtkLoadDisposed” for retro compatibility with Construct2). When the property is set to true, the image is not loaded until it’s used in a render operation. Engines that load all the assets at startup can benefit from this property. But do not forget to purge the textures when they are not needed again, for example, using the dispose mechanism described earlier!

NPOT Textures

Canvas+ uses POT (Power Of Two) textures by default in 2d contexts. This is very useful for performance improvements, especially on mobiles with old GPUs. But it can waste memory on games that don’t use packed or 2^n textures. In CocoonJS Canvas+ version 2.1 you can allow NPOT textures in Canvas2D contexts (they were already supported in WebGL).

Check out the API documentation.

Conclusion

We have covered some basics of memory management in HTML5 games and exposed Canvas+ specific tips and tools.  We are always open to your suggestions. Remember that if you have some problem with memory usage in Canvas+ and you think that the problem is on our side you can send us a testcase and we’ll be glad to help you.

Additional Notes about Ludei’s Canvas+ Environment

CocoonJS’ Canvas+ is not a full browser, but a highly optimized JavaScript Virtual Machine for Canvas 2D and WebGL environments. Comparing it to a full fetched browser is not recommended as browsers include “a lot of magic tricks” (and that is why sometimes they are big and slow). For example, a browser might be able to handle a 5000 by 5000 pixels image but that does not mean that the underlying device is able to do it, just that the browser is handling some things internally for you either lowering the quality of the image (downscaling it) or subdividing it. Very few native technologies (C++ game engines) allow this kind of features as the developers should know how to handle this situations correctly (do not use 5000×5000 textures in the first place). Here at Ludei we never intended to create a new browser, but provide a highly specialized runtime environment so HTML5 developers can be closer to the native side without ever leaving JavaScript and the great HTML5 APIs.

CocoonJS Enables Android Wear HTML5 App Development

Google announced Android Wear this year, a new Android OS version suitable for wearable devices (Google Glass and smartwatches for now). Of course, Ludei right away started to wonder what kind of HTML5 execution capabilities will be available in such interesting devices. A couple of weeks ago, we purchased several Android Wear watches and begin to perform some tests over them. The first thing that we noticed was that at least this initial version of Android Wear does not come with a system WebView. It kind of makes sense as it is a very constrained environment and webviews are very resource demanding. Every attempt to execute a full fetched web environment on Android Wear Smartwatches has shown really low performance. Still, we wanted to see HTML5 running on a Smartwatch and how a good of a fit our highly optimized Canvas+ technology could be for Android wear. Our results were really encouraging as Canvas+ works amazingly well on these devices. Check out the following video that shows some HTML5 canvas apps and games running on Android Wear!

Of course, some minor modifications had to be done both to the technology and our cloud compiler, but we are more than happy to announce that we have enabled a new compilation target inside the CocoonJS Cloud Compilation System so any developer inside our community can test it. As far as we know, CocoonJS is the only technology that allows to deploy hybrid HTML5 applications for Android Wear even supporting WebGL! This is just an initial testing environment that allows you to build Android Wear applications but there are some initial limitations:

  • Do not add ad services. These services use the system webview to show ads and as we mentioned, Android Wear does not have a system webview.
  • Although you will be able to install the resulting APK on your smartwatch, we need to work on ways to better integrate the Android and Android Wear experiences. Please, use this initial builds for testing purposes.

If you want to test it, you need to make sure your app works on our Canvas+ environment. You can test it using the CocoonJS Launcher for iOS on iTunes, GooglePlay or Amazon. Then, just go to the CocoonJS cloud compiler, create or select an existing project, go to “Compile Project” and you should see the new target “Android Wear”.

Screen Shot 2014-10-23 at 12.44.03

Once you select the target, as it happens with any other CocoonJS compilation, a simple APK will be built in our cloud service, similar to the GooglePlay, OUYA or Amazon APKs, and it will be sent to your email account, but this one completely prepared to be executed on a Android Wear device. Connecting to Android Wear devices is similar to any other Android device as you will need to activate the developer options in the device and allow USB debugging. 

Enjoy testing your games and apps on an Android Smartwatch!

CocoonJS Latest Releases

New versions of some components of CocoonJS are ready. Please, share with us your comments about these releases. Your feedback is important to find bugs and determine next improvements. Enjoy!

Core v2.1

All platforms

  • Implemented custom Keyboard handling so users can enter text directly into the app, without popping up a dialog.
  • Cordova support is now always available for all platforms and environments in CocoonJS.

iOS

  • Added the new CocoonJS WebView+ for iOS 8 based on the new WKWebView (Only for 32-bit devices at the moment).
  • Fixed iOS 8 orientation and layout issues.
  • Drop iOS 5 support.
  • Updated the following third-party services
    • FacebookSDK.framework (3.19).
    • Google Play Services (3.0).
  • Fixed bug where reloading with an open websocket made the app crash.
  • Fixed bug where sending a score to GameCenter could cause a crash in poor-quality networks.
  • Fixed bug where after a reload, the system WV was being loaded instead of the WebView+.

Android

  • Added the option to compile Canvas+ projects for Android Wear.
  • Added support for the new ART Java virtual machine.
  • Fixed bug where making a webview call forwarding replaced the HTML body with the returned value in some Android versions.
  • Alert dialogs buttons behavior was not consistent across Android versions. Fixed.
  • Fixed rare case where the webview was being added twice.
  • Fixed negative values as notification ids.
  • Fixed case where webview would remain black after load.

Services

  • Updated the following third-party services
    • Google Play Services (5.0.89)
    • MoPub (3.1.0)
    • AdColony (2.2.4)
    • AdMob (6.12.0)
    • Chartboost (5.0.1)
    • Greystripe (4.3)
    • InMobi (4.5.1)
    • MillenialMedia (5.4.1)
    • Parse (Android: 1.6.0, iOS: 1.4.0)
    • iAd
  • Fixed rare crash when using local notifications.
  • Fixed type cast error showing in the console when sending a push notification.

Canvas+ v2.1

  • Added 8 WebGL extensions:
    • WebGLVertexArrayObjectOES
    • WebGLCompressedTextureS3TC
    • WebGLCompressedTexturePVRTC
    • WebGLTextureFloat
    • WebGLTextureHalfFloat
    • WebGLTextureFloatLinear
    • WebGLTextureHalfFloatLinear
    • WebGLTextureFilterAnisotropic
  • Fixed ambiguity when getting the window.location.port value.
  • Added NPOT texture support for Canvas2D.
  • Added a mechanism to discard seldom-used textures when the app receives a memory warning, to keep Canvas+ working even if the app loads more images than fit in memory.
  • Added a lazy-loading mechanism so images can be loaded on first use instead of when the src attribute is set.
  • Fixed rarely-occurring deadlock when pausing audios.
  • Fixed issue with the audio system not being ended correctly if the audio thread was locked.

WebView+ for Android v2.2.0

  • Updated to Chromium 36.0.1985.143.
  • Fixed unnecessary creation of shell additional instance.
  • Fixed cache mode.

See on github.

Plugins v3.0.4

See on github.

Launcher v2.1

  • New UI for both Android and iOS versions.
  • Added filename/URL search mechanism.
  • Added Favorites panel.
  • The Android Launcher now allows navigation through the whole device file system and loads not only .zip files but entire folders too.
  • Improvements to the debug service usability. Also, new error/warning reporting icons.
  • Restructured settings dialog.
  • More stable architecture. The launcher will keep working even if CocoonJS has a runtime problem.
  • Fixed several problems on Android 2.3.
  • Android launcher now allows canceling the app load process.

CLI v1.0.0-0.5.0

  • CocoonJS serve now has livereload enabled by default.

Known issues:

  • Livereload feature not work in system webviews with no websockets support.

See on github.

The End Of The Wrappers? I Don’t Think So!

It’s official: HTML5 is hot once again. For the past year, many of the wishes that all HTML5 developers have been waiting for have finally come true. All major browsing technologies support the main HTML5 features that make this technology a great option to develop beautiful desktop sites and compelling mobile apps. The latest addition to the list of iOS 8 with its official support for WebGL and improved webview called WKWebView with Nitro JIT acceleration, has been widely applauded by the community. And there are plenty of other reasons to be happy if you are an HTML5 developer, as the runtime environment that will run your app or game is a major issue that has been holding back the widespreading of the web as a major development platform (specially on mobile) for the last years.

There are many articles out there around performance benchmarks of the current browsers. Chromium based solutions for Android, Internet Explorer supporting the main HTML5 specifications (and auto updating itself quite regularly), plenty of great app development frameworks, … the list of good news is long. And here at Ludei, we are glad that, finally, all the pieces are starting to come together. But (there is always a but ;)), we have been reading much about a concept we do not agree with, and is the apocaliptic calling to “the end of the wrapping technologies” for mobile web applications. Ludei has been providing great tools and technology for HTML5 developers for the last couple of years.

Ludei’s developer community has grown strong to 50,000 developers and more than 4,500 apps published on mobile markets. We are going to continue to provide a great development experience and the best tools and runtimes as long as they continue to come out to the market. But there is a reality we still know about: building compelling mobile web apps is not simple. And we are not just talking about developing the app itself. Some frameworks are getting mature, some are starting to show their potential, but there is a detail worth mentioning: the mobile space is not the same as desktop web app development.

  1. First of all, mobile users are used to and feel comfortable with app stores, so they want apps. Building an app is not a major issue, but still, lots of web developers do not want to face all the hassle of installing native SDKs, compile applications and moreover, update multiple tools to be able to create their final mobile apps.
  2. But not only this, successful apps need access to native SDKs and mobile features that may vary from one platform to the other, or even from one store to the other. We are talking about in-app payments, ad networks, push notifications, social network SDK integrations, etc.
  3. Additionally (and sadly), there is still not one runtime environment solution that fits all and not plenty of good tools to test and debug apps on mobile. At Ludei, we have developed our own HTML5 runtime environments (Canvas+ and WebView+) and we also provide access to use the system web browsing technologies. This way, developers can choose what works best for them depending on their app. Even our canvas only technology, Canvas+, has plenty of advantages that some other technologies do not have for some type of apps (mainly games): low footprint, advanced memory management, extensions, accelerated physics, full control over the runtime (crucial for some customers), etc.

All these features are what wrapping technologies like Ludei’s CocoonJS or Apache Cordova provide: A productive way of testing, creating and monetizing HTML5 mobile apps. The bottom line is, that we are far from a mobile browser only app and game market. App stores on mobile will continue to exist, and actually, that’s the beauty of HTML5, your product can exist in both environments (as a browser based discoverable app and a mobile app store app). Mobile web app development is here to stay and grow and wrapping technologies are far from being at their end, moreover, in our opinion, they are at their infancy.

iOS 8 support added to the CocoonJS Cloud Compiler

After the official iOS8 release on September 17, 2014, we are proud to announce that the iOS 8 support integration is now completed and ready to use in the CocoonJS Cloud compiler for both CocoonJS and Cordova compilations.

iOS8 support is available for all the supported CocoonJS versions at 2.0.1 and all the available Cordova versions. We are removing CocoonJS 2.0.0 support after this update.

Regarding the CocoonJS Launcher, an iOS 8 ready version is under review by Apple and will be available in the AppStore in the next weeks. In the meanwhile, remember that you can still use a Custom CocoonJS Launcher.

So you can start compiling and uploading your apps and games to the Apple AppStore with iOS8 support now!