New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile Support #562

Closed
cjfromthesea opened this Issue Aug 8, 2014 · 62 comments

Comments

Projects
None yet
@cjfromthesea

cjfromthesea commented Aug 8, 2014

It'd be awesome if atom-shell supported iOS/Android. What is required to achieve this support? Related to #366

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Aug 8, 2014

Contributor

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.

Contributor

YurySolovyov commented Aug 8, 2014

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.

@zcbenz zcbenz added the enhancement label Aug 9, 2014

@cjfromthesea

This comment has been minimized.

Show comment
Hide comment
@cjfromthesea

cjfromthesea Aug 10, 2014

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

cjfromthesea commented Aug 10, 2014

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

@zcbenz

This comment has been minimized.

Show comment
Hide comment
@zcbenz

zcbenz Aug 11, 2014

Contributor

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

Contributor

zcbenz commented Aug 11, 2014

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

@zcbenz zcbenz closed this Aug 11, 2014

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 8, 2015

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.

trusktr commented Dec 8, 2015

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.

@joao-parana

This comment has been minimized.

Show comment
Hide comment
@joao-parana

joao-parana commented Jan 11, 2016

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Jan 11, 2016

Contributor

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

Contributor

paulcbetts commented Jan 11, 2016

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

@lastmjs

This comment has been minimized.

Show comment
Hide comment
@lastmjs

lastmjs Apr 16, 2016

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.

lastmjs commented Apr 16, 2016

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.

@emin93

This comment has been minimized.

Show comment
Hide comment
@emin93

emin93 Apr 25, 2016

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

emin93 commented Apr 25, 2016

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

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Apr 25, 2016

Contributor

@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.

Contributor

YurySolovyov commented Apr 25, 2016

@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.

@emin93

This comment has been minimized.

Show comment
Hide comment
@emin93

emin93 Apr 26, 2016

@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.

emin93 commented Apr 26, 2016

@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.

@JavaScriptDude

This comment has been minimized.

Show comment
Hide comment
@JavaScriptDude

JavaScriptDude Jun 8, 2016

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!

JavaScriptDude commented Jun 8, 2016

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!

@lastmjs

This comment has been minimized.

Show comment
Hide comment
@lastmjs

lastmjs Jun 8, 2016

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 commented Jun 8, 2016

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?

@jlord

This comment has been minimized.

Show comment
Hide comment
@jlord

jlord Jun 21, 2016

Member

@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.

Member

jlord commented Jun 21, 2016

@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.

@noelmace

This comment has been minimized.

Show comment
Hide comment
@noelmace

noelmace Jun 30, 2016

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 commented Jun 30, 2016

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).

@emin93

This comment has been minimized.

Show comment
Hide comment
@emin93

emin93 Jul 1, 2016

@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 commented Jul 1, 2016

@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.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jul 1, 2016

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

trusktr commented Jul 1, 2016

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

@jlord

This comment has been minimized.

Show comment
Hide comment
@jlord

jlord Jul 5, 2016

Member

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)?
Member

jlord commented Jul 5, 2016

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)?
@lastmjs

This comment has been minimized.

Show comment
Hide comment
@lastmjs

lastmjs Jul 6, 2016

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.

lastmjs commented Jul 6, 2016

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.

@jlord

This comment has been minimized.

Show comment
Hide comment
@jlord

jlord Jul 6, 2016

Member

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?

Member

jlord commented Jul 6, 2016

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?

@lastmjs

This comment has been minimized.

Show comment
Hide comment
@lastmjs

lastmjs Jul 6, 2016

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? 😃

lastmjs commented Jul 6, 2016

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? 😃

@joeblew99

This comment has been minimized.

Show comment
Hide comment
@joeblew99

joeblew99 Jul 12, 2016

@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.

joeblew99 commented Jul 12, 2016

@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.

@palodequeso

This comment has been minimized.

Show comment
Hide comment
@palodequeso

palodequeso Jul 12, 2016

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.

palodequeso commented Jul 12, 2016

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.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jul 12, 2016

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.

trusktr commented Jul 12, 2016

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.

@palodequeso

This comment has been minimized.

Show comment
Hide comment
@palodequeso

palodequeso Jul 12, 2016

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.

palodequeso commented Jul 12, 2016

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.

@hadees

This comment has been minimized.

Show comment
Hide comment
@hadees

hadees Jul 27, 2016

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.

