(wall of text alert! there is a fair amount of history and technical ground to cover here)
First of all I just want to emphasise we did not remove the exporter: it's just hidden by default. You can continue to use it for existing projects, all you need to do is once-off show the deprecated plugins/exporters, and the setting is remembered.
I understand it comes as a surprise to some, but this really has been a long time coming. From our point of view it has been very difficult to support CocoonJS, to the extent that it has become a major source of complaints and refund requests, particularly from new users. Ludei have made it difficult for us to support CocoonJS on a number of occasions, and the open-source CocoonJS plugin is the latest round in a long story of really awkward technical problems they've created for us (and we can't simply drop it in to C2 - more on that in a moment).
First of all, looking at the current state of CocoonJS compatibility compared to other platforms, there are a number of gotchas:
- memory management: large games will take ages to load, and possibly just crash on startup. Every other platform supports memory management. This is a CocoonJS bug, and despite months of trying to explain the problem clearly and guide them to solutions, and even showing them our code changes in Ejecta to fix it, they have never fixed this. As far as I am aware they attempted it, but could not figure it out; this really makes it hard for me to be confident they can make their platform work. Meanwhile users continue to run in to this time and time again.
- no letterbox scale: this should be simple to add, but again they never did. Every other platform supports letterbox scale. Now every CocoonJS game has to deal with variable aspect ratios, which can be a lot more work, or a nasty gotcha when you've finished your game for mobile browsers and want to port it to native.
- no XML parsing (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
- no form controls (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
- no Web Audio API support for effects/3D audio etc (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
- no multiplayer support (supported by Crosswalk, not iOS yet but perhaps if Apple add support)
- no web workers, so pathfinding calculations have to be synchronous and impact the game framerate (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
- user media/speech features not supported (to be fair, I am not sure on the status of these for Crosswalk/PhoneGap, but since they are based on real browser engines with underlying support it should be practical to add support if not already supported)
Some games can get by despite that list, and that's fine. However I can tell you we regularly hear about the pain of users who keep running in to these same issues time and again. Often the user appears to come away with a perception that Construct 2 simply does not work on mobile, and that makes us particularly uncomfortable when we have no way to improve the platform ourselves.
The CocoonJS plugin has been a fiasco. They did an update a while back that broke everything. I asked them for a list of breaking changes, or anything that could point us in the direction of updating our old code to work the same with the new APIs. They were unable to provide any guidance at all - presumably they'd gone ahead making loads of breaking changes without keeping any record of what had changed. I did not think it was reasonable for us to support the plugin in the face of that, especially when it's their API which they know better anyway, so I told them to maintain the plugin. Eventually they released a broken open source plugin. It's broken because (presumably having not read our SDK documentation) they changed a bunch of the action/condition/expression IDs, but kept the plugin ID the same. Now we are hosed: we cannot simply drop in the new plugin, because it will break every project that uses the old plugin; if we leave it, it stays incompatible with the new plugin. We have always worked hard over the years to maintain high standards of backwards compatibility (despite several internal changes, projects in very old releases of C2 continue to open in new ones - it's transparent and you never know it happens, because we do it well). If we are ever forced to change anything in a backwards-incompatible way, we note it clearly in our changelogs with advice on how to update projects. In comparison this is ridiculous. There is nothing we can do without breaking things. This is why we have still not updated the plugin that ships with C2; we'd rather leave users to opt-in to a different and incompatible version of the plugin, so it's not down to us if things are broken. I also take the fact they open sourced it "for community development" as a sign they're not really actually interested in supporting it.
I'd point out Crosswalk is based on Chrome, which from extensive testing is definitely currently the best mobile browser and the fastest improving, too. GPU blacklisting is a big problem and is largely to do with the poor quality of graphics drivers on Android, which is difficult to work around: you can turn it off, but then you are at the mercy of crappy drivers, which might crash on startup or severely glitch the game (something it sounds like CocoonJS is also affected by). It's a tough pill to swallow, but it might be worth considering the utility of the GPU blacklist: it provides something which might be slow, but works where it may not otherwise work at all, and it does not affect newer devices with better drivers which can stay high-performance. Android drivers have also significantly improved - I think most new devices fully support GPU-accelerated WebGL, so blacklisted drivers should fade away over time.
Ejecta is also a non-browser engine and has a few limitations, but not so many as CocoonJS, we can fix bugs ourselves since it's open source, and it's also guaranteed to always be free even for commercial use. PhoneGap for iOS 8 will be even better, since it will provide a real JIT-compiled GPU-accelerated browser engine in the web view, solving many of the limitations above. I also believe it is the only way to get JIT-compiled Javascript code in a native app on iOS, which can double or even triple Javascript logic performance, so it will likely far outperform any other iOS exporter. iOS versions achieve high marketshare quickly: iOS 7 reached nearly 75% marketshare in less than three months after release (source). Given how far and away better an export option it will be, I think it's well worth jumping on that. I would also want to similarly deprecate the Ejecta exporter at some point, to encourage use of PhoneGap.
The PhoneGap Build service does charge a small fee for building more than one app - if you don't want to pay, you can install the development environments locally and build for free, but it's a real pain in the ass (hundreds of megabytes of downloads and installations of SDKs, drivers and IDEs, often to cover just one platform). You can do that if you like and not pay anything, but IMO PhoneGap Build is so elegantly simple in comparison it's well worth it, particularly for a non-technical oriented audience, which is why we have a focus on that particular part of PhoneGap. Also in the long term, Android L+ is as good with PhoneGap as iOS 8 is, and does away with the Crosswalk filesize overhead. The only difference is that Android versions tend to take a lot longer to reach majority share. But we will get there eventually, and it's always up to you as the authors to decide when it's a satisfactory time to publish for Android L+ only or keep relying on Crosswalk/something else.
Overall we're not out to stop existing users with existing CocoonJS projects from being able to do anything. Our intent is to hide it by default to stop new users trying it first and finding it's full of problems which they then come and complain to us about. It is particularly uncomfortable for us when we can't fix problems ourselves (as we can with Ejecta) and the developers show no interest - or inability - to fix them. I am convinced Crosswalk and PhoneGap are far better solutions to pursue. We also want to encourage more users to try them out so we can get everything working smoothly. I occasionally read about problems with Crosswalk or Ejecta, but we have no open bug reports on them, so it appeared they were working well. If you run in to issues please report bugs and follow all the guidelines and we can investigate - if nobody reports anything then we can't make improvements. Our own tests have so far been working very well on all of Crosswalk, Ejecta and PhoneGap iOS 8+. We will also be looking in to IAP and ad support for Crosswalk/PhoneGap for the next beta.
Hopefully that helps outline our position right now. This was not a snap decision, nor is it personal, nor is it unwarranted in my opinion. I think this short-term pain will lead us on to much more robust, reliable and performant mobile publishing solutions.