Electron: Mobile Support

I think atom-shell was primarily build for atom text editor, so I would not expect it supporting mobile platforms. There are Phonegap and Cordova for HTML5 mobile apps.

Yeah, but it is about sharing code from node.js modules and for accessing low level resources

For mobile platform, nearly all of atom-shell's APIs don't apply, so I don't think we will ever support mobile platforms.

Maybe you guys can at least play well with Cordova, etc, by (somehow) detecting the environment (at runtime, or specified during build) so that the Electron APIs simply call Cordova modules (or native code) without us knowing. That would be insanely awesome.

+1 @trusktr

@trusktr Sounds like a great 3rd-party module that would provide compatibility shims for Cordova

I really hope this happens. I think the future of the web platform needs to move in this direction, so that we can write TRULY cross-platform apps. I'm really hoping this isn't ruled out.

I can't believe it's already 2016 and there's still no such thing.

@emin93 this is not constructive, as already pointed out by @zcbenz, it would be nearly impossible to port Electron APIs to mobile.
You can't just demand features without at least some kind of suggestions on how to make it happen.

@YuriSolovyov I'm not referring to Electron directly. There are actually no alternatives and that's what gets me frustrated. But yeah, you're right, that's actually not the right place to discuss that.

Electron for mobile would be so awesome. I have a few Electron Apps developed and love the framework but every day I wish we would see it work on Mobile too.

The only cross platform framework that shows end to end cross platform support (IOS, Android, Windows, OSX, Linux) is Xamarin but that requires to code in C#. I would not be surprised if Xamarin allows JS code soon as Microsoft now owns Xamarin and has also been making great strides in with porting node to their own JS engine.

I really hope that some corporate sponsors can get on board to fund such a port / fork of electron for mobile that would eventually be baked into the same framework so we can have a full JS based cross platform application development framework.

Thanks Electron team for your great work!

Echoing the original question from @cjfromthesea, can someone explain the problems there are with Electron's APIs on mobile (perhaps @zcbenz)? With some general guidance, myself and others can potentially start thinking of ways around the problems by hacking and tinkering. I've dealt with jxcore-cordova a little, but some guidance would be nice. What are the roadblocks?

@lastmjs a huge roadblock is that Electron uses V8 which is not supported on iOS. This means Chromium and Node.js will also not work on iOS and these three are the main components of Electron.

A new chromium version for IOS was released in january, and node.app could maybe do the trick for node.js. And Android shouldn't be a problem given that V8 is supported.
In the mean time, we could write a documentation on how to use Cordova with electron for IOS (as I really need those, I would be happy to help).

@noelmace Chrome for iOS does not use the Chromium engine since Apple doesn't allow that. It's just the WKWebView like Safari uses it, but with a different UI.

@emin93 Does Apply allow using any custom interpretter like node.app?

I had a few questions I'd love thoughts on from those in this thread—

• Are you looking to build _one app that runs everywhere_?
  
  
  
  • Follow up question, are there examples of desktop apps (that aren't web apps) that are also mobile apps?
  
  
• Or are you looking for the Electron app building _experience_ but on mobile?
  
  
  
  • Follow up question, how would that differ from Cordova/PhoneGap (or others)?
  
  

I'm definitely looking for one app that can run everywhere. One codebase, one web platform, any environment.

Examples of good mobile/desktop/web apps, where the screen size and device doesn't really matter, but you might want the same functionality:

• Chrome
• Firefox
• Slack
• Gmail
• Google Photos
• Google Maps

Not all of the apps above necessarily have a desktop version run with a native executable, but they do have a desktop version in the browser. To me, of course it depends case by case, but generally I want my app to be my app no matter what device it is on. I strive for the same features across all devices as much as possible. Why not? I want Chrome to work the same on my desktop as it does on my Android, my iPhone, or my tablet, the same for Firefox, slack, Google Maps. I find it sad when sometimes Google Maps features are platform specific. Back to Chrome, I want to be able to view source and even use the debugger, even on my phone. I sometimes think we don't have the foresight to limit the functionality of our applications appropriately. What if someone does want a feature that works on the desktop version of the app on their phone? The apps should be responsive of course, but core functionality should remain the same as far as possible in my opinion.

Thanks @lastmjs. I just edited my question because what I was thinking, but hadn't specified, was desktop apps that are also mobile apps but are not web apps. I think this is an important distinction.

but core functionality should remain the same as far as possible in my opinion

Thinking out loud here: Electron creates an API for common native desktop application behaviors—it seems that if you also add in mobile that the common ground between all of these would shrink. An app based on the common ground between desktop and mobile might in the end work everywhere but be a sub par mobile experience and sub par desktop experience?

Are the common native desktop application behaviors you are talking about mostly UI based? I can see how native menus and other behaviors might not translate well. The biggest benefit to me would be having one consolidated runtime, where I have access to Node.js and Chromium API's, and said runtime being deployable to all major platforms. Electron and Cordova are in a way doing the same thing for different platforms, minus UI functionality as you may have been talking about. With Cordova you have one codebase that can be deployed to a few major mobile operating systems, said mobile operating systems not being too different in functionality from the major desktop operating systems. An operating system manages processes and their resources, and grants access to hardware that the processes might need. There isn't much of a fundamental difference there between mobile and desktop operating systems. And with browsers beginning to have hardware APIs, the web platform is becoming more and more universal in its ability to deploy in all major environments. So as I see it, Cordova and Electron are accomplishing largely the same tasks but on different operating systems, said operating systems not being fundamentally different, and so why not combine them? 😃

@jlord

I build for mobile and desktop and would like to add to the comments from @lastmrs and @noelmace

Here are my thoughts for how it could work for everyone.

The API that electron exposes has to vary based on if it mobile or desktop. So it is then the responsibility of the developer to do runtime environment detection ( which the electron layer provides) to call a different API depending the the environment context.
Again to be clear, it's up to the develop to do the right thing

As far as UI aspects, again it's down to the developer to do the right thing. I use polymer for all my desktop and mobile projects, and it's down to me to do it correctly.
I also use golang to write any compiled stuff i need on desktop and mobile to access any hardware.

At build time, I package for desktop ( amd 64, etc, etc ) and mobile ( android or iOS) where I make a separate package for each OS and chip architecture. I do the same with electron. This allows me to do compile time differences as I need it because some code is hardware dependent.
I can still include the same code in all the builds and do runtime sniffing, and this is where electron would provide me the environment context.

The great thing this provides is common tooling at design time and compile time. This is a huge productivity improvement for developers because you can install electron and run a bootstrap bash script to install the iOS and android bits and your writing hello world and packaging and deploying to desktop and mobile.

I did not know that the Google team had updated chrome for iOS to be multii-process. I am super excited to see this.

If I can help with any of this I would gladly do help.

This would be such a massive improvement for a lot of my projects as well. One would already have to make changes to the UI based on whether it's mobile or not, might as well do any other detection/changes as well.

I don't think having two separate APIs is a good idea (@joeblew99). For the end user, I think it'd be better if Electron made it's APIs work on top of Cordova or Node, so that the end user only needs to know one API (Electron API). Then if something isn't covered by the API, end users can dive into Node or Cordova as needed.

Also, I think it would be important for Electron to define how to use an NPM workflow that works in either case (Cordova or directly on Node). I.e., Electron would have to define it's build system to be compatible with both, using NPM (and ES6 modules would benice too) so that end users wouldn't have to worry about how to build for each. The Node case is already handled, obviously, but there might need to be additional work so that NPM works fine in Cordova.

Note that in Cordova Node.js APIs aren't available, so Electron would need to polyfill some of the native Node.js modules with alternatives that work in Cordova, similar to what Browserify does for the browser. This would help with making a unified API, because if there's something the Electron API doesn't cover, then at least the polyfilled libs means the user can fall-back to Node-based APIs that behind the scenes call Cordova APIs.

The need to polyfill is exactly what I think it's smarter to start with the API route. It doesn't have to be a separate API, just some features are not available right away. If you go through and make it 100% compatible, then it's a much bigger beast to deal with when new features are added down the road.

I would also just like to point out that Android and IOS aren't just mobile anymore. The project I'm working on would look awesome on an Android TV, plus I don't see why Github wouldn't want to make Atom run on TVs or Tablets.

Great point, it isn't about screen size anymore, we're starting to deal with general purpose operating systems.

I am confused as to the status regarding Electron on Android?

Is it something which is actively being considered or merely something being talked about?

Making Electron apps a valid target for PhoneGap or Cordova apps is about 1000X easier!
ie. cordova platform add electron-osx electron-win electron-linux

@purplecabbage sure but then you lose all the added benefits of controlling the entire browserstack.

RE: Node.js Polyfills.

We should start a list of the required _native_ polyfills for this to work. Browserify already has pure web versions of a _lot_ of Node.js Core. The only ones I can think of that we'd need are:

• dns
• net
• fs

Anything else?

Global Objects:

• __dirname
• __filename
• process

@purplecabbage looks like those 3 have browserify implementations. https://github.com/substack/browserify-handbook#__dirname. Should we give them different values based on devices?

yeah, __dirname and __filename are not biggies.
process is barebones in browserify, wouldn't we want to support events?
https://github.com/defunctzombie/node-process/blob/master/browser.js

For Native Mobile apps sharing code with electron.js, I think the best will be to explore the route by combining Electron.js with NativeScript - http://github.com/NativeScript/NativeScript.

We (the NativeScript team) are planning to create a sample demo app, if you are interested, please comment on this issue - https://github.com/NativeScript/NativeScript/issues/2695

Actually, there is already available Angular 2 advanced seed that enables this - https://github.com/NathanWalker/angular2-seed-advanced. But angular 2 is by no means a requirement to implement such kind of solution.

Is this something that makes sense?

I think the key thing is your team has done the leg work to add the native APIs. I'm all for your idea.

@valentinstoychev that's a really interesting idea although it basically means any electron apps is going to have to redo it's entire UI right? It would be really interesting if somehow y'all could include libchromiumcontent to create a webview similar to electron. Then it would be easier to use both in one app.

What about the Android WebView widget and the equivalent on iOS? In fact the Android one is already chromium. :)

@hadees yes, the idea is to implement the mobile UI once for iOS and Android using NativeScript and once for desktop using electron. Everything else - data, models, business logic, services, data access should be the same.

There are two things to note here.

First, you will be using almost the same skillset (means one team can make it for desktop, web and mobile) when building with electron.js and NativeScript - it is all JavaScript/TypeScript/CSS. You can use Angular 2 if you like. For styling, you will be using CSS for both NativeScript and electron. _So generally the only thing that will be different is the UI markup_. Even the layout should be familiar as we are releasing FlexBox layout next month. Everything else is reusable code and most importantly reusable skillset. The tooling part should also be familiar as in NativeScript we are using Chrome Devtools...

The second thing to note here is that you actually want to have different UI for mobile and desktop, right. So, in many/most, of the cases, the UI part will not be reused anyway and should be different.

I believe this is a pretty compelling story and we will explore it and show a real-life example very soon. I hope seeing the actual code and actual app will help clear a bit if it is worth exploring or not.

In any case, the final app (or apps) will be with native UI everywhere. And I think this is what makes this solution unique and worth exploring. It is also cheap to be hacked because there are no changes need to be done on both electron.js and NativeScript. Starting from this first solution, we may find areas where a more tight collaboration can exist.

I have used polymer for the desktop and mobile GUI, with Cordova. Cordova
supports desktop and mobile.

The key for me was to use grpc as the binding technology. This made it much
easier because clients and servers can interoperate.

For all I just needed a grpc proxy plugin to act as middleman

On Sat, 10 Sep 2016, 08:17 Valentin Stoychev, [email protected]
wrote:

@hadees https://github.com/hadees yes, the idea is to implement the
mobile UI once for iOS and Android using NativeScript and once for desktop
using electron. Everything else - data, models, business logic, services,
data access should be the same.

There are two things to note here.

First, you will be using almost the same _skillset_ (means one team can
make it for desktop, web and mobile) when building with electron.js and
NativeScript - it is all JavaScript/TypeScript/CSS. You can use Angular 2
if you like. For styling, you will be using CSS for both NativeScript and
electron. _So generally the only thing that will be different is the UI
markup_. Even the layout should be familiar as we are releasing FlexBox
layout next month. Everything else is reusable code and most importantly
reusable skillset.

The second thing to note here is that you actually want to have different
UI for mobile and desktop, right. So, in many/most, of the cases, the UI
part will not be reused anyway and should be different.

I believe this is a pretty compelling story and we will explore it and
show a real-life example very soon. I hope seeing the actual code and
actual app will help clear a bit if it is worth exploring or not.

