Framework 7 – Building native iOS apps in HTML5(idangero.us) |
Framework 7 – Building native iOS apps in HTML5(idangero.us) |
"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.
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.
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.
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.
> 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.
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.
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.
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.
[0] Despite the many claims of "cross-platform UIs," we have many cases in our UI layer of doing different things on different platforms.
It is contentious on HN, but I implore you to draw your own conclusions.
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.
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.
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.
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.
- 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.
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.
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.
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.
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" />
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).
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.
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.
Ok, so the technical details are:
* JS file (minimized): 33k * CSS file (minimized): 62k
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.
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.
Where did you start? As a web developer Java and Objective-C seem really complicated and require so much code for the simplest things.
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.
Attempting to build a UI shared between, say, Windows and the browser would be a bad idea.
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.
Its not a bad idea, its just really hard to pull off.
it would be interesting if they elaborate on those...
Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.
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.
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.
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.
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.
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.
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.
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.
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!
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.
Put all the code in a good ui/codebehind separation framework like mvvm, and you are happier than ever.
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.
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.
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.
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.
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!