Does anyone know of a way in which you can deploy a WebGL app as a native iOS or Android app? Commercial middleware is acceptable, although an open project would be preferable. Thanks.
As an extension to Joris' answer (which appears to be based on the work of Nathan de Vries), the following is the code I needed to enable WebGL within the iOS 5.0 SDK:
Somewhere near the top of your view controller implementation:
#interface UIWebView()
- (void)_setWebGLEnabled:(BOOL)newValue;
#end
Programmatically creating a UIWebView and enabling WebGL:
UIWebView *webDetailView = [[UIWebView alloc] initWithFrame:mainScreenFrame];
id webDocumentView = [webDetailView performSelector:#selector(_browserView)];
id backingWebView = [webDocumentView performSelector:#selector(webView)];
[backingWebView _setWebGLEnabled:YES];
I created a sample application that demonstrates WebGL running in a iPhone / iPad fullscreen UIWebView, using the WebGL scratchpad site http://glsl.heroku.com as a destination. Be wary that some of those examples there will grind even an iPad 2 to a halt, potentially leading to a hard reboot. The performance there seems to indicate why WebGL is still in an officially unsupported state in mobile WebKit.
Of course, as has been stated, this is not guaranteed to work on future iOS versions and will get your application rejected from the App Store. This is only really useful for hobby work and internal testing.
An example of WebGL running on my iPad 2:
WebKit on iOS actually supports WebGL, as of 4.x (not sure which .x version). It is enabled in the webview used by the iAd framework, all other uses of WebKit (Safari and UIWebView) have WebGL disabled.
It is possible to enable WebGL using private API's (this will not pass the submission process). In your webview subclass:
- (void)setWebGLEnabled:(BOOL)enableWebGL {
UIWebDocumentView* webDocumentView = [self _browserView];
WebView* backingWebView = [webDocumentView webView];
[backingWebView _setWebGLEnabled:enableWebGL];
}
(via)
This will at least allow you to start experimenting with WebGL on iOS.
Not sure about WebGL support on Android. Fairly recent comments on the issue in the Android tracker suggest it is not available yet.
A nice support table for WebGL in (mobile) browsers: When can I use WebGL
Best way to go for now seems to be to include your own WebGL enabled version of WebKit in your application wrapper for both iOS and Android.
As the iOS version of WebKit doesn't support WebGL natively, I think you have two options:
Implement the WebGL API in the JavaScript context of a WebView yourself by forwarding calls to the native OpenGL via iframe RPC or so. There isn't a clean way of calling (Objective-)C functions from JavaScript on iOS, unfortunately. Performance could be a problem.
AOT-Compile or interpret the JavaScript in a third-party runtime, then implement WebGL from there. JIT compilers are disallowed on iOS, so something like V8 won't work. Appcelerator Titanium statically compiles JavaScript as far as I know, and also has an interpreter. You could use that, but you'd still need to implement the WebGL glue yourself.
I'm not aware of any existing WebGL bridges for iOS, so I think you will need to either write it yourself or get someone to do it for you. One problem that might not be possible to overcome is if you use anything other than WebGL to display stuff - e.g. HTML, 2D <canvas>, etc. Combining WebView display with an OpenGL framebuffer is going to be rather tricky.
I don't know much about Android, but considering the rules are more relaxed there, it might be possible to embed a WebGL-compatible browser there.
I don't think there are any easy converter tools. You'll probably have to take your WebGL codebase and rewrite in OpenGL for both platforms, to create native apps.
It's not ready yet, but ForPlay may be able to act as a common development platform for Android and WebGL via GWT.
Bundling WebKit and your app's resources (.js, textures, etc) into an iOS or Android application doesn't sounds too much difficult. I'm assuming that since Google and Apple are major contributors to the WebKit project, all the required support (for multitouch and other stuff) is already there.
PS: many iOS apps use interpreted Javascript or Lua. The rules are there to prevent your app to execute 3rd party code (esp from the internet), not the code you'd bundle in your own app.
EDIT: To clarify, I think you'd need to implement your own web view using webkit (built from source) in order to use WebGL and pass Apple's screening process, as activating WebGL in the Apple-provided web view will get your app rejected.
There are a couple of options to be able to deploy a native WebGL app. EjectaGL is a great WebGL implementation but a little bit harder to master (http://codehum.com/stuff/ejectagl/).
Another option is Ludei that recently announced their support for WebGL on both iOS and Android. It is easier to use and supports acceleration for HTML5 canvas in both 2D and 3D through WebGL. It also provides a way to monetize your app using IAPs, ads and plenty of extensions. It is much easier to test using the CocoonJS Launcher App and their cloud compiler.
www.ludei.com
http://blog.ludei.com/webgl-demos-arrive-to-google-play-store/
Try Phonegap. It allows you to build "native" HTML+CSS+JS apps using the standard Webkit installation on your OS. And it provides a javascript-to-native bridge to allow you to do things not possible in pure webapps.
Related
I'm maintaining a plethora of apps for one of my clients all of which have native projects for each of the three main platforms. The apps are relatively simple in functionality. My client wants to always take advantage of the latest features in each platform for marketing opportunities. They also want to appear to be a native app (responsive, not laggy). I haven't followed cross-platform development very much lately, so that's why I'm reaching out to SO.
My initial idea is to write a C++ library that has all the functionality shared by the three platforms. Then, for each platform, I'll write some network, file access, and UI-code that connects the abstract library code to the concrete platform.
Of course, this is exactly what cross-platform systems aim to do. Would it be a waste of my time to write the above myself when this has already been done by platforms like PhoneGap? My concern is that I would be dependent on a third-party. If I write the code myself, I have full control, and I will always have access to the latest features.
Hope to get some pro's and con's.
Thanks!
Yet a third option (after Facebook's React Native and Microsoft's Xamarin) is Google's new Flutter and as the other answers suggests "then writing the Windows app purely natively". BTW, React Native does have Windows support the lack of which in Flutter could be a plus or a minus depending on how you look at it.
Have you considered using React Native for iOS and Android, then writing the Windows app purely natively?
There are tons of articles out there about pros and cons for React Native.
PhoneGap is just a web, written in HTML, CSS and JavaScript. React Native actually renders native components for iOS/Android.
There is also Xamarin. It supports multiple platforms and uses c#. The new features from the native languages all work great.
I've to do a quick development for a prototype app and I've decided to go for a cross-platform HTML5 tool/platform.
I've shortlisted Intel XDK for its developer-friendly IDE, React native for its performance as a native build compared to others and Ionic for the nice UI with Angular and available themes.
I need native like performance and nice UI with some responsive themes, which would be better recommended?
Currently? Cordova + Intel XDK has more support and a larger feature set. There are even examples that come with the XDK of video games that perform at near native speeds. Cordova uses JS APIs to hook into native functionality, but at the end of the day, you're still running web code.
React Native is different in that you're building an application using native components, but expressed using React's JSX. Arguably, because you're building the app using native components, you should see better performance (and get a more native look/feel).
Cordova:
Uses a web view
Taps into native functionality with jsAPIs
Has been around longer, and has more support
Code once, run everywhere
React Native:
Android support appears to be a little shaky? (could be wrong here)
Builds display using native components
Newer, but backed by a powerhouse (and gaining traction)
Learn once, code everywhere
Honestly, using either technology you should be fine. Both have shown that they're up for most challenges.
I would probably push you to Cordova + Intel XDK for increased support, easier for webdevs to pick up, and it's more mature. React may very well eclipse it, but I don't think it's quite there yet.
¯\_(ツ)_/¯
with cordova The biggest advantage you get, is the single code base to develop without learning any new technology, if you are already a web developer But the application runs in the webview, and not natively on the hardware, which makes it less performant than the native iOS applications or native Android.
in React You need to understand the Framework(react), you need to understand JSX (in iOS simulator, You also need to work with Xcode)
With React native, you get ease of development, better performance and great user experience in the end
Is Chrome Apps For Mobile only a collection of Apache Cordova plugins for each mobile platform or does it intend to also replace the native web-view with Chrome based web-view ?
This question and this slide on Google Docs seem to indicate that it is only a collection of plugins. This question says that on iOS it uses the native web-view.
What about on Android and any future platforms Google might support?
Yes, all current Chrome Apps for Mobile using the cca toolkit are cordova based and thus use the Native system WebView.
On iOS, this currently seems unlikely to change because of policy restrictions (but hey, who knows).
On Android, the cordova contributors would like to experiment with supporting the use of custom web renderer implementations. This is being discussed as a possible cordova-4.0 major version bump milestone feature, and would thus target fall/winter of 2014. This is really just a dream at this point, but its certainly a feature that is on everyones mind.
I should note, there are a many downsides to doing this, its not all gravy. Using a custom WebView means adding ~20meg to application download size, and means significantly more memory/video memory usage on device. Alternatively, we could ask users to download a separate "cordova-runtime" app from the store (like Adobe Air for Android, or like you have to download a Java Runtime for desktop), but users usually dislike that experience.
Also, with Android 4.4 KitKat now having a chrome-based WebView, which enabled remote debugging and implements many modern web capabilities, the usefulness of a custom WebView is shrinking.
Finally, there is already a project that does what you ask, but isn't cordova based, and is not used by the cca tool: Intel's Crosswalk Project. Just adding it for reference. Their wiki goes over a lot of tradeoffs with their approach.
We're developing several HTML5 apps based on the Sencha framework, and thinking about packaging them into apps with say PhoneGap.
However, even if you package these into apps, I'm assuming you still have to deal with the Android fragmentation with various manufacturers making weird modifications to the browser. We've tested a lot of manufacturers (especially those from China) and the default Android browser is being hacked to death.
Our app works perfectly in the Chrome browser on Android, so, the question is, is it possible to just literally put Chrome into the same package and just use that? Instead of some random modified browsers each manufacturer feels like making.
Sorry if this is a dumb question, still very new to this. Any help / advice would be greatly appreciated!!
I want to point out Crosswalk: https://crosswalk-project.org/
It seems to provide what you require.
What is Crosswalk for?
If you are a developer working with web technologies, Crosswalk enables you to deploy a web application with its own dedicated runtime (ed: modified Chromium). This means three things:
You can distribute your web application via app stores.
Your application won't break in whatever ancient webviews or browsers your audience is using, as you control the runtime and its upgrade cycle.
You can build applications without worrying so much about runtime differences and quirks: you only have one runtime to deal with.
I'm assuming you still have to deal with the Android fragmentation with various manufacturers making weird modifications to the browser
PhoneGap doesn't use the browser. PhoneGap uses a Web rendering engine per platform. On Android, that is WebView. Hence, it matters not a whit what manufacturers do the the AOSP Browser application.
is it possible to just literally put Chrome into the same package and just use that?
If you have a dozen or so Java and Android native code engineers who are capable of taking the Android build of Chromium and rewriting substantial amounts of Apache Cordova (a.k.a., PhoneGap) to use Chromium, it's at least conceivable. Then again, if you have a dozen or so Java and Android native code engineers, you might be better served simply writing a native Android app, as it will be smaller, faster, and easier to maintain than your own home-grown edition of "ChromiumGap".
To quote the Chrome for Android FAQ:
Does Chrome for Android now support the embedded WebView for a hybrid native/web app?
We are evaluating ways we can support WebView with Chrome but do not have any plans to announce at this time.
We will develop a, social network integrated mobile application which will need to access native device capabilities but 90% of the logic will be implemented in the HTML5/Javascript code posted by Ruby back end to the device. Thus, we would like to update or change the logic/GUI of the app without user involvement. We have strict deadline and have to support iOS, Android and Blackberry.
In this case, what approach would you recommend us? We considered the approaches below but could not decide since we do not have any experience with mobile development even if we are experienced in Ruby, C/C++, Java, Javascript, Flex.
Our considerations:
Develop native apps for each platform and embed the native browsers
to implement our logic, which can take too much time.
Use one of the frameworks for cross-platform development such as
PhoneGap or rhomobile. In this case, we are afraid of facing some performance issues. We would love to hear the experience of developers with those frameworks.
Use Adobe Air for accessing the device and its WebKit component for the rest.
First, I hope you understand that there is no simple answer. At this junction, having been looking at cross-platform solutions for mobile development for two years, I feel that in order to get fully native UI look, and to access all the device and UI features, one is forced to produce native application on each platform.
But, since you asked about cross-platform tools, here's a list of the main contenders:
Sencha http://www.sencha.com/products/touch “Sencha Touch is the world's first app framework built specifically to leverage HTML5, CSS3, and Javascript”
Dojo http://dojotoolkit.org “Dojo saves you time, delivers powerful performance, and scales with your development process”
Phonegap http://www.phonegap.com “PhoneGap is an open source implementation of open standards”
jQuery Mobile http://jquerymobile.com “Touch-Optimized Web Framework for Smartphones & Tablets A unified user interface system across all popular mobile device platforms”
Rhomobile http://rhomobile.com “Free and open source mobile application framework”
Titanium from Appcelerator http://www.appcelerator.com
There are plenty of comparisons online, including on SO, and this fellow actually tried to use several platforms, code included.
Anecdotally, I have seen Phonegap produce a rather iPhone-centric look, that may not mesh well with Android, plus showing performance problems when loading screens (there may be workarounds via pre-loading). Also, access to more complex devices was limited, or at least lagging. Rhomobile is a good fit for data-driven apps (simple display of large databases), but architecturally could show performance issues, so check for yourself. Personally I did not get into Sencha, Dojo seemed a little small, and Titanium showed dated architecture. So next time I'm attempting a cross-platform app, I'll give jQuery Mobile a serious try.
Let us know what you pick and how it works out.
Iam using this rhomobile rhodes for my cross-platform development App which will run in Android, Blackberry and iPhone.
We have developed application and sucessfully runned in all devices without any issues. we used ruby for backend webservice call, And remaining app is constructed with HTML5 and java Script. I didn't face any issues regarding rhomobile.
intially we faced memory issues, But later on we resolved this issue by implementing local storage for our App. For android it wont supports local storage so we used Rhom Storage only for Android Device.
Sounds like a project doomed to fail.
If I were you, I'd build a mobile-friendly site for all 3 platforms if deadline is tight. What native features do you even need, first off? If it's something like a camera, you're better off just build a native app for all 3.