In any case, the final app (or apps) will be with native UI everywhere.
And I think this is what makes this solution unique and worth exploring. It
is also cheap to be hacked because there are no changes need to be done on
both electron.js and NativeScript. Starting from this first solution, we
may find areas where a more tight collaboration can exist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript is not really an option for Electron's mobile support, because
it completely shifts the paradigm away from web technology to JavaScript
bindings for native widgets. In essence, what we'll have would no longer be
"Electron", because Electron at it's core is a browser stack that exposes
Node.js _inside_ of a browser context, and that is what makes Electron
Electron.

NativeScript + Node.js bindings can be deemed a completely different
project.

First, you will be using almost the same skillset (means one team can make it for desktop, web and mobile) when building with electron.js and NativeScript - it is all JavaScript/TypeScript/CSS.

Not necessarily true, because with NativeScript you must have some
understanding of how the native widgets behave, regardless of the fact that
you are coding in JavaScript. This means that without the knowledge of the
widgets, and without knowledge of how to modify those widget bindings with
native code, then doing something custom becomes very difficult, which is
not the case with pure JS/HTML/CSS in a web stack, because with a web stack
modifying the internals means modifying the same type of code in the same environment you're already in, not having to worry about a foreign language.

The second thing to note here is that you actually want to have different UI for mobile and desktop, right. So, in many/most, of the cases, the UI part will not be reused anyway and should be different.

One of the benefits of using Electron (with it's Web-based front-end), is
that we write one code, and it behaves almost _exactly the same_
everywhere. This would not always be the case with NativeScript, which
tries to bridge completely different sets of technologies with one language.

I personally like much more the idea of using a web-ui everywhere,
versus different native UIs everywhere. Some people believe that Native UIs
are much better than Web UIs. It is true to some extent, and it is the case
with developers that don't know the full underlyings of the web. But, with
proper use of web APIs we can in fact make nice UIs. The web is making huge
progress. WebGL is hugely cross-platform...

_/#!/_JoePea

On Fri, Sep 9, 2016 at 11:17 PM, Valentin Stoychev <[email protected]

wrote:

@hadees https://github.com/hadees yes, the idea is to implement the
mobile UI once for iOS and Android using NativeScript and once for desktop
using electron. Everything else - data, models, business logic, services,
data access should be the same.

There are two things to note here.

First, you will be using almost the same _skillset_ (means one team can
make it for desktop, web and mobile) when building with electron.js and
NativeScript - it is all JavaScript/TypeScript/CSS. You can use Angular 2
if you like. For styling, you will be using CSS for both NativeScript and
electron. _So generally the only thing that will be different is the UI
markup_. Even the layout should be familiar as we are releasing FlexBox
layout next month. Everything else is reusable code and most importantly
reusable skillset.

The second thing to note here is that you actually want to have different
UI for mobile and desktop, right. So, in many/most, of the cases, the UI
part will not be reused anyway and should be different.

I believe this is a pretty compelling story and we will explore it and
show a real-life example very soon. I hope seeing the actual code and
actual app will help clear a bit if it is worth exploring or not.

In any case, the final app (or apps) will be with native UI everywhere.
And I think this is what makes this solution unique and worth exploring. It
is also cheap to be hacked because there are no changes need to be done on
both electron.js and NativeScript. Starting from this first solution, we
may find areas where a more tight collaboration can exist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr I wholeheartedly agree. I think there is too much stock put into looking native by developers. Native isn't even a consistent ideal. In the last decade, mobile interfaces have changed dozens of times, and aren't even consistent from one android phone to the next.

Having your app look consistent across all the platforms that a user might access it from is a much better standard to hold. Making them learn two sets of UI symbols and signals just to operate an app on both their iPhone and Windows work machine is terrible.

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository.

Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink, Chrome's rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.

Given Chrome's commitment to open-source code, we've spent a lot of time over the past several years making the changes required to upstream the code for Chrome for iOS into Chromium. Today, that upstreaming is complete, and developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

First big step? :]

But that dosen't mean anything since chromium is not allowed to put on apple store.

But in android , it is dearly needed now .

Developing with cordova and default webview is hell , and intel had scrapped Crosswalk , which is intel's port of chromium webview as default webview to android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Problems:

• default webview is unreliable thanks to different vendors doing different things.it is not stable till 6.0 of android , which is only 20% of phones using.
• not every one is doing android firmware or package updates, especially in bandwidth restricted areas with expensive 3G.

What we can do:

• Electron APIs are impossible to port to chrome ( as @zcbenz saids in 2014 )
• chromuim for android and chromium webview for android is fully opensourced now : https://www.chromium.org/developers/how-tos/android-build-instructions
• We can fork and cotinue maintaining crosswalk (Which is basically port of chromium to android with less restrictions) https://github.com/crosswalk-project , it is already quite stable.
• Our experience show that crosswalk and cordova with a good JS Framework gives Near-Native peformance ( Emberjs / React / Angular /Vue ) .
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

we need contributors and maintainers in crosswalk , that might be one you are looking for.

Good news

Relevant news, new port of Node.js to iOS by @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

so the only effort that would need to be done is to make sure that the mobile browsers support electron if emulated via the link that @mikeal posted?

Is it legal to ship other JS VMs on iOS nowadays? Or does Apple still require you to use theirs?

@trusktr shipping VMs that don't generate executable code is not in violation of the app store guidelines. We have gotten such an app approved in the app store before (though using SpiderMonkey and not ChakraCore).

Can we reopen this issue to continue the discussion on wether electron will have a supported mobile framework in the future?

I second this. What needs doing? I'm happy to start testing or hacking on this with a little direction.

@OtterCode would it make sense to create a repo called electron-mobile and start hacking there? I could see a necessary step of planning and getting example applications ready to start to figure out what needs to be done. Is there a higher level api library for electron that we could emulate to get started? (Api docs, build targets, etc)

@OtterCode and anyone that is interested I have created, https://github.com/gabrielcsapo/electron-mobile, if anyone is interested I can add you as an owner and we can start working on a path forward for iOS and Android build targets for electron.

Products such as Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Make this a viable request IMO (at least for Android).

This is definitely very doable. The application "Termux" from Google Play, for example, gives us a whole Debian-based terminal right in the app. We can apt-get install anything we need (Node, Vim, Git, etc, as long as the thing we're installing supports the device's CPU architecture). It's completely possible to get Electron running in its own app-sandboxed environment similar to Termux.

Termux works without rooting our phones, it installs everything inside the app sandbox, and we can even symlink our external storage into our "home folder" within Termux and work in our external storage using all the command line tools that Termux gives us.

We can open Node.js apps in our browser, on localhost, served right from in Termux.

Its definitely possible to do something like this with Electron.

I really hope this will happen, I have used ElectronJS for my previous project which was a stand-alone desktop-based computerized system. Electron was extremely great, now a company wants to hire me and they want to create mobile apps, they are thinking of using PhoneGap for it since they don't want to bear the trouble of having multiple teams for different platforms (iOS/Android), having a one-fits-all solution is extremely great, and I hope ElectronJS can have a version that supports mobile so I don't have to switch between different platforms and languages, it really tiring sometimes.

react-native isn't a permanent fix for this problem

@aprilmintacpineda have you looked into Progressive Web Apps already? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel yes I have, I was not aware of progressive web apps when I saw this issue here. I decided to use react-native instead.

@aprilmintacpineda you can still try out PWAs too, https://youtube.com/watch?v=vhg01Ml-8pI . It also helps on the desktop

How does one integrate nodejs-mobile with Chromium? This seems like the closest solution to bring Node to mobile in a browser environment, similar to what Electron has done for desktop.

(I'm aware of what PWAs can do today, and there are frameworks such as Cordova to wrap web apps into mobile apps, but PWAs can't access to OS-level file systems or embed HTTP servers, and Cordova is just an overkill for my current project, not to mention the setup and build processes for both Android & iOS.)

A distributable bundle of Node-integrated browser for mobile would've made development as easy as developing desktop apps with Electron, which I believe is what made Electron so popular. A lot of code would also be reusable instead of writing completely different code for mobile.

I'm a web developer and don't have the expertise in building system/native applications, let alone integrating a complex browser with Node, so any pointers would be greatly appreciated. If you have the expertise and want to help creating such project, you're more than welcome to contribute.

While this is possible to be achieved, I think we should think twice if we should really do this. On the desktop app where I used electron, I experienced lags, especially with css animations. If there's a native option, I'd rather go for the native, native has a lot to offer. Or maybe try out PWA. It's awesome, but not a replacement YET for apps, but I think it has a great future.

mark

https://github.com/dna2github/dna2oslab

the nodejs which can work well on android

It's not exactly like Electron, but for anybody who wants to build Android apps with Node.js, this library seems to work well in my testing.