hadees commented Jul 27, 2016

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.

@lastmjs

This comment has been minimized.

Show comment
Hide comment
@lastmjs

lastmjs Jul 27, 2016

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

lastmjs commented Jul 27, 2016

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

@JohnAReid

This comment has been minimized.

Show comment
Hide comment
@JohnAReid

JohnAReid Jul 31, 2016

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?

JohnAReid commented Jul 31, 2016

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?

@OtterCode

This comment has been minimized.

Show comment
Hide comment
@OtterCode

OtterCode Sep 29, 2016

@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.

OtterCode commented Sep 29, 2016

@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.

@zeke

This comment has been minimized.

Show comment
Hide comment
@zeke

zeke Feb 2, 2017

Member

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.

Member

zeke commented Feb 2, 2017

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.

@systems-rebooter

This comment has been minimized.

Show comment
Hide comment

systems-rebooter commented Feb 2, 2017

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Feb 25, 2017

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:

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

v3ss0n commented Feb 25, 2017

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:

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

@taoqf

This comment has been minimized.

Show comment
Hide comment
@taoqf

taoqf Feb 28, 2017

Good news

taoqf commented Feb 28, 2017

Good news

@brysgo brysgo referenced this issue Apr 11, 2017

Closed

Android support #9162

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal commented Jun 8, 2017

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

@gabrielcsapo

This comment has been minimized.

Show comment
Hide comment
@gabrielcsapo

gabrielcsapo Jul 3, 2017

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?

gabrielcsapo commented Jul 3, 2017

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?

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jul 3, 2017

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

trusktr commented Jul 3, 2017

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

@orangemocha

This comment has been minimized.

Show comment
Hide comment
@orangemocha

orangemocha Jul 3, 2017

@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).

orangemocha commented Jul 3, 2017

@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).

@gabrielcsapo

This comment has been minimized.

Show comment
Hide comment
@gabrielcsapo

gabrielcsapo Jul 4, 2017

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

gabrielcsapo commented Jul 4, 2017

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

@OtterCode

This comment has been minimized.

Show comment
Hide comment
@OtterCode

OtterCode Jul 4, 2017

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

OtterCode commented Jul 4, 2017

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

@gabrielcsapo

This comment has been minimized.

Show comment
Hide comment
@gabrielcsapo

gabrielcsapo Jul 4, 2017

@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)

gabrielcsapo commented Jul 4, 2017

@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)

@gabrielcsapo

This comment has been minimized.

Show comment
Hide comment
@gabrielcsapo

gabrielcsapo Jul 4, 2017

@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.

gabrielcsapo commented Jul 4, 2017

@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.

@LiamKarlMitchell

This comment has been minimized.

Show comment
Hide comment
@LiamKarlMitchell

LiamKarlMitchell Nov 21, 2017

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

LiamKarlMitchell commented Nov 21, 2017

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

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Nov 21, 2017

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.

trusktr commented Nov 21, 2017

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.

@aprilmintacpineda

This comment has been minimized.

Show comment
Hide comment
@aprilmintacpineda

aprilmintacpineda Dec 31, 2017

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.

aprilmintacpineda commented Dec 31, 2017

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.

@Serkan-devel

This comment has been minimized.

Show comment
Hide comment
@Serkan-devel

Serkan-devel May 19, 2018

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

Serkan-devel commented May 19, 2018

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

@Serkan-devel

This comment has been minimized.

Show comment
Hide comment
@Serkan-devel

Serkan-devel commented May 20, 2018

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

@aprilmintacpineda

This comment has been minimized.

Show comment
Hide comment
@aprilmintacpineda

aprilmintacpineda May 20, 2018

@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 commented May 20, 2018

@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.

@Serkan-devel

This comment has been minimized.

Show comment
Hide comment
@Serkan-devel

Serkan-devel May 20, 2018

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

Serkan-devel commented May 20, 2018

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

@SourceBoy

This comment has been minimized.

Show comment
Hide comment
@SourceBoy

SourceBoy Jul 12, 2018

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.

SourceBoy commented Jul 12, 2018

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.

@sprlwrksAprilmintacpineda

This comment has been minimized.

Show comment
Hide comment
@sprlwrksAprilmintacpineda

sprlwrksAprilmintacpineda Jul 12, 2018

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.

sprlwrksAprilmintacpineda commented Jul 12, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment