Framework 7 – Building native iOS apps in HTML5
idangero.usI'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 knows what tools will keep up with the native frameworks terms of functionality?
Another reason that is more qualitative, is that you come into contact different design styles, code styles and paradigms. Objective-C, for instance, is a tricky beast sometimes, but it is an interesting language with a lot to learn both good and bad. The new things you learn will most definitely carry over into your web programming!
The third reason to code natively, and I cannot stress this enough, is third-party library support. Maven and cocoa pods may dependency management much better on the mobile platforms, and using a third-party tool will most likely render all those advancements useless. There are some amazing libraries for both platforms that you definitely don't want to miss. They were reduce the amount of time you spend coding and improve your baseline quality.
> First, you have the absolute most control you will ever have over your application.
You have 0 control over distribution though, which is pretty important to me.
> There are some amazing libraries for both platforms that you definitely don't want to miss.
I don't doubt that the platforms have good 3rd party support, but it's absolutely dwarfed by that of the web community, and that will only grow larger over time.
> You have 0 control over distribution though, which is pretty important to me.
Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store. True that you can release it as a website whenever you want, but that's not really the same thing.
> Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
You don't have control whether your app will be accepted into the store (like the recent bitcoin apps), you don't have control whether the content in your app will be allowed in the store (such as the many Comixology comics that where banned from being sold).
> Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store.
But I don't have to put my web apps in the store at all, I just tell my users to visit a URL.
You know why it is funny? The things that native offers without even third party code is leaps and bounds beyond what web community offers for mobile and will stay this way for a long time, if not forever. So far community has been reinventing the same wheel a thousand times over and there is no sign of progress. Guys, look, another MVC framework, how cool is that!> I don't doubt that the platforms have good 3rd party support, but it's absolutely dwarfed by > that of the web community, and that will only grow larger over time.
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.
I don't buy it. Enterprises definitely buy into that idea and they do have their employees work with these crippled apps because they have no other choice. But the experience for this 'CRUD' app is definitely not good enough. It's by forcing it that it gets used. It depends on how intensively it will be used in reality, but I definitely know quite a few companies who went from BYOD and an HTML5 Cordova app which was very intensely used to just buying Android devices for the employees and making a native app to boost productivity.
If you have to enter / search / whatever information in an app which is horrible to use (a BIT of lag can ruin your day; you tap/swipe; because of the lag it just responds a bit late, the keyboard pops for the wrong field or you submit accidentally; plop seconds lost and so is your good mood) all day, you're not going to want to work with crap. It's not 'good enough' even though management might think so.
You don't have to buy it, it's an undeniable reality. Yes, if you're an enterprise and you can afford to write native apps for all platforms, then that's the better choice. If you're a small startup or a single developer, writing the app 3 times is just not cost effective.
Well then there are still a few options; 1) it's internal and you can force-feed it to your employees, then it might be ok 2) it's external and you're trying to get a lot of people to work with it outside your company.
In both cases I still think you are better/easier/happier/cheaper off building it once and in case 1) giving your employees tablets/phones with the target OS and in case 2) just waiting till you have enough critical mass to warrant writing a version for the next OS.
Not to mention that, in most cases we have made HTML5 'hybrid' apps, we noticed that it takes more time making it uniform and smooth across the plethora of (especially Android) devices than just writing 2 native versions. And the HTML5 version will just never work well on a large amount of 'Alibaba $50' Android devices which surprisingly many people have. Resulting in TONS of bad reviews (if public) and/or very frustrated people.
Depends on whether or not quality of the product is a factor in your cost calculations. It should be, and for many startups and solo developers, it absolutely is.
Most likely you never tried to do what you preach. You will end writing your app only a little bit faster (if you are lucky) and then three times more on debugging.
I have. I built an HTML5 hybrid mobile app for Android and iOS. It was about 90% JS/HTML/CSS and 10% native code. Worked very well for our purposes. You can judge for yourself, it's called Kona and in both major app stores.
Eh yeah. Exactly what I said then reading the Android reviews then? Works on some devices, terrible on most; getting that JS/HTML/CSS to work well on 'most Android devices' is infinitely more difficult than doing it native. Is that worth it? I still want to bet I could've written both apps native in a shorter time with much better results. You can take me up on that any time.
> 90% JS/HTML/CSS and 10% native code.
this was going to be my comment on the original comment: it's not like you have to do only HTML5 or only native, or so i'm given to understand... i'd be interested to hear more about the hybrid approach if anyone has links/blog posts.
10/90 is Phonegap/Cordova; when hybrid is viable (imho) is when you need to show complex documents; what HTML was made for. So the parts in your native app where you need to show documents with nice flowing text, images, charts, etc HTML is a good option, but then the 10/90 is usually not native/html, but the other way around.
Pick a platform, port later if needed. It's what most indie app developers do.
No, the web exploded in popularity as a development target because the labor pool is so diluted that it's easy, quick, and cheap to hire (and fire) any random "webdev" who is good enough for their purposes. And that's why, unless I get desperate, I wouldn't put PHP on my resume and would only list non-webapp projects for other languages I've used professionally but which are also used for webapps (e.g. python)--I don't want to put myself into that (cheap) labor market.
You are forgetting about the modern contender - Xamarin. It's a sweet spot between HTML5 and native: modern high-level language and a very decent performance.
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#.
I regret investing in MonoTouch and wish I had instead just learned native iOS dev from the getgo. You need to at least be comfortable with native iOS dev to be effective with MonoTouch anyway. I have a MonoTouch written app that I can't do anything with unless I pay for a new version of MonoTouch as it's no longer compatible with current iOS releases. The constant song and dance between releases of MonoTouch and iOS updates gets frustrating after a while.
I always recommend (and when it's about employees demand) people to first learn everything native in Objective-C/Java(/C# if you need wp8 as well) before trying to unify things with C#/Xamarin, C++ or JS. That way you have a solid understanding what is possible and you don't lock yourself in. That said; Xamarin rocks and I hope MS doesn't kill it.
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.
The language isn't the issue, the frameworks and libraries are. You're going to have to spend your valuable expert time sorting those out too. That's the bulk of it.
If your truly an expert at c# then learning objective-c isn't much of a challenge. At least learning the amount you need to build apps.
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 in all your projects and you really can focus on your idea
Put all the code in a good ui/codebehind separation framework like mvvm, and you are happier than ever.
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?
It's called C++.
And I can tell you, from my own experiences, your backend isn't going to be as cross platform as you dream of it being because everything from networking on down is done differently on Android and iOS. Which isn't to say that you can't front-end all of that with a shim in C# or C++ or whatevs, but on mobile, the bulk of the hard stuff is UI anyways and there is no cross-platform panacea as of this writing.
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.
Xamarin is great for sharing code. You just rewrite the GUI layer per platform. It's great, cannot really say it any differently.
And that GUI layer could be just Views in the end, since it seems you can even re-use ViewModels/Controllers.
This is the exact use case for Hexagonal/Clean Architecture: http://blog.groupbuddies.com/posts/20-clean-architecture
It is contentious on HN, but I implore you to draw your own conclusions.
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.
You're thinking of JavaScriptCore. It allows Objective-C objects to be used inside of JavaScript (and vice versa).
It's actually a pretty cool technology. I gave a talk about it this month at Berlin CocoaHeads, and I'm gonna put some blog posts together about it soon!
I presume the JSCore runtime bridges objects back and forth? Very cool!
>I'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 off I agree that native wins over some bundled HTML5 app anyday of the week.
But for many reasons companies still choose to use phone gap or another framework to compile HTML into a native app. The first and foremost reason is that a lot of organizations have plenty of web devs available with skills to build web apps.
Managers would rather leverage the skills they already possess. Believe me I do web dev as part of my job and I still try to make the case that Native is better for mobile. In the end it is cheaper to use developers they already have with tools the devs a familiar with (HTML/JS) than to hire several new devs to code against different mobile OS's.
Right or wrong Managers and Organizations like cheaper and faster.
Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. We need to learn from the past. Cross-platform UI is a conceptual mistake. An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It has an icon, so it's an app. The rest are implementation details that the user doesn't (and shouldn't) care about. So if the user perceives it to be a native app like all the other apps, it has to behave like one. Otherwise the user will be disappointed. Web apps that mimic native apps simply don't behave exactly like native apps: Imitating native UI with web technologies on a mobile device will only disappoint.
A long time ago when iOS dev tools were immature Joe Hewitt created https://github.com/facebook/three20. I can't find the source, but somewhere Joe is quoted that so many of the early Facebook application reviews were about how so much of it was derivative.
There is absolutely a place for this kind of library and if you pay enough attention to the details (sweat every pixel and animation) I fully believe that you can achieve an experience that would be completely indistinguishable from iOS.
Notes:
1. For this to work you should be using something like Ember as your front-end framework, not jQuery Mobile.
2. I'm not pushing this as dogma, I'm just very glad that it exists within the ecosystem.
As someone who spent years building "HTML5" JS mobile apps and then recently spending the time to learn native languages, I 100% agree. There is no way to match the performance and consistency of native with a cross-platform clone. It will always be a half-baked solution.
That being said this only applies to apps. A ton of apps shouldn't be apps, they should be well-optimized websites. For ex. content sites.
Side Note: Learning Objective-c and Android java dev isn't nearly as bad as I thought it would be. It takes less time to learn and build native instead of trying to hammer Javascript into a hole it doesnt fit into, and spending hours attempting to optimize it's performance to no end.
> Learning Objective-c and Android java dev isn't nearly as bad as I thought it would be
Where did you start? As a web developer Java and Objective-C seem really complicated and require so much code for the simplest things.
The additional code involved in Java/Obj-c is less annoying since they are well integrated in IDEs such Android Studio or Xcode which auto-generate most of the boilerplate. After you develop for a while you depend less on the IDEs.
I always build an app to learn the language/platform. The only way you can really learn it is by building something. Combined with that I usually buy a book.
For Android, I hardly had to invest any time learning Java, since I came from Ruby and it's pretty similar. Most programming languages are all the same under the surface. Especially among OO-heavy ones.
Best android book: http://www.amazon.com/Android-Programming-Ranch-Guide-Guides...
Best objective-c book: http://www.amazon.com/iOS-Programming-Ranch-Edition-Guides/d...
Both books assume you know the languages but I jumped in with limited knowledge and learned the language as I went.
I fully agree. As stated in my article http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de... I think that the web is the one place where cross-platform UI actually works. Don't destroy it by using that freedom to mimic a native UI. Plus, in quite a few cases a great mobile website would be a much better solution than an app anyway.
I totally agree. We need to learn how to use the right tool for the job. If your job is to cut down trees you wouldn't say "Well, I know how to use a pocket knife and I think a pocket knife is much easier to use than a chainsaw, so I'll just cut down trees with my pocket knife." No, you'd obviously invest a little time to learn how to use a chainsaw to get the job done properly.
I think this was true a year ago, but mobile browsers are getting better and projects like this and Ionic (ionicframework.com) are quickly closing the gap between native and HTML5.
"Never" is much too strong a word to use, but I think that it is very very very unlikely that any major mobile vendor (Apple, Google, Microsoft) will invest much time and money to make the web a first-class citizen for apps on their platform. Each company wants to offer the best experience on THEIR platform and offer features that are only available on THEIR platform so that more developers develop apps for only their platform which in turns means more sales of their products. They are interested in exclusivity.
Google is investing a lot of money with efforts like Chrome apps and Cordova.
True, but it doesn't seem to me as if Google tries to push web apps as an "as-good-as-or-better-than-native-Android-apps" approach to make apps.
True, but I do think the platforms will continue to invest in browser technology and processors will improve. I am amazed by how fast Chrome is improving and the type of experiences it is enabling.
> Cross-platform UI is a bad idea on the desktop.
Is it? At the end of the day, that's what the web is, right? Gmail (or even Google Docs) may or may not be your favorite email client, but I don't think it's necessarily a bad idea, per se.
I think you're right about user expectations on mobile. I also agree that we've all seen how terrible the UIs on some cross-platform Java and Flash applications are, but—given the success of the web on the desktop—I'm not sure it's fair to condemn cross-platform UIs on the desktop.
I agree that the web is the exception to this rule (see http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de...). I quote: "Surprisingly, cross-platform UI works on the web. People are used to it. People don't think it's odd that GMail doesn't look like Outlook or Mail.app. They don't complain that the buttons on Twitter look different from the button of the other apps they use. They are able to use Google+ and Facebook although the UI looks "foreign" in comparison to other apps on their platform. Strangely enough, all those things that make cross-platform UI a bad idea seem to be absolutely OK on the web. Why is that? It has to do with expectation. When users open their web browser, they know that they are entering a very diverse space."
It's probably better to think of the browser as another platform. In the sense that users have specific expectations about how it behaves, what it can be used for and how to use it.
Attempting to build a UI shared between, say, Windows and the browser would be a bad idea.
The web is text, alas that is too often forgotten now.
Completely agreed. However, I think you're missing a point here. The purpose for pushing cross-platform web-app-presented-as-native development memes isn't to make apps appear the same everywhere in a pretense toward common user interaction; it's to commoditize the developer labor market in these areas. It's better for companies (but not developers) if it's easier and cheaper to hire from a broad labor pool to produce mediocre-but-good-enough products.
That might unfortunately be true. However, even that is a misconception on the part of companies thinking it is "easier, faster, cheaper" to create web-based apps. Building something with web technologies that's on par with native is hard and difficult work. It's a myth that it's so much easier and faster to build an app with web technologies. It could very well take longer and still have a worse user experience. Building a simple native app is, well, simple. It might be way more complicated to build it with web technologies (if you try to mimic native).
This has already happened in web apps.
Whether you're hiring people based on experience with frameworks, or relying on Bootstrap, the central message is that you as a developer are easily replaceable. Experience is devalued in favor of what you know now. You aren't hired to think, you're hired to ship fast and break things.
I know I'm not alone in finding these terms unacceptable.
You typed your comment on a highly effective cross-platform UI, and I'm reading it on the very same. While there is a place for experiences tailored for specific devices, cross-platform UI also offers value, especially for fast prototyping and iteration.
I don't dislike the web. I dislike it when web technologies are used to mimic native apps because that creates expectations that can't be fulfilled.
Rdio pulled it off.
Its not a bad idea, its just really hard to pull off.
isn't Rdio built with Xamarin and therefor uses native UI elements ?
Login to http://rdio.com in your browser. This looks and feels way too much like the native app to be native.
They cleverly designed an application that looks like Rdio, not iOS, Chrome, or Web, then wrapped it with window chrome that hooks nicely into the operating system.
The 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 story.)
"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.
Same reason I think they're dragging their feet on various parts of HTML5 that everyone else has already implemented, such as IndexedDB.
You forgot to mention the part where Apple was first to implement features that later become known as HTML5. Also, the story of Web SQL and IndexedDB is not so simple.
Can you tell the story that explains why Apple has done nothing with IndexedDB for years while every browser vendor implemented it a while ago? Because the story as I see it is very clear: Apple embraced the web when they had very small market share, and they're doing the opposite now that they have a good chunk of the market. Walled gardens generally aren't very profitable if you have only a tiny fraction of the market.
Of course, it'll be hard for you to tell a convincing story because (AFAIK) Apple hasn't even commented on IndexedDB. Strange, for such a well-established open standard. Even MS has supported it for years!
My understanding was that Safari used JIT which is prone to security issues with how it executes that code.
As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against.
[EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.
My understanding is that you would have to mark some of the apps pages as executable, iirc, which could allow for arbitrary code execution.
That makes little to no sense.
This reeks of the same logic that caused them to disable HTML file upload buttons (there's "no" filesystem -- which is apparently why you can't even browse for photos and uploads until recent IOS).
This is what drove "there's an app for that" for so many years: Apple's systematic limiting of web apps into a severely curtailed walled garden so that the app store would -- in fact, could -- be the only source for real applications.
"Web Apps aren't as performant as native" is a direct result of such strategies.
In other words, those strategies WORKED. As with all anti-competitive practices, they will keep doing their job for a while, until something new and better (or at least workable) comes along.
What's extra fun is that when Steve Jobs introduced the iPhone in 2007, he explained that developers could write web apps if they wanted to create software for the iPhone.
I remember that, excellent point.
Ok, show me Android apps which are as performant as native. This nonsense about Apple fearing web apps should stop already.
They made poor initial design decisions which effectively put a speed limit on JavaScript apps. Currently they are not motivated to do the probably very difficult work it would take to fix the problem, that's why it's so important that the Chrome team gets its shit together and makes the speed of Chrome Android awesome (which, to their credit, is a goal for this year).
Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.
It's really easy to "fix the problem". There have been fixes on Jailbroken devices for years.
I'm not going to make an assumptions about how hard it is for apple to solve the problem, but I'm sure people writing solutions for jailbroken devices have a much greater degree of flexibility when it comes to making changes to the OS.
Nitro, to my knowledge, only optimises Javascript performance, but JS performance is not the only bottleneck. We noticed that DOM manipulation together with style and layout calculations play a big part, see http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safa...
It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.
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.
In the end HTML5 will work fine on phones. That'll take a few years yet though; currently it's shit. It's ok on an iPad, but compared to native, not so much. I like nice responsive HTML5 or HTML5 apps for stuff I use sometimes; like booking tickets, hotels, checking what's on TV and such. For stuff I click in all day long, like bugtrackers, PM systems, CRM, etc, HTML5 on mobile or desktop, is just wasting time. It's just not very nice to work with productively. This is improving fast on the desktop by building in provisions for being (temporarily) offline, easy drag & drop, offering small native plugins to interact with it, but it's not there yet.
On phones it's far from being a nice and productive experience; you can see that well when you 'quickly' check a task and end up trying to swipe something 10 times because it lags and swearing profusely. Which happens with all badly 'cross platform' written apps which are mostly HTML5.
HTML5 was supposed to be the answer when the iPhone 1 was first announced. It still sucks many years later. Draw your own conclusions ....
That's analogous to the advance of desktops. The hardware kept getting faster ("what Intel gives") but at the same time the software became more complex ("Microsoft takes away"). If you deliver software based on it performing better on future revs of hardware, you're going to get a reputation for delivering pokey software.
I don't know the details of your app, but I have a feeling that there are many places where you can optimize it.
You can't just take a desktop app and stick it on the phone. It will perform poorly.
But you have to design mobile (web) apps from the ground up relying on the strengths of the mobile platform.
One idea is to limit the functionality of the mobile app. Tasks which are very UI heavy should probably be simplified or removed.
Can I see it?
Sorry but we're limiting public access while we work out some issues. There will definitely be a Show HN when its ready for public viewing.
Tried React?
Wow what a tough crowd. So many off topic discussions. The framework is buttery smooth, and very well done. Kudos to the dev! I have never seen any html5 framework (like ionic, jqm, wink etc) nail swipe to delete row so acurately Awesome job!
Don'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.
> the only advantage of building an app using web technologies, that it's cross platform
There are other advantages of building an app using web technologies. Maybe you want to link to a store that doesn't pay Apple 30%. Maybe you want to control your own updates. Etc.
> Maybe you want to link to a store that doesn't pay Apple 30%
Isn't this explicitly forbidden on AppStore by Apple regardless of technology?
> Maybe you want to control your own updates.
This is what some games do, you don't need HTML/JS for that.
Right, that's an app store rule. However, if you've got an HTML 5 app you don't need to install it through the app store. For example, forecast.io.
I'm not sure what you're saying about games controlling their own updates. What I was talking about specifically is that a web app can update at any time, without the vetting process required of apps in the app store. My understanding was that app store apps couldn't download and execute new code.
And simultaneously, you loose the main benefit of a native app, which is being able to draw on the work of all the really smart people who work on the native frameworks.
I guess if you're doing something that browser technologies are better suited for than native code, it might be a more pleasant developer experience. It might be fun to build a meteor app with something like this, for example.
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.
I wanted to enjoy this but I opened it on my phone and was immediately cursed with problems.
- When I scrolled the list items where my thumb was scrolling started lighting up
- When I clicked a button nothing happened, I had to click a few times repeatedly before it changed screens and even then it didn't feel like I clicked
- When I clicked back nothing happened, and after a couple more tries I saw it was working and then changed the page. That might could be solved with something like fastclick.
I would love a tool like this but it has to be damn near perfect for me to be able to consider it with my team.
EDIT: After playing with it a little more I found it gets a little better. The big issue is lag and fluidness for me. It's got to be very responsive to touch and movements and not have any lag or choppiness.
The problem with HTML5 is and always will be performance, not because of HTML5 but because of the platform it sits on. The DOM simply can not perform with the efficiency of native applications. I'm more hopeful for companies like famo.us that have basically subverted the DOM renderer for their own Unity-style game engine. You can see demos of their projects at http://demo.famo.us/. Running those on your phone will give you an idea of what a truly native web experience should feel like.
All of these attempts to make a web page run fast on the phone are all bound by one single performance constraint; Document Object Model.
Very impressive! One of the best mimics so far. Performance is good and very lightweight. Might use this for prototyping an app.
The title should say, mimics native iOS UI in the browser. Nice job though.
This. I like the look of it and it's still useful, but we need to stop abusing the word "native." Let's be clear that this is just an html framework that looks like a native app. It's still a website.
This is not the same thing as Phonegap, for example, which lets you build a native app you could install from the app store.
Again, still useful if you want your mobile website to look native, but not the same thing.
This is a webview app not a native app.
I played with this just now on an IPod Touch and must say that it is incredibly smooth. It could easily be mistaken for a native app.
I've had quite a lot of luck developing HTML/JS apps in Sencha Touch (very basic CRUD apps of course). Really noticed a speed improvement running the latest release on an iPhone 5S. Not sure how much room there really is for HTML/JS ports at this stage. Titanum was a let down for me. Am keen to try Xamarin next. Or just go native? Thoughts?...
Very impressive. As someone who uses Appcelerator a lot, this makes me rethink the ability to prototype and app quick and wrap it with Phonegap, or a similar strategy.
Colors, spacing, swipe translations are all very solid. While a majority of everyone else here complains about pixels and the right words to use, I'd like to congratulate you on this.
Nice work.
Suggestion: Add the new iOS7.1 "minimal-ui" key to the viewport tag.
It makes the top bar a lot smaller and makes it fullscreen in landscape mode. Much nicer for an 'app-like' experience.
<meta name="viewport" content="width=device-width initial-scale=1.0 maximum-scale=1.0 user-scalable=yes, minimal-ui" />
minimal-ui is a god-send. Without it, bottom-screen tab bars in web apps are effectively unusable.
Native apps in HTML5 is an oxymoron.
It's important to add words like "native" to main product description tho. Adds credibility. It's ok that this is completely NOT native.
The only native apps in HTML5 are probably some of those Win 8 apps. If you think about it HTML5 is just a quirky version of XAML and the latter is supported in Win8 very well. Maybe OS itself should give a choice of layout engine.
Just tried it on Android (Chrome, Nexus 5, 4.4.2). Very smooth, but the sideways page-to-page transition was incredibly stuttery. It also doesn't handle the "back" button the way I'd expect from something like this.
Yeah, this is shiny and cool. But not native.
True. This is different to how Appcelerator Titanium does it - which does build native apps with native components, despite the code to build the apps being written in JavaScript.
They did a nice job on this framework, but I think it is a fundamentally wrong approach. Here is why: http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de... Or, if you prefer a video: http://vimeo.com/32256530
I'm baffled that a technology stack (HTML, JS) that every single web developer think is broken (but still have to deal with) is being considered for iOS development, and being promoted as an easy way to develop native apps.
This is where I think RubyMotion offered the best of both worlds: native APIs and Ruby's flexibility (even if Objective-C is really not that bad or hard to learn).
Web Dev here. I don't think the stack is broken.
Positioning elements, fighting to implement the support of multiples screen resolutions, dealing with JS quarks, etc. All those topics are mastered in most native frameworks and clearly a hot topic in web dev.
Maybe broken is a little bit exaggerated, but very well deserved IMHO.
After several years in web dev _and_ mobile dev, I can safely say that even in a couple of years, native toolchains won't be relegated to a marginal role and remain the only efficient way of developing native apps.
I remember that you built this in the Static Showdown hackathon! Congratulations, and it looks like a really promising project :)
I'm very impressed with the page transitions. They're pretty spot on.
Havent got the toggles right though. The stretched out dot is not it moving into another position, it's the result of you tapping it. If you tap and hold, the dot shoud expand out.
Correction, "Native look & feel". But well made!
So the "Download" button is a regular link to the GitHub repo. Ugh, not a smart move.
Ok, so the technical details are:
* JS file (minimized): 33k * CSS file (minimized): 62k
I would say best used as a web app that one can use along side a native app IE Gmail, which has an ok mobile web app and a good native app.
Was anyone else disappointed when they opened it on their iPhone and it rendered the same page?
Congratulation! You have managed to create a web page where even links no longer work. Okay, that is a bit of an overstatement - open in new window, download and probably also the social media links do work.
There is nothing native. Go home and read a books.
nice, but where are the docs ?
really cool I think !
This is honestly so pointless and bad for the community, further dividing up mobile technology. Why not just improve on something that already exists like jQM?
"Building native iOS apps in HTML5". You're building them in HTML5, to look like iOS7, not exactly native now is it? This is the same thing as making a theme for jQuery Mobile.
I clicked on this hoping to download something that converts my HTML5 app to native code, but then I clicked this, and immediately had severe performance issues on iOS7, iPhone 5S.
I really hope this does not take off, and if it does, I hope they fix the performance ASAP.
Not even REMOTELY close to native performance, look, or feel.
Did you ever try jQM? My god. I applaud any efforts to move away from it.
JQM is so unbelievably terrible. Been working with it for the past year.
I'm so sorry... I have seriously not often in my 30 years of being a coder seen something so promising turn out so bad. It doesn't even get the 'hello world' right. Why have you been working for it for the past year?