Was anyone else disappointed when they opened it on their iPhone and it rendered the same page?
Framework 7 – Building native iOS apps in HTML5
41–50 of 131 posts
Re: Framework 7 – Building native iOS apps in HTML5
#42I'm not knocking this or any particular xxxx-to-mobile platform, but as a native iOS and android developer, I would highly recommend just learning the native languages and frameworks. First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who know…
As someone who has used several cross-platform frameworks (Titanium, Cordova/PhoneGap, investigating Xamarin), I have a question about going "full native": how do you handle shared core code? Our app has an engine that drives the business logic, and the cross-platform frameworks have been useful because we don't have to deal with modifying the core codebase for different platforms [0]. Is it possible to create platform-agnostic libraries that can be shared?
[0] Despite the many claims of "cross-platform UIs," we have many cases in our UI layer of doing different things on different platforms.
Re: Framework 7 – Building native iOS apps in HTML5
#43Earlier quoted context omitted.
My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8 : Google). Web Views inside native apps don't get access to Nitro. Even web apps that you save to your home screen don't get access to the faster rendering engine. This is apparently for security reasons. I think it's one of the biggest barriers to web apps being competitive on iOS. (The other is that there really isn't a good installation…
"security reasons" (= http://bit.ly/1d7p5Tq ) it would be interesting if they elaborate on those...
More like "job security" reasons as they have less control over webapps than apps.
Re: Framework 7 – Building native iOS apps in HTML5
#44Earlier quoted context omitted.
The advantage of using a single language is that, for each single app in all the three store, you have to change a single codebase and not to make 3 different changes in 3 different codebases just because each of them require its own language (and then its own specific libraries). So you have surely to spend the time to sort the libraries, but it is a one-time problem. After it, you can just use them without problem…
It's a nice dream. Pity reality is so very harsh on nice dreams.
See my comment above: I am under no delusions that cross-platform frameworks are truly cross-platform on the UI level. But, for our app, the UI layer is roughly 50% of the app. What about the core of the business logic? The code in a cross-platform framework is truly cross-platform. How do I approach that doing full native development for Android and iOS? Is there a way to create a cross-platform library?
Re: Framework 7 – Building native iOS apps in HTML5
#45I'm not knocking this or any particular xxxx-to-mobile platform, but as a native iOS and android developer, I would highly recommend just learning the native languages and frameworks. First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who know…
As someone who has used several cross-platform frameworks (Titanium, Cordova/PhoneGap, investigating Xamarin), I have a question about going "full native": how do you handle shared core code? Our app has an engine that drives the business logic, and the cross-platform frameworks have been useful because we don't have to deal with modifying the core codebase for different platforms [0]. Is it possible to create platfo…
If have read before that C++ can be used to share logic. An interesting development with iOS7 is that it has a JavaScript runtime of some sort (I don't know the details) - perhaps it will be possible to use JS for cross-platform code.
Re: Framework 7 – Building native iOS apps in HTML5
#46I'm not knocking this or any particular xxxx-to-mobile platform, but as a native iOS and android developer, I would highly recommend just learning the native languages and frameworks. First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who know…
With Xamarian being acquired by Microsoft, I'm really hoping to NOT have to learn native android / ios / windows phone development. I don't have time for that, and I'm already an expert in C#.
As a C# developer I am well into a project using Xamarin. I have not run into any road blocks and I am very happy with the performance on both iOs and Android. I currently have 80-90% shared code utilizing portable libraries and MvvmCross. Only real learning curve has been at the UI level but they are both rather WPF'ish especially Android. I highly recommend this path for a C# dev.
Re: Framework 7 – Building native iOS apps in HTML5
#47The limit we've run into with iOS is not getting a good looking UI. Rather it's the performance of Javascript in Safari. We have a fairly large one page webapp that looks great on iOS however the performance is an order of magnitude slower on an iPad than Chrome on an old laptop.
My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8 : Google). Web Views inside native apps don't get access to Nitro. Even web apps that you save to your home screen don't get access to the faster rendering engine. This is apparently for security reasons. I think it's one of the biggest barriers to web apps being competitive on iOS. (The other is that there really isn't a good installation…
[deleted]
Re: Framework 7 – Building native iOS apps in HTML5
#48The limit we've run into with iOS is not getting a good looking UI. Rather it's the performance of Javascript in Safari. We have a fairly large one page webapp that looks great on iOS however the performance is an order of magnitude slower on an iPad than Chrome on an old laptop.
My take on this is that phones are only getting faster and people upgrade their phones far more frequently than they do their laptops/desktops. Compare what you're able to do with HTML5 apps today on modern phones to what you could do even 2 years ago and it's astonishing how fast things are progressing.
Re: Framework 7 – Building native iOS apps in HTML5
#49I'm not knocking this or any particular xxxx-to-mobile platform, but as a native iOS and android developer, I would highly recommend just learning the native languages and frameworks. First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who know…
So if you want a web app, an android app, and an iPhone app, you have to code it up 3 different times in three different languages. The reason why the web exploded in popularity as a development target is precisely because it made it easier to target a larger number of customers. Imagine if Facebook had started out as a Windows XP / Linux / OSX native application. It never would have even got off the ground.
My take on this is that if you absolutely need the performance, go native and pick the platform you'll get the most customers on. If you're app is a glorified CRUD wrapper, though, HTML5 will probably suit your needs and you'll only have to code it up once.
Re: Framework 7 – Building native iOS apps in HTML5
#50Don't frameworks like this which try and emulate one platform very well get rid of the only advantage of building an app using web technologies, that it's cross platform. Apps using this will feel really out of place on Android and Windows Phone, and you'll end up spending lots of time porting the web app to those platforms if you want to support them properly.
Not necessarily. You could share the bulk of your code between platforms and use whatever mobile ui framework you want for each platform. They're just window dressing, after all. Compare this to native iOS and Android development, where very little if any of your code can be shared.