Google’s ARC Now Runs Android Apps on Chrome OS, Windows, Mac, and Linux | Hacker News Reader

Google’s ARC Now Runs Android Apps on Chrome OS, Windows, Mac, and Linux

arstechnica.com

350 pointsismavis132 comments

I've had the opportunity to work with this project and it does deliver. In terms of code portability it's pretty good. Small changes had to be done to accommodate some yet to be supported APIs. No big deal though. The performance is good. Even on the low end chromebook I test with. Myonly concern is related to how the (my) codebase might need to evolve over time to adapt to ARC updates. Right now it's pretty sane with only a handful of extra settings on the manifest file. But I worry about being forced into forking. Having two similar but slightly different codebase for the same app is silly.

The overall experience with the Google team has been very positive. Which, in all honesty, surprised me. I was expecting the typical corporate attitude towards outsiders. The way the ARC team has gone above and beyond to help has been refreshing.

I do worry as to how this would affect the openness of the web. A closed source container used to run other closed sourced clients is not my idea of how the Web should be. Even Mozilla is going down this route with their browser apps. Though I have more trust in Mozilla than in Google in regards to having and keeping an open web. Either way, it raises an important question: Where is the Web going in the next 10 years? I wish I knew. Right now it looks like a toss up.

Just curious: What is your app? Is it available on Chrome web store?

I cannot divulge such information at this moment, sorry.

Everything involved in Firefox OS and their web apps is open as far as I know, what are you thinking of when you say they're going down the 'closed source container / clients' route?

My point is more towards Chrome/Google. I mentioned Mozilla with regards to firefox the Web browser and not firefox os. The latter does excite my interest and has me dying to get my hands on a device to tinker with and build apps. Even if it's with javascript. :)

> Even Mozilla is going down this route with their browser apps.

Why are you saying that?

What Mozilla is doing is to develop web APIs needed for those apps and then push for their standardization, but all the apps listed in the Firefox Marketplace are just web apps, having no problem in running in other browsers (assuming they don't rely on APIs that haven't been standardized yet). Google is also doing this with Chrome on Android, as they've also been pushing for certain standards to be adopted that would benefit apps.

Of course, I also worry about ARC or NaCL or Dart (what's with Google these days?), however the work that Mozilla and Google are doing on those web APIs meant for apps is really not the same thing.

> Of course, I also worry about ARC or NaCL or Dart (what's with Google these days?)

That's fairly typical of Google to have 2 or more of everything. Inbox and Gmail, Chromebooks and Android are prime examples.

Ars Technica has a write-up on it that lists more: http://arstechnica.com/business/2014/10/googles-product-stra...

Just for the record, ARC is a runtime you statically link to in your NaCl app (not an alternative core Chrome feature).

Huh that's interesting. I haven't looked much into ARC (or NaCL for that matter), I just wanted to point out to the parent that it's fairly typical for Google to go down multiple paths for a specific market need. They're kind of the anti-Apple in that regard.

Good points. My worries are more directed towards the browser becoming a second OS and moving towards client apps. I guess I'm old school and am still tied to good old html.

> Having two similar but slightly different codebase for the same app is silly. isn't that what flavors are for ?

This is absolutely huge and I think some people may be missing its significance.

Back in the 90's Windows had a huge monopoly due to network effects - developers would target Windows because it had the greatest number of potential users. But now they will target Android for the same reason because it can run on Windows, Mac, ChromeOS and Android smartphones.

This "Android First" model will affect several major areas, all in Google's favour:

1. It strengthens ChromeOS over Windows.

ChromeOS is already a strong player in the education and low-price sectors. Having a huge range of Android apps will make ChromeOS far more attractive and grow its market share. Moreover if corporate, boring-office-CRUD developers switch to an Android-first model then it will very quickly kill Windows.

2. It strengthens Chrome over Firefox and IE.

Many apps will now require the Chrome browser to run. Oh, you are running Firefox on Windows and want to play that cool Android game your friend told you about? Just switch to Chrome and sign in with your Google account! Again there are network effects - the greater Chrome's market share the more willing developers are to create Chrome-only apps.

3. It strengthens Android over iOS.

Android has about 85% of smartphone market share, but many startups are still undecided about an Android-first approach because a single Apple user generates far more revenue than a single Android user. Having Android run on desktops will push some startups off the fence in favour of Android-first. A few developers switching from iOS to Android doesn't sound like much, but if there are a ever a critical mass of Android-only apps it will quickly kill iOS. Apple should be worried.

4. It strengthens Native over Web-app development.

Ok this isn't a huge benefit for Google, but it is significant for developers. Back in 2005 every startup chose browser-based web apps as their target platform. The rise of smartphones has pushed the pendulum back towards native development, but desktops have remained the preserve of web apps. Many startups now develop both a Web App and Android version of their product - by dumping Web App development startups will now be able to (a) save costs; (b) produce a desktop app that has native performance and better access to Google Play Services.

It's certainly a fascinating piece of tech and a very politically intriguing play by Google, but I don't see it suddenly changing the calculus of app development. Here's why: the set of apps that I run on my phone are disjoint from the set of apps that I run on my laptop or desktop. My laptop doesn't need a flashlight, or turn-by-turn navigation, or the ability to hail a cab, because I don't have it out or open or even with me when I do the things that need these apps. My phone doesn't need Photoshop or Notepad++ because the form factor doesn't favor it. Write-once-run-everywhere isn't a selling point for your app because I don't actually want to run it everywhere.

The one exception could be games, which are a lucrative market. That said, mobile games will offer a limited set of interactions compared to typical PC offerings, which will limit appeal to people who are already playing mobile games but who wish to play those games on their desktop as well. It will increase time spent in the app, but not grow the market substantially relative to new users coming in from mobile devices. And because it requires a browser anyway and because ARC is never going to run on iOS, if the web can advance fast enough to keep the market satisfied (asm.js is a start, but payment is still horribly lacking) then there will be pressure to just do everything on the web anyway.

Interesting times are in store, regardless.

I think you may be underestimating the overlap between smartphone and desktop functionality. Take a look at the home screen of your smartphone - what percentage of those apps are also available as a web app? For me that figure is about 80%.

Amusingly, for me, there's exactly one app with a web equivalent that's not a preinstalled Google app (a weather app). The rest all are either doing things with hardware that the web doesn't know how to access (accelerometer, microphone, camera, FM radio, SMS, cell, raw network access), or apps for managing data on the phone itself (contacts, image gallery), or services with no web equivalent (Steam, Lyft).

And that's just the thing: if your app can be done on the web, you're already going to do it on the web, because there's not a platform on the planet that won't automatically have it. If the website that you already have doesn't perform well enough, then you make a second app while you wait for the web to reach parity.

You're going to think I'm weird, but I don't use the Facebook app, I use the site. I don't use the Twitter app, I use the site. This isn't some philosophical choice on my part, I really just can't be arsed to take the effort to search for yet another app on the app store, and then fret over the implications of approving yet another set of meaningless permissions, and then resign myself to endure yet another app pestering me to update it for the rest of my days.

I accept that there will always be a place for native apps. The web is slow to pick up on new bits of hardware and new modes of interaction, so native will always be ahead of the pack there (though Mozilla is at least attempting to prepare itself for the Oculus Rift with a big push for VR on the web). It's a conservative platform. But once something is Good Enough for the web, you need a very good reason to dislodge it.

We are clearly polar opposites because I love native apps ;) For example you might think The Economist was perfectly suited to a browser web 'app', but I prefer the native Android app because (a) it notifies me when a new issue is published; (b) it downloads the content offline; (c) it is fast to navigate and has smooth animations between pages.

I think we've been talking about two separate issues:

1. Do a significant proportion of apps need to provide the same functionality on both a smartphone and on desktop computers? Here I think the answer is yes. Twitter, Gmail, weather apps, maps, image gallery, music streaming, games, banking apps, youtube, etc. provide essentially the same feature set on both devices.

2. If an app needs to run on both smartphone and desktop, should it be native or a web app? Here I think the answer is not so clear-cut. Certainly in the past 15 years it was true that "if your app can be done on the web, you're already going to do it on the web, because there's not a platform on the planet that won't automatically have it". But will that still be the case in 5 years time? The choice of platform for a new app depends on more than just the potential number of users - the usability and development cost also matter. Let's say I expect to produce a web app, an iOS app and an Android app - is it really worth the extra cost to produce the web app if I can cover 95% of the potential user base without it?

  > But will that still be the case in 5 years time?

By 2020 I don't expect any new platform to arise that both lacks a standards-compliant web browser and manages to enforce the lack of such a web browser. I also don't expect any existing platform's browsers to regress from the degree of standards compliance that they have at this moment. There do exist several scenarios whereby web standards could stagnate over this time period:

Scenario 1: A major platform allows only a single browser, that browser being produced by the platform's parent company, and drags its feet in order to impede the standards process and promote native app development over web app development. The obvious potential candidate here is iOS, with Safari being the last major browser that has yet to commit to an "evergreen" model whereby features are quickly and regularly released. However, if ARC were to ever pose a threat to Apple's app model such that they could not somehow counter it with crippling technical constraints, it would be in their best interest to rapidly advance Safari to feature parity with other browsers. In other words, if Apple were ever faced with the decision of empowering the web vs. tacitly empowering a platform backed solely by Google, they're always going to choose the web.

Scenario 2: Chrome becomes dominant to the same degree that IE6 was once dominant. At this point anything that Google decides to implement (or to not implement) would de facto determine web standards, and just like Microsoft of old they could choose to leverage this power in order to advance a proprietary platform under their exclusive control. This is largely kept in check by Chrome's inability to exist on iOS as anything other than a thin wrapper over Safari, a situation that is unlikely to ever change (at least, I don't see any business motive to Apple making such a thing possible).

Scenario 3: Mozilla somehow loses its seat at the standards table. In the short term it may seem like Firefox can be ignored to a degree, but in the long term Mozilla is the Bismarck that keeps web standards moving forward in ways that are seen as beneficial to a majority of the vendors at the table. As long as there exist platforms with sizable userbases on which Firefox can be installed, it is in Mozilla's interest to advance the web as quickly as possible while convincing two of the big three to play along in order to undermine the remaining mutual competitor (and hence indirectly gaining an influence over that competitor's closed platform, using the browser as an attack vector). Mozilla's recent contract with Yahoo will sustain their efforts at their current levels for at least another five years, but its fate beyond that time will depend on how well FirefoxOS does at keeping Firefox from being locked out of the increasingly closed platforms of the future.

Given all of the above, I think it's safe to say that the web will continue to evolve rapidly for at least another five years, and the inexorable advance of mobile hardware will continue to close the gap between native performance and web performance (with projects like Mozilla's Servo designed to accelerate the closing of this gap). In the meantime, the biggest hurdles are the process of web app development (sorely lacking compared to native development, though there appear to be tentative steps in the right direction) and the unanswered question of how to make payment on the web as frictionless as it is on mobile (seriously, someone start working on this).

Yes the three scenarios you mention are unlikely, and I agree that the web will continue to evolve rapidly for at least another five years. But isn't it possible for web apps continue to close the performance gap yet still lose their dominance as the 'first choice' for startup development?

For example, perhaps Google will make it much easier to port an Android app to iOS, similar to the way SWT makes it easy to write a single app that uses native controls on both Mac and Windows.

This Android+iOS app could then run on Windows, Mac, ChromeOS, Linux, Android, and iOS. Suppose that the cost of developing such an app is roughly equal to the cost of developing a web app. Wouldn't startups be tempted to choose this platform over a web app?

As you say, there's a class of apps that works best on a phone and another that works best on a laptop. But there's also a class of apps that you'd want to run everywhere, for example all the addictive social media apps. For these it becomes more of your preference between touch vs point and click interfaces. This is what Windows has been trying to do, offering both paradigms in one device. I've talked to people with these Window devices who will switch between using the full-screen/touch and the windowed/mouse version of the same app based on their context. It's nice to have the options.

I've done a fair bit of HTML5 game development for Mobile. And it's really tricky to get Mobile-first games to be fun on Desktop. All my games run on Desktop, but things like Flappy Bird just don't get much playtime on Desktop, it's popular because they're played in 'throwaway-time' on the bus, or in a bar when your friend is waiting in line to buy some drinks. A lot of mobile gaming is like that.

Which is why we don't see a ton of HTML5 games on desktop. Expectations for desktop games are far higher nowadays. If you're competing with a household-gaming experience (i.e. desktop games are generally played on your home computer), we're talking about competition like World of Warcraft, League of Legends, shooters, RPGs, or indeed big budget console games.

And seeing as any of these games can also run on your phone, and seeing as most gamers have phones nowadays, and seeing as your phone gives you a touch-screen experience around which the gameplay is built (e.g. swipe to throw a basket ball), you might as well play on your phone.

There are some exceptions, but not many. At the end of the day though, if the mobile game runs on your phone and desktop, you'll play it on your phone. If the game has a mobile version and a desktop version, and the mobile also runs on your desktop, you'll play the desktop version instead on your desktop. Mobile games on desktop is likely a relatively small market.

Of course this entire thing will shift slowly once you can run mobile games on your desktop. But it won't be a gigantic thing overnight. It's years away.

And considering I fully agree with all your points (Flashlight, nav, cab, Photoshop and Notepad++ are excellent examples of the divide) I think it'll take quite a bit of time before things take a big turn.

It kind of feels like the early Android tablet days. When the tablet app store offered just blown up phone apps. This is going to be that, but even more blown up, and much less finetuned to the mobile form factor. (e.g. things like swipe based UI just doesn't fly.) Of course it was clear that one day developers would build apps that'd adjust to both phones and tablets perfectly, but it took some time and it's still not quite there yet. This will be similar but I think it'll take a little longer, as it's not just a resolution-difference, but also requires developers to build multiple control systems (like swipe). The entire fat-finger vs precise-mouse driven UI/UX divide now needs to converge and it takes time.

In any case, the latest announcement of touch-screen Chromebooks makes a lot more sense now.

> The entire fat-finger vs precise-mouse driven UI/UX divide now needs to converge and it takes time.

I have to wonder if this is why Google decided to implement Pointer Events.

Is there a good place to find good html5 desktop games (non-demos, full games)? I know they exist but I have a hard time tracking them down.

Not really for the above mentioned reasons.

HTML5 desktop games barely exist. If you build a game for desktop you usually just build a native game, because trying to build World of Warcraft or GTA in a browser makes little sense. And if you do build for the browser, it's usually small-mid games where Flash is still king, despite the fact it's dying.

Desktop HTML5 games are afaik 90% mobile HTML5 games that obviously also run on Desktop, but to call 'em desktop games would be too generous because they're built for crappy mobiles running Android 2.3 browsers where even playing a simple sound when you press 'start game' is a big deal because you have a few megabytes of memory to work with. A lot of these games cater to e.g. 40 year old house moms who want to play Candy Crush type games but outside of the App Stores that are marketing black boxes.

Big publishers in this scene are e.g. Spil Games or BoosterMedia.

For example, Zibbo is one of SpilGames' brands. You'll find mobile-first games like these: http://www.zibbo.com/game/Monsterland-Junior-vs-Senior?featu...

Beyond that, there are a few developers who build cool HTML5 games usually as a way to get you to download their native app. It allows them to put these games on any desktop gaming portal, the Facebook canvas etc, and get eyeballs, and then after 5 levels say 'download the native app for more'. But even then devs often go with Flash as it's got such a huge community of developers with lots of expertise, and with Flash dying, it's cheap to hire.

For example, I think Kingdom Rush, a pretty cool and fun native tower defender app on mobile had an HTML5 version in the Chrome store, basically as an extra channel to advertise their mobile app. Not completely sure though.

Mozilla built BrowserQuest: http://browserquest.mozilla.org/

Which was pretty cool. Not really fun, but an interesting demonstration of the tech, which is what they built it for.

There's a pretty sizeable indie scene with games like these in HTML5: http://godswillbewatching.clay.io/game/godswillbewatching

Again these are mostly just desktop games that got an export-to-html5 version, though. A lot of the entry level game dev tools like GameMaker or Scirra seem to have built a big HTML5 engine which allows them to offer their users an export to iOS and Android apps by wrapping them with tech like cordova, without having to mess with Objective C or Java or anything. So for a lot of indie game devs that use this type of software they can export to HTML5 as an afterthought and upload it.

Don't know of big HTML5 game repos other than the mobile-first publishers (SpilGames, BoosterMedia, Keygames, Admeen, Pakap etc etc). There are some HTML5 game repos but they're full of crap.

Thing with HTML5 is, it's not a user-demanded tech. It's a developer tech for people who want '1 codebase, all platforms that have a browser', i.e. TVs, phones, tablets, PCs, consoles. No user is actually interested in playing HTML5 games, it has no known benefit to them, so it's never advertised as such and so there's no real stores built around it.

Sorry can't help you much more.

Isn't there something in between weekend-project demo games that you master in 5 minutes and AAA games with million dollar budgets? Also I disagree with this:

> Thing with HTML5 is, it's not a user-demanded tech. It's a developer tech for people who want '1 codebase, all platforms that have a browser', i.e. TVs, phones, tablets, PCs, consoles. No user is actually interested in playing HTML5 games, it has no known benefit to them, so it's never advertised as such and so there's no real stores built around it.

I'm a user and I want it. The ability to play a game on any computer without installing Steam and then installing the game and then setting up a controller and etc. etc. is a huge win for users.

I understand that browsers aren't ready for AAA FPS games (or at least the makers aren't ready to put the effort into html5 export) and I'm fine with that, but I think there's something in between, like a Super Meat Boy that is still a full-fledged game and can easily work in browsers.

I'm just surprised that there are virtually none of these out there.

That's a nice analysis! I'm also into browser games. But just started with "HTML5". The reason is that it takes time to invest in new technology. "HTML5" is bleeding edge and new features are still added. WebGL is not yet fully supported on the major browsers and Canvas just got hardware acceleration a year ago. Also Websockets got scandalized just months ago. Flash on the other hand, is mature, so it will live on at least a few more years as a lot of developers are still developing in it.

I think Google deliberately slowed down "HTML5" in favor for their Android ecosystem. Witch was a stupid idea since most of their money still comes from WWW.

The money is still in WWW! The the problem is that a native app runs much better then a web app on Android. Even Facebook made a native app!!

With Chrome-OS and Firefox-OS on mobiles we might be able to reduce the gap between native and web on mobiles.

Native is still king on desktop though and I do not think AAA-studios will develop for the web anytime soon. There are some studios (Zynga, King) making shit-loads of money from crappy web-games though, so I think we will see more in between crap and AAA on the web soon. And hopefully without plugins!!!

> ARC is never going to run on iOS

I don't see why the same applications couldn't be compiled to run on iOS, like unity or AIR for example.

I could certainly be wrong! That said, I don't see Google themselves really committing to such an effort (there are definitely business incentives to do it, but it sounds like a terrible technical burden). There could be third-party products that make it happen, but from my experience they would likely either be expensive or result in a janky product (or both).

I have to admit that this is a brilliant move by Google. In one sweep, they have put the might of the formidable Android ecosystem behind ChromeOS. Well done. Chrome OS is instantly comparable to Linux and Windows if it can run native apps.

Chrome OS has been able to run native apps via NACL for a while. This just makes porting automagic for a certain category of apps (Android).

It remains to be seen if more Chrome OS devices will come with touch screens or if app developers will modify their apps to work well without them.

> Chrome OS is instantly comparable to Linux and Windows if it can run native apps.

Windows and Linux have many, many more applications that are meant for trackpad-and-keyboard-with-'large'-screen interaction. Adding phone and tablet apps to ChromeOS doesn't make it instantly comparable to Linux and Windows.

"One sweep" and "instantly" are flamboyant at best. There is a long way to go before running android apps on desktops is the norm. Sure, some run Android emulators but its for special cases.

This seems technologically awesome, but I don't really know how useful this will be presently to everyday people. I can't really think of any Android apps people would want to run on their computer.

Consider the inverse situation. I can now write PC apps which will run on your Android.

I would love to be able to continuous most apps on my computer once I am using one, instead of picking up the phone and drain its battery. Running the apps on computer is the first step.

That's because in most cases the app functionality is duplicated on the desktop, either as a web app or native desktop app. On my phone for example such apps include Gmail, Skype, Kindle, The Economist, Google Calendar, YouTube, my banking app, Facebook, Spotify, Photos, Maps.

But in future the simplest way for a developer to provide the same functionality on both desktop and Android smartphone will be to create a single Android app.

> Chrome OS is instantly comparable to Linux and Windows if it can run native apps.

Oh, because if you add an OS made for touch/small screens on a notebook equipped with a keyboard, that immediately makes it as good as regular desktop OS ?

Android apps typically work quite well windowed, and given that Android tablet netbooks were a thing for a while: http://www.asus.com/uk/Tablets/Eee_Pad_Transformer_TF101/ you'd be surprised how good they can be.

It's been possible to run Android apps on Chrome for a while now, and my experience was that they're terrible for the most part. Cryptic icon buttons with no tooltips and reliance on gestures like swiping in from edges does not make for quality desktop software.

http://lifehacker.com/how-to-run-android-apps-inside-chrome-...

If those are the biggest complaints you have those will be easily solved.

Well let's be clear on one thing, what's the benefit of a desktop over mobile? Usually we say productivity.

Editing photos, video, text, is all less productive, slower, less capable, more superficial on mobile. Adding an instagram filter is kind of iconic for mobile's productivity factor in my opinion.

So is ChromeOS suddenly comparable to desktops if it can run mobile-productivity software? Of course not. Far from it.

This may change as we're seeing mobile/laptop blur a bit (iPad Pro with force touch, a stylus and USB ports for externals, 12" Macbook with Intel Core M processor, for example. Or any of the 2-in-1s, the MS Surface etc). Once we see Mobile software running on Laptops, and see Tablets equipped with a keyboard/stylus, converging around the 11" form factor, with ever improving mobile chips, then we'll probably see more 'real' productivity software.

But it's a bit too soon to call ChromeOS comparable all of a sudden. It's a great move, though. I remember you couldn't/can't even run Skype on ChromeOS. Soon, stuff like that will be of the past, without requiring massive Tizen-like investments to have developers completely rebuild a hundred thousand mid-high quality apps for your store.

VLC is coming to Chrome OS soon thanks to ARC. Anandtech has tried out the beta version and it is coming along nicely. http://www.anandtech.com/show/9082/the-chromebook-pixel-2015...

Here's hoping this is eventually gets made into a standalone library or program that can be run without Chrome. Don't get me wrong, Chrome definitely has some benefits over other browsers, but I don't want to have to have it to use this and I definitely don't want to have to run a browser to use apps.

There are already standalone Android runtimes to run apps as is on your computer without Chrome. See BlueStacks[1]

[1]http://www.bluestacks.com/

Bluestacks is an emulator running the Android OS under Windows, not an integration of the Android runtime with Windows. The latter is possible, but it would take quite a bit more work. Whereas ARC really is an Android runtime, separated from the Android OS, and ported to other OSs.

And that library would be Chrome. Which is to say, whether or not you ship a web browser UX, you need 95%+ of Chrome to run NaCl/PPAPI apps, which this Android virtualization layer targets.

Really, Chrome itself isn't so much a web browser any more. I swear, at some point they're going to let you generate seeming-OS-native-binaries from Chrome Apps which will then bootstrap themselves by silent-installing Chrome—but only the "app launcher" part, not the "web browser" part. At that point, Chrome will be a capital-P-Platform: exactly the same as Silverlight/Adobe Air/etc.

> At that point, Chrome will be a capital-P-Platform: exactly the same as Silverlight/Adobe Air/etc.

Or Flash, or Java...and look how well things have worked out for all those "write once, run anywhere" client app platforms!

Flash was very successful as a client app platform, and Chrome has clearly avoided Java's client-side failure mode already.

Which goes to show. In hindsight Adobe shoulda built their own browser or forked Firefox or bought Opera...

No, they should have gotten flash to run really good on mobile, crappy or no flash on mobile was the downfall of flash.

True. Hadn't thought of that. Or done both.

Chrome Apps outside the browser were demonstrated a couple of years ago¹; but I'm not sure if it's in their interest to be so silent installing Chrome.

It's interesting that what you're describing is actually been done by Mozilla, when they separated XULRunner from Firefox. A few apps already use it², including Google's own Analytics Editor, but it needs to be way more polished to make it attractive to the general app developers.

¹ http://www.youtube.com/watch?feature=player_detailpage&v=j8o...

² http://en.m.wikipedia.org/wiki/XULRunner#Uses

Coming from OSX development, I read this as "Google's Automatic Reference Counting" and was thinking that it would be pretty sweet.

I read it as ART, which would be insanely great as well.

I'm working on bringing ART to OSX, see https://github.com/DmitrySkiba/ARTPart

I thought it was a caching mechanism for a moment (ZFS).

That would probably be very sweet indeed :) . Android's GC is constantly improving but I just don't know if it will hit the point where it is entirely invisible for a reasonably coded app (ie if you create heavy objects during each onDraw cycle, it is your fault and would result in shitty performances with any OS). ARC sounds like an interesting way to do GC. From my limited understanding, the reference counting adds a non-null cost but it looks like a good trade-in against unpredictable GC pauses.

"ARC runs Windows, Mac, Linux, and Chrome OS thanks to Native Client (abbreviated "NaCL"). NaCL is a Chrome sandboxing technology that allows Chrome apps and plugins to run at "near native" speeds"

Straight out of the MS playbook, 'lets use our dominant browser as a pincer move to gain developer/market share'.

But since it's Google everyone jumps and says yes!

On the one hand this is really awesome because by opening ChromeOS up to Android apps it becomes much more useful.

The other side of the medal is that this might slow down progress on the open web-platform as developers would rather develop a native android app than put effort to make a web-app.

It somehow funny: Recent developments around the web platform (service workers, etc) are supposed to make web-apps compete with native apps and even Microsoft is starting to embrace this (web based skype). At the same time now native apps run in the web. It will be interesting how to this will evolve.

It also shows why Google developed NaCL and that it doesn't really matter that it hasn't been adopted by other browsers. Because its main use case is for ChromeOS.

So we have come full circle in circa 5 years.

We now have a development platform for desktop quality apps in a proprietary format that run via a plugin in the web and in a runtime on desktop.

The only missing link is publishing the plugin so other browsers can run the apps, oh and renaming it to Flash.

Sigh. We need this going the other way around; that is, our mobile devices supporting web-apps, instead of our browsers supporting mobile apps.

ARC is going to be the next Flash(TM). And now developers still have to target multiple platforms (web, android, ios), instead of just the web.

What mobile browser doesn't support web apps? They may not support proprietary app stores and the nonstandard "web" (but not really) apps tied to them, but actual web apps are generally supported on major mobile browsers.

The only issue is having a unified design system that is optimized for larger-screen, mouse and keyboard devices.

Just when I thought I'd rid myself of Java...

Oh don't worry, Dalvik/ART is completely different from Java, at least for legal purposes.

Neither run Java bytecode. They happen to have Java semantics. But they are one (Dalvik) or two (ART) steps removed. Once your Android toolchain has produced Java bytecode, it is translated to Dalvik bytecode before being packaged. Then it might, or might not (pre-ART systems), get translated to native code before being run. And, depending again on version, might get JIT compiled, or not.

Once can take advantage of this in interesting ways. If you are Myriad and you have a Java(tm) runtime for mobile devices, you can skip (or reverse) the Dalvik bytecode translation and run Android apps in your runtime. At which point Oracle sues your ass, and the settlement is confidential. You can see this approach at work in the Jolla handset.

I think that in the medium/long run google will, at least, add a new language officially supported and a bit more modern that the pseudo-java5 they are using right now. I mean something like what apple made with swift. Also considering google is already working on Go and Dart, there could be already something in preparation related to them.

I hope they go with C#.

April Fools!

The CLR would be a pretty good universal runtime, to be honest. It's open source under a liberal license, so you don't have to worry about the copyright dickery that Oracle. It has a lot of modern language features, like closures, with syntax that doesn't want to make one punch kittens. Plus, it has things that go beyond a lot of languages, like having the compiler classes in all versions of the runtime, so you can extend your app as it's running. There are very few frameworks out there that give even a few of those features.

But nobody at Google writes C#. I think you're much more likely to see Go (or Python) where Google designed much of the toolchain.

Jon Skeet, highest rated user on staklckoverflow, is a C# expert and he works for Google UK. I remember reading somewhere that parts of teams in Google's London offices are Microsoft technology driven.

He is not writing C# at Google.

That said, sure, there ARE people writing some C#. Google has applications that run on Windows. But very very few people are writing C#.

The CLR has actually been open sourced under an extremely restrictive license[1]. It does not allow any modification or derivative works that are not part of the .NET runtime or a .NET app, or changes that make the platform non-conforming to the spec. The license is so restrictive that it probably even fails to meet the minimum criteria set forth by the OSI for being called "open source" (as it only allows grants very limited modification and derivation rights).

Remember the great lengths Google went to avoid the OpenJDK's GPL license (which, BTW, is a plain-and-simple open source license, with its implicit, unrestricted patent grant); this one is a lot more restrictive (and dangerous).

[1]: http://www.ifross.org/artikel/4-shifty-details-about-microso...

This is inaccurate. The CLR has been released under the MIT, a permissive non-copyleft license that has been certified by the OSI. Microsoft has a separate patent grant that the article takes issue with, but the source itself is open.

The source itself is not "open" (though it is available for you to read), neither is it under the MIT license.

To meet the minimum requirements for open source, the copyright holder must grant you permission to modify the source and create derivative works. Microsoft most certainly does not grant you those permissions.

The MIT license implicitly grants you patent-use permissions; MS has taken those permissions away, hence this is not the MIT license, but an MIT licensed that has been ammended (so much so that it is perhaps no longer open source at all).

You can read DannyBee's comments here for clarification and a more thorough and precise discussion: https://news.ycombinator.com/item?id=9111849 (he's an open source lawyer).

What you are saying contradicts what is posted here:

https://github.com/Microsoft/dotnet

".NET open source projects typically use either the MIT or Apache 2 licenses for code. Some projects license documentation and other forms of content under Creative Commons Attribution 4.0. See specific projects to understand the license used."

Well, they "use" the licenses and then amend them considerably (those licenses grant you patent use permissions, while Microsoft doesn't). The licenses are still there, only with a nice juicy amendment on the side, which basically says: "You know all those permissions granted to you by the license? Well, were taking most of them away now, thank you".

The legal instrument by which those permissions are taken away is patents, which is actually worse than copyright because patents are sneaky. See those DannyBee comments I linked to for an explanation.

In any case, Facebook does something similar with React which also "uses" the BSD license, except not really, which is why Google, for example, have already said they can't use Facebook's open-source projects.

Facebook keeps the project open source, except adds an unrelated auto-destruct mechanism; the CLR isn't even really open source (because you don't have permission to freely modify the code or derive from it). I don't know which is worse...

The DannyBee comments you linked are entirely about Facebook, React and the BSD license. They are not about Microsoft, the CLR and the MIT license.

At any rate -- the MIT license for CLR is not amended. The patent grant is separate from, not an amendment to, the MIT license.

Amendments are often separate. But call it what you like, the MIT license includes an unconditional (implicit) patent grant, which MS takes away.

Microsoft's patent promise does not override the MIT license. Whether or not the MIT license implies a patent grant is an open question not yet tested in court. If that unconditional (implicit) patent grant succeeds in court then Microsoft's patent promise is unnecessary. If that fails in court, then the patent promise protects compatible implementations (like Mono).

IANAL, but DannyBee is, and he says (re. Facebook and a BSD license, but it's the same thing):

This grants an implied patent license to the patents necessary to actually do this, as long as you meet the restrictions... This is actually well-settled law. You don't get to give people stuff unrestricted, and say "you can use this for free", and then say "just kidding, what i meant was, you can use this for free as long as you pay me for the patents"

However, when you do what facebook has done, and give an explicit license, you have overwritten the terms of that implied license, and you get no implied license. So it is not only "not unambiguously safer", you are not "left with the same rights you had under the bsd license if it is revoked". This is because if you revoke the explicit grant, you get nothing in terms of patents. But the implicit grant is not revokable unless you violate the copyright license.

most engineers are not familiar with implied patent licenses. BSD normally carries one. So you do in fact, get a implied grant. By doing this [i.e. have an explicit patent grant] you don't, you only get the explicit grant. The implied grant is normally not revocable unless the underlying BSD terms are violated, whereas the explicit grant is revocable for other reasons.

To summarize, it is well-settled law that an open source license carries a patent grant, unless that grant is restricted by an explicit one (which supersedes the implicit grant as it amends the license). The restrictive MS patent grant is therefore not in addition to, but instead of the implicit promise.

It seems like Google's legal department is also under the impression that this is settled law, as they've said they cannot use React and other open source Facebook projects because they contain a restricted, explicit patent grant, while they do use projects without them.

You forgot to quote this part:

> The reason people use explicit patent grants is to avoid getting into some unsettled law. Particularly, the sublicensability of implied patent licenses is not clear. The TL;DR of this is "the answer is clear if you get the software directly from person owning the patents. If you get it through someone else, like say, a linux distribution, it's not clear what happens". The related doctrine of "patent exhaustion" that plays into this is also not settled, and currently the subject of a Supreme Court cert petition by Cisco.

If you read the whole thing, what he's talking about there are licenses, like Apache, that explicitly grant those patents that are only implicitly granted by the MIT and BSD licenses (and even that, he says down the page, does not really solve the sublicensing problem).

But Microsoft's explicit grant does not clarify the grant implicit in the MIT license (as the Apache license does) but restricts it, beyond even the minimum bar for being considered open source.

So, if you ask: "do I have permission to use the CLR source code as I wish, as long as I comply with the MIT license?" the answer is a resounding no, Microsoft does not grant you that permission (true, they might not have the specific patent to go after you, but they might, too, and they don't have to tell you).

For any open source project you can violate a patent completely unrelated to the author and be sued just the same. Heck, Microsoft probably makes money from Android than Google does.

C# (using the Mono VM) actually works inside of Chrome Native Client.

Agreed. Alternatively they could try to poach Anders Hejlsberg, the guy behind C#, and have him make an even better language. Google is big enough to provide the initial push behind it and he has shown that he can repeatably build great tools (Delphi, C#, Typescript).

Kotlin already runs very well on Android, and people seem to love it.

Presumably you could use any language that targets the JVM, since the code could be further compiled down to ARC.

That leaves things like Scala, Kotlin, Grovy, etc.

I've been wanting the android kindle app on Mac for a while. It is so much better than the Mac app.

If this means Microsoft's Office Apps for Android (Word, PowerPoint, Excel, Outlook) come over to Chrome OS and Google manages to integrate them in a nice fashion - Microsoft has one more headache to deal with.

That aside, this will seriously increase the appeal of Chromebooks - who doesn't want a simple, secure platform that can run all the bazillion Android apps? Google just needs to pay some more attention to Chrome OS desktop interface - it is shitty frankly.

Android apps are typically a pretty lame desktop experience. It's the corollary of desktop apps typically being a lame mobile experience.

Currently yes, because so few people are running them on a desktop. There's nothing preventing that from changing other than momentum though, Android is set up to handle varying form factors already, so if someone wanted to create an app which scales from mobile through tablet to desktop they can do so.

Now that there's a supported way to get Android apps running on people's desktops I could see this becoming more of a thing, especially for things like photo and document editing.

"Write once, run everywhere" is the web applications promise. Unfortunately we have a lot of work to do to make web applications comparable to native apps.

"Write once, run anywhere" was Sun's slogan for Java.

Google's following through on that lofty goal in a reasonable way. Assuming one uses their product lines.

Too bad its still Java though :p (with many advances in sandboxing and security), but I guess Google/Android didn't really have much of an option back then and I'm honestly not sure what would be the better choice now.

As long as you didn't need a user interface :-) Back then, you were lucky to get any Applet working without crashing the browser. From what I remember, GD was pretty much the only way to draw anything besides ASCII art. Oh and that Macromedia... shudders

Does "everywhere" include e.g. Firefox? Also, no, you don't have to make web applications comparable to native apps. At all. Just make native.

As a marketer, this allows me to manage social accounts like Instagram and Vine from the desktop env. In fact, we have those two working for our team now:

https://medium.com/@seanmdixon/run-android-apps-in-chrome-78...

If only Apple will open up iOS a bit so Google can port this over...

That could have downsides for both companies.

a) Android becomes the "write once, run anywhere" platform, attracting developers away from native iOS development.

b) Android loses app exclusivity that pulled/locked users into the platform.

b) Android loses app exclusivity that pulled/locked users into the platform.

Was that ever a thing? I can think of apps that had this effect for iOS, but did it ever work in the opposite direction? I got Android because it's less expensive...

Yes. For example, in South Korea, most apps are released for Android first, then maybe iOS, because Android has overwhelmingly more market share compared to iOS.

That's really interesting since in the US it's the opposite: apps are released for iOS and months later an Android version will potentially come out.

I wonder if it has anything to do with the fact Samsung, the most successful Android manufacturer, is in South Korea.

Really? This page claims iPhone market share is 33%, and was even 15% before the release of iPhone 6:

http://blogs.wsj.com/digits/2015/01/20/apples-smartphone-sal...

Yes, really. It is true that iOS share increased after iPhone 6, but Android first/iOS later is an established pattern by now and I guess old habits change slowly.

Just to give an example, Naver (the dominant South Korean internet company) launched Pholar, which is quite similar to Instagram, in March this year. Pholar is currently only available for Android.

Things like Facebook's Chat heads only work fully in Android (basically Messanger chats show up as a floating bubble no matter what app you're in[0])

I also like being able to configure my homescreen and having different keyboards (though the latter's shown up in iOS now)

There's some feature differentiation for sure, though iOS has the advantage on some things (I would kill for fingerprint unlock)

[0] http://www.technobuffalo.com/wp-content/uploads/2013/04/Face...

The Galaxy S5 has a form of fingerprint unlocking: http://www.cnet.com/how-to/a-deep-dive-into-the-galaxy-s5s-s...

I have used both, the iPhone's fingerprint unlocking feels better IMO.

This already exists, it's called AIR. However it's a double edged sword.

The Google page linked from the article does not support the claim that this extends beyond ChromeOS for deployment via the Web Store -- in fact, it repeatedly says the opposite --only that the packaging and testing process works on Mac/Windows/Linux.

To me this seems like a hope and pray response to where Windows is heading with a heterogeneous platform strategy. What people want is high quality robust full featured applications on their mobile devices, not app store quality word processing on their laptop.

I already have all the Gmail and hangouts on my desktop I could ever want. I don't think I'll use the Clojure REPL app in lieu of $> lein repl or the Maps app in lieu of my browser. To a first approximation, apps are better than nothing but I don't see this as a Windows 8 app killer ~ their standard of fit and finish is generally higher.

There's a niche where this will be great but I don't see an app replacing audacity or blender anytime soon.

Hrm. I converted one of my Android apps with ARC welder and uploaded it to the Chrome store but it will only install from there on Chromebooks =( Anyone know how to enable desktop distribution?

Will this support NDK apps? I don't really care about most Android apps -- I'd rather have an HTML version, and the web is a better universal runtime than the Android API for a bunch of reasons -- but it'd be cool to be able to play Android games on a Chromebook.

It does.

I really wonder why it is only Mozilla right now that offers their browser as a tar.gz for Linux use.

Is this the reason that Chrome seems be getting extremely bloated on the desktop? It's like running a ChromeOS VM with every chrome.exe process. I guess it's time to go back to Firefox or try Spartan.

Is there any project under way to translate PNaCl code to asm.js?

Edit: reading further, PNaCl happens to be a subset of LLVM IR. The Emscripten code could probably be repurposed to run NaCl and thus Android apps everywhere.

you're forgetting the API (pepper). There are already Pepper shims for Emscripten but they are unusable.

So where can I see a list of Android apps which I can run on my Mac?

Looking forward to porting my FOSS newsreader over. Nice work, this.

Are there any code changes necessary to get your app to work on this? When I run my APK I just get a white screen with the app logo in the center.

Java's Write once Run Anywhere is live in spite of Sun's Failure. I just hope Oracle makes up with Google for Java's Sake.

Google is the only reason Java is not a dying Language.

Have you ever worked for boring, enterprisey companies? Java is everywhere, sadly.

Yep, like

Yahoo! (search, infra),

LinkedIN,

Twitter,

NetFlix,

Square,

RelateIQ (startup, bought by Salesforce),

Salesforce (itself),

Google,

RedHat,

Facebook (I'm sure there are a few teams that have to use Java),

Yammer,

the list goes on and on and on...

To be fair, the list of companies using COBOL is also long.

I've been writing a lot of Go lately and this makes me pretty excited. The Go developers have put some effort in to getting Go working well on Android, with accompanying OpenGL related libraries[0]. If those apps really do work well on desktops now that'd be great.

[0]: https://godoc.org/golang.org/x/mobile

It is no different than using the crippled NDK.

I don't know why you are getting down-voted. You are right, if you can't access to the Android framework, standard app development is heavily crippled.

Most likely by people that never bothered even to try to install the NDK.

Looking to how the Android team deals with anyone that dares to use the NDK, I bet if they had the freedom to choose the NDK would never had been made available.

Why would I want to run Android apps on any device?

If you are a Chromebook user, you want to run Android apps so there are more to apps available to you.

If you are an app developer, you want your apps in front of as many people as possible, regardless of their device.

Or, for the kids, this may mean Minecraft Pocket edition on the Chromebook :)

Reply on news.ycombinator.com