Hybrid vs Native: Choosing a Mobile Strategy
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
French, Jeff
In today’s mobile-first world almost every company has realized the need to connect with consumers on mobile devices. Now you, the developer, must figure out how to build it! Objective-C, Java, Xamarin, PhoneGap, Appcelerator, Icenium: there are so many ways to build a mobile app today, how do you choose? In this session I will cover the pros and cons of native app development and HTML5 hybrid app development to help you make the right choice based on the needs of YOUR app.
 Can you guys hear me okay? Yeah, good? All right. So good morning. Welcome to the first session of NDC 2014. Glad you guys made it out. My name is Jeff French. I am a mobile app developer. Been doing mobile apps exclusively for about a year now, off and on for a few years before that. So let's start by kind of finding out more about you. So how many people in this room have built a mobile app before? Okay, maybe half. Out of those, how many built a hybrid app? Okay, a few. Native app then? Okay. So how many of you are about to start a mobile project in the next six months? Okay, looking for some timely advice? Great. So we're going to go ahead and conduct this session in a little bit different fashion. I'm going to start at the end and then we'll go back through the beginning and the middle and figure out how we got to the end. So let's do that now. There you go. If what you came here to here was someone stand on stage and tell you to choose hybrid or choose native, this is what I'm going to tell you. If that's all that you were after, great. You got time to go catch somebody else's session. If you want to know why, I'm going to tell you that. I'm going to stick around and we'll go through it. And I'll take you through. You know, my experiences in delving into hybrid app development and why I think it's the right choice. So for starters, am I a hybrid fanboy? Yeah. Have I ever built a native app? Nope. And does that make me grossly under qualified to advise you on this subject? Maybe. But no. Really, it just means that I have already kind of done a lot of this homework. I've, you know, I'm going to let you know my experiences in spelunking through all these Google results and sifting through all these blog posts and trying to figure out, should I invest in learning a native technology or make use of the existing web skills I already have, right? Like, I'm going to be a hybrid fanboy. I already have, right? Like the upfront trade-off seems pretty obvious, right? Because you say, well, if I've already got web skills and I can use those technologies to build a mobile app, then it's going to be better, right? But that may not be true. Now, I've gone through this kind of research cycle, I guess, a few times over the last three or four years. And every time I've come to the same conclusion, I always keep coming back to hybrid apps. And every now and then I say, yeah, you know, well, maybe, and then I go back and I start thinking about it again and I start doing the research and trying to figure out if there really is an advantage to going native, and I always come back to choosing hybrid. So TLDR, choose hybrid. So let's go back to the beginning and start by kind of defining some things. What is a native app? What are the components of a native app? You're going to find a native app is going to have a platform-specific language. You're going to be using a different language for pretty much every platform that you need to develop for. So if that's iPhone, Android, Windows phone, there you go, three languages. Three UI designs that you have to build. Three UI design languages, I guess you could call them, that you're going to have to learn. Cocoa and XAML and whatever that thing is on Android. You're going to have to go through and build out a UI for each one of these platforms that makes sense for your app. And you're going to have to build it three times, four times, however many platforms you've got to go to. And as you're building the same app to solve the same problem for your end users or provide the same value for end users on all these different platforms, when you're building a native app, do you know how much code reuse you're going to get? Zero. You're going to have to do everything on all of the platforms that you need to deploy to. You're not really going to be able to share much logic. I mean, yeah, you might say, well, if I'm building something that's more of a thin client and I can put the logic on the server through an API, yeah, absolutely. And that's going to be true of any mobile app you build hybrid, native, or otherwise, and really any other app. If you can centralize some of that logic into an API, that's definitely going to get you some more reuse. But on native apps, your actual device-specific code is not going to get much shared usage. So these things here, Objective-C slash Swift now, if you saw yesterday's announcement or two days ago announcement, Java, XAML, if any of those terms give you heartburn, if you have built something with XAML for Windows Phone 7 and now you suffer from post-traumatic shock syndrome, native might not be the best choice for you. OK? So let's look at the anatomy of a native app. Here's what you're going to end up having. On every one of these, in some form or another, you're going to have this stack of view that has your UI, some type of a view controller that's going to present that UI, some business logic that's underneath it. And as you can see, they're in silos. We're not sharing anything across them. We're having to solve the same problem multiple times. All right? So on here, that's your problem. OK? In each one of these, your problems are being solved multiple times. OK? Now, you're going to be challenged with trying to build a somewhat consistent UI for your users. That makes sense. If you've got users who switch from iOS to Android and they're using your app, you want them to understand how to use your app already. They shouldn't have to relearn it, just because they're on a new platform. You're going to have to have feature parity, not only in your initial development, but in your ongoing development as you continue to try to add value to your application. You've got to add it on three platforms, considering that's all of the market right there. But if you're doing BlackBerry, have fun with that. You're going to have to solve that same problem, every business problem, every UI problem, all the great stuff that Luke was just talking about out there with designing for good user experience on a mobile device. Well, now you've got to figure out how to replicate all of that across all the platforms that you go to. OK? So you're going to have to solve your problem n times, where n equals the number of platforms you need to deploy to. And you're also going to have to overcome multiple learning curves. Unless you were already born an expert in all three of these mobile platforms, you're going to have to go out and learn these technologies. Or you're going to have to go out in higher teams that already have these technologies under their tool belt and can be effective at building them. So what's a hybrid app? Well, one thing all hybrid apps tend to have in common is a native web view. There's a web view in every mobile SDK. They've got some way for you to display a web page. And hybrid apps take advantage of that by having a native web view that lets you present an HTML and CSS and JavaScript-based UI inside that web view. And it doesn't look like a browser. There's no Chrome around it. It's just a full page most of the time, unless you want it to have a toolbar. They're going to have a JavaScript API that's going to let you access native functionality. So when you want to get to native device capabilities, such as a camera or access to an NFC chip or GPS or the contacts on a phone, they're going to have a JavaScript-based API that's going to let you access that in a consistent manner across all the platforms that you deploy to. And as discussed, we're going to have an HTML5 and CSS-based UI. And JavaScript can be in your UI as well. And that means that if you already know how to build web pages, which quick show of hands, who knows how to build web pages? Yeah? Pretty much everybody. That's good. Congratulations. You already know how to build a UI for a mobile app then. Are you going to have to learn some mobile UI paradigms that make use of HTML5, of course? Maybe you already know some from building mobile web apps. But the really nice one is your code reuse. When you choose to go down the path of hybrid apps, you're going to get close to 95% to 100% of code reuse across your platforms. And that's going to skew more toward the high end of that number for most apps. Now, you're not going to get that with a native app. So let's look at the anatomy of a hybrid app. They're going to look like this. You're going to have a native web view and native API and a unified JavaScript API that goes across all those. And then you're going to have JavaScript-based app logic, and HTML and CSS-based UI sitting on top of that. So here's how that breaks down. Those top two, those are your problems. All the bottom ones are somebody else's problem now. Not yours. You're going to lean on a framework, such as PhoneGap or Senka Touch or something, where they are building out the native web view. And they are integrating the native APIs and exposing them via a common JavaScript API. And all you have to do is write one code base. Whenever you want to get a picture from the camera, you just say navigator.camera.getPicture, depending on whatever kind of framework you're using. And whether that code is running on a Windows phone or an iOS device or an Android device, it's just going to work. And you don't have to care. All those differences in the platform are nicely and neatly abstracted away. So you don't have to worry about them. Because last time I checked, unless you're actually building one of these native frameworks, the details of how to get a picture from a camera on three or four different platforms is probably not the business case that you're solving. It's probably not what your app is intended to do. If your app's primary function is to figure out how to get a picture off of a camera, OK, yeah. Maybe it makes sense for you to write that native code. But probably not. Probably you're building some sort of a social app or maybe a line of business app. And you need to grab the user's location for something. You don't want to have to worry about how to write that on six different platforms. You just want to have one nice call that says, well, just give me the location. This is very similar in concept to something like the.NET framework. You can go ahead and write lots of Windows-based code in C or C++ that makes use of native low-level Windows APIs. Or you can use the.NET framework and be way more productive. And then you can also know that some other engineer who probably has more time and experience in optimizing native API calls in the Windows framework has optimized that and exposed it to you in a good way in the.NET framework for most of your use cases. That's the same concept with the hybrid app. You're kind of standing on the shoulders of giants by letting a whole team of other developers who work on something like, say, PhoneGap that have a lot of experience in building this native piece of the code so you don't have to. And it's also going to come back to, see how we've got JavaScript app logic up there? That means that you notice it's one big pink block across all the platforms. You have to solve your problems once. And yes, some of those are going to be solved, like we said before, at the API level up on your server. But if it's a local device application, if it's something that's offline and you don't have access to a server, it doesn't make sense to have an API, you still only have to solve your problems one time. And the same goes for your UI problems as well. When you start designing out a UI paradigm, you're going to be able to reuse that across platforms and then just tweak it ever so slightly as needed for each platform. There's a gray area that exists between native and hybrid. So this gray area is what we would call transpiled applications. A transpiled application is going to be something that you write code in one language and it gets transpiled down into another language. So examples of that might be something like, say, Xamarin, where you write C sharp and it gets transpiled down into Java or Objective C or whatever else to run on all these different platforms. Now, in these transpiled apps, you're still going to have some of the advantages of kind of like a hybrid app in that there's going to be native device APIs that are exposed in a common language. Hybrid apps do it with JavaScript. Some of these transpilers do it with JavaScript, like, say, AppCelerator. Some of them do it with C sharp like Xamarin. You're going to have common business logic across your platforms. So once again, we're getting that nice advantage here of being able to solve your business problems with one code base one time and have it work on all the platforms, which is very nice because as a developer, you probably, like I do, adhere to the kind of philosophy that, well, if I have to do something more than once, let's automate it because I don't want to do it three times. Same thing with building a native app. Why solve the same problem three or four or five times when you can solve it once by using a better set of tooling? Now, most of these transpiled applications, you're going to have to build a platform-specific UI. Now, these are going to be usually in the native UI language and tooling of the platform that you are trying to target. So typically, you'll have to build out a cocoa-based UI for iPhone. You don't have to do your Android thing. You don't have to do XAML. Now, that's not 100% true. Some of them, especially if you saw the release of Xamarin. Forms, they've released a lot of nice cross-platform UI components. But you'll probably still have to dip down into native UI stuff in order to use most transpiled mobile app frameworks. So code reuse. Transpiled apps do get a lot of good code reuse. You're still probably going to get, on average, I'd say, about 70% to 80% code reuse by going this way. Most of your business logic is going to be there. It's going to mostly be UI code that you have to, that you're not going to be able to actually use between the things. Now, that still leaves you in that area of having to solve these UI paradigms on your own. To solve these UI paradigms on multiple platforms. So you're still going to have to figure out how to make this work on each one of these platforms and how to plug it in to your transpiled app framework. So like I said, some examples of the transpiled apps would be Xamarin, AppCelerator, Titanium. I haven't built a full app with either one of these things. I've maybe done about Hello World on each one. And they definitely have some potential. But again, I've always fallen back to doing a straight up hybrid app with something like PhoneGap. So when should you choose native? I've spent this whole time up until now telling you, well, you shouldn't. You should just choose hybrid, right? But that's not always going to be the use case, right? There are times where a native app is the way to go. One of those times is when you only care about one platform. If all you care about is having your app on Android, then whatever, just build it on Android. If your app is highly dependent on a feature that only exists on one platform, right, for a long time, NFC was only on Android. And if you were building some sort of a mobile wallet app that used NFC for payment or something like that, OK, build it on Android. There was no reason to go to iOS or Windows Phone at that time. Or the big one is when your app uses heavy 3D rendering, you're building a game or something that's going to have a really, really intense 3D UI, you're probably going to get a lot better performance by going native with that. But the caveat is none of those reasons mean that you have to choose native. You can do all of those things with a hybrid app. I've shipped many hybrid apps that are only on iOS. But it was faster and easier and cheaper for me to build it using PhoneGap and some other UI frameworks and ship it. And now if the client comes back to me and says, oh, man, we got to go Android and say, OK, cool. We can do that tomorrow. Just got to run a build script. We're done. And they go, oh, wow, that's cool. 3D rendering, you can do a lot in the browsers and web views that are available today. Most of them have OpenGL. And you can build a lot of really intense 3D games using nothing but JavaScript. You can also do this in transpiled apps. I talked to a guy who had used, I think he had used Xamarin and built a fully 3D UI. And he didn't care about having to redo his UI on every platform because he wasn't making use of any native stuff anyway. It was all his own UI. So he was able to reuse one set of UI components across all the platforms as well because of the way he had to build it. So why is hybrid good for the 95% use case? Most of the time, you're going to find that a hybrid will probably suit your needs. So a lot of people are building line of business apps, which end up being lists. You don't need a native app for that. You can do nice, rich UI in a hybrid app as well. So hybrid apps are good because they're going to have native functionality available to them via plugins. If there is something that you can't do in HTML and CSS, you can write a program that's not available to you. In HTML and CSS, you can write a plugin for it. But even better than that, most of these frameworks already have big plugin ecosystems where other people have already contributed plugins that will probably meet your needs, or at least serve as a good starting point for writing your own plugin. Some examples of that would be things like barcode scanners, GPS contacts, camera, NFC, Bluetooth. There are tons and tons. Facebook and Twitter integration for authentication, being able to build SMS text messages in the device's native format and actually send them out. There are tons and tons and tons of plugins out there that will give you the native access you need. And even if you have to write your own plugin, you're now only having to write and maintain this much platform-specific code on each platform instead of 100%, instead of the whole thing. The other reason that they're great is that there are a lot of frameworks out there to help you build good, close to native, or fully native-looking UIs on each platform. And also give you a lot of the same native behaviors people expect on your platforms. A few examples of this are like Ionic, Senka Touch, Kendo UI. Some of these take different approaches. I've been using Ionic to build a lot of apps lately, and it's been really, really nice. It's heavily integrated with AngularJS, and single-page apps are great for building mobile apps. So Ionic gives you a lot of cool stuff, such as behaviors, in that they've got AngularJS directives to build out a list that automatically has swipe to edit and delete, and have all those native UI paradigms that your users are already accustomed to available to you without you having to write all that extra code to figure out how to do it. And it's going to work on all these multiple platforms. And then because it's just CSS and HTML that's used to style the UI, now you can tweak it and make it look right for your brand and match what your users are going to expect. OK? A phone gap has always been my hybrid platform of choice. And they have a ton of plugins. Now, a phone gap plugin and most hybrid app plugins are going to consist of the same thing. You're going to have native code written in the platform that you are developing for. So Objective-C or Swift for iOS, Java for Android, C-Sharp for Windows Phone. And on top of that, you are going to expose a JavaScript API for your plugin, which then gets kind of exposed through that common JavaScript API that we saw on the slide before. So this lets you build out a scenario where you only have to write, like I said, a little bit of code for a given platform and still be able to access full native functionality in that area, which is way better than writing it for every platform. So if any of you have already been doing any research into hybrid versus native, you've surely come across a ton of stuff on the internet about how hybrid apps don't perform as well as native apps. This is one of the first things that I came across when I started looking into it. I said, oh, that seems too good to be true. And sure enough, I found a whole lot of blog posts telling me, yeah, it is too good to be true. The hybrid apps don't perform well. Well, I think you're going to find, if you go and look at that, that, A, most of that is based on hybrid technologies that existed around 2010 when they kind of started really coming into popularity. They weren't that great. Like a lot of software, they didn't come out of the gate killing it. They took some time to iterate and figure out how it was the best way to do things. And I can tell you that the hybrid solutions that are available today, this is not a statistic that I have a benchmark on, but in 90% to 95% of the use cases, they perform just as well as native apps. So when you are going out and conducting your own research on this topic, please make sure you check the dates on those blog posts and really kind of go investigate the frameworks that you're looking at and figure out, well, have these people made any progress in the last four years? I sure hope they have. Now, you're also going to come across the Facebook story. Facebook, very famously a couple of years ago, ditched their HTML5 apps and went to native apps. And I even saw a quote from Mark Zuckerberg that said that betting the farm on HTML5 was one of the worst strategic decisions that the company ever made. Maybe it was just feeling pressure from the IPO. I don't know. But I will say this, should you do the same because Facebook did? No. I've done a lot of looking into that because it was a really big driver for me when I first started looking at hybrid apps and saw that Facebook was ditching their hybrid web view-based application to go native. I said, oh, man, if it's not good enough for Facebook, it's probably not good enough for me either. Well, first thing is then I remembered, oh, yeah, I don't have Facebook's problems yet. One day I'll have billions of users on my app and then I'll have Facebook-level problems. Today I don't. Then I came to the realization, if I built a hybrid app and got to Facebook scale, hopefully I would be making enough money that I could hire teams of engineers on each one of these platforms to build me native apps, just like Facebook did. If not, then maybe there's more of a problem with my business model. Maybe I have done something wrong upfront that caused this problem. Now, I don't know a whole lot about Facebook's actual implementation, but from what I've read and what I gathered, I was able to draw some pretty interesting conclusions. Remember this slide? Remember how I said that the things at the top are your problem and the things on the bottom are somebody else's problem? Well, this rule only applies if you actually choose a mobile framework, like, say, PhoneGap or Senka Touch, where other engineers are building the native components and giving you a place to plug in your HTML and CSS. Now, from everything I've read on the Facebook situation, they didn't take this approach. They decided they would build their own native container with a web view to display their HTML stuff in. If you're going to go that far, you may as well build a native app, because now you are in charge of all of the native code that displays your web view and making sure that it's patched for security and that it's performing well and that you're keeping up on all the SDKs. You've already taken on the overhead of native app development at that point. You've already had to learn the language. You're probably not getting a whole lot of gains out of doing a hybrid app if you are building your own web view on each platform. Now, the other thing with regards to our performance myth is I will tell you right now, having never even built a native app, that it's just as easy to write crappy code in a native language as it is to write crappy code in JavaScript. Ever been is easy. In fact, if you are maybe an experienced web or JavaScript developer and have never touched a native language before, I would say it's probably even easier to write crappy code in a language that you're new to. I mean, how many people here have spent a lot of time learning how to optimize your web view? How many people have learned how to optimize for the platforms that you build for? If you write.NET code and C sharp, you've probably learned a lot over your years of experience. That's why we look for developers that have five plus years of experience for things. Because we know that they've already learned, or hopefully have learned, how to write better code in that language and how to get more performance out of it. So if you have already spent a lot of time, especially if you're a web developer who has already spent a lot of time really good at optimizing your HTML and doing smarter and more efficient DOM manipulation and writing good effective CSS selectors and writing good high-performance JavaScript, you're probably going to be able to write a good, well-performing hybrid application using those skills. Those skills are going to transfer right over into your hybrid app development. However, if you have never written Objective-C before and you file new in Xcode and start building out a native app, there's a very good chance that you're going to do a lot of things wrong or do a lot of things poorly. It's the old saying that the first step to getting good at something is sucking at something. Well, oftentimes in mobile app development, time to market is critical. If you can get out there first with your idea, you're going to gain some mind share and some market share. Well, if you've got to go build something really, really fast on three brand new platforms that you've never touched before, there's a good chance you're going to put out crap. But if you can leverage existing skills that you've already spent time developing, you've given yourself a much better chance of putting out a good, well-performing application. So our conclusion here is that you should choose hybrid. I told you I was a fanboy. Now, as we've said, there's a lot of reasons that you might choose something other than hybrid. But if you're going to go down that path, I really, really want for you guys to go down that path with your eyes open. Understand the caveats, because it's easy when you're jumping out into a new language to find a lot of let's get started. Here we go. Quick start tutorial on Android development. And it's going to have you build Hello World. And you're going to say, OK, that wasn't too bad. I mean, I had to struggle through some tool installations and some configurations and maybe a little bit of language learning stuff. But I got Hello World out the door in a day or less, so it can't be that hard. Just stop to remember the first time that you wrote Hello World in your favorite language. You wrote it, and you probably learned a lot since that first Hello World. So don't throw that out the door, especially if your language of choice is already JavaScript. Don't throw away that skill set, just because some random blog post from 2011 says that Facebook had a problem with a web view. That's not really a good reason to go that route. So at this time, I'd like to go ahead and just open it up for questions. Generally a lot of questions at the end of this talk. Go ahead. OK, great. So the question is, out of the stuff I've mentioned, what kind of concrete examples can I give of stuff that I've used? As I said earlier, every time I've looked at stuff, PhoneGap has been my tool of choice for building these hybrid applications. And it's the only thing that I've actually shipped something to the app store in. And it's been my experience, especially since PhoneGap went from 2.9 into the 3.0 era. They made huge, huge gains in the way that they handle their framework and performance. And it's gotten us a lot closer to a native app type experience. As far as Xamarin, like I said, I haven't done anything beyond, say, Hello World using Xamarin or Accelerator Titanium. So I can tell you that my experience in those, in writing Hello World, was such that I felt like I wasn't going to get enough gains out of investing in learning their system. With PhoneGap specifically, I found that I didn't have to learn very much new stuff beyond HTML and CSS and JavaScript. It was very much about building a web app that could run on a device. But so I don't have a lot of good, I don't have a lot of good negative experiences to tell you about because I don't waste my time on negative stuff. When I feel like there's nothing there, I bail out. But excellent question. Did I answer that? OK, great. So any more questions? Yes? What are some high profile? Excellent, excellent question. I actually had a bullet point on here, and I forgot to bring it up. So with PhoneGap, I was just looking this morning, and a couple that I found as high profile examples were the BBC in the UK did an Olympics app for the Summer Olympics. Or no, maybe it was just recently, Winter Olympics, whichever one. I don't know, I'm not in the UK, so I didn't get to use the app. However, it was featured on PhoneGap's featured app page to show that the BBC had built this thing. And it looked beautiful. And it was available on iOS, Android, and BlackBerry. That was the platforms they decided were important to them. And this app had 24 live streaming feeds of the Olympics. It had social integration, it had medal rankings, it had a page for every sport, a page for every country where you could go see all this stuff. And obviously, if it's put out by the BBC to allow people to use it, I don't know what their usage numbers were, but I got to guess, there was a whole lot of usage, a whole lot of simultaneous usage. And again, the thing you remember on mobile apps is simultaneous usage doesn't really amount to anything except for server load. Everybody's using their own device. But another one that I see, has anybody here ever used Untapped? No? Craft beer drinkers? No? OK. But it's big in the States anyway. And it's another one that is available on iOS, Android, and Windows phone, and has great experiences. And to be honest with you, I've used the app for probably a year now. And until I looked it up and noticed it on the Phone Gap page, I had no idea it was a hybrid app. Like, I've been using it every day, or not every day, but a lot over the last year, and had no idea that it was a Phone Gap-based application. And I was like, oh, OK, cool. Well, that's good to know. So now there are other, one of the ones that I here pointed out a lot as an example of hybrid apps, but it's not Phone Gap, to my knowledge, is Instagram. Now, Instagram is still, as far as I have guessed, in the same boat that Facebook was with their HTML implementation. I believe that they have a native app with their own web view, and so they load up native navigation, and then the actual pictures and posts that you view are loaded in a web view. Now, again, they have taken on the task of writing, essentially, a native app. Probably the only reason they showed in a web view is because it's a real easy way to load a bunch of pictures and text into your app, because those are coming live from the web, which is actually a really good, important point to bring up. When you are building a hybrid app, especially with something like Phone Gap, a common misunderstanding or pitfall that people get into in the beginning is they say, well, I've already got a mobile website, so I can just take Phone Gap and create this little container that will load up the mobile website I've already got on my server, and it's just going to work. No, it's probably not. Phone Gap is going to require at least the first bit of HTML to be on the device. And you're going to get the best experience by serving all of your JavaScript and HTML and CSS from the device itself. If every time a user clicks on something in your app, it has to make a web request, just like they're in their browser. It's going to feel like a website, not a native app. And that's one of the areas where, when you go down that path, it creates a hybrid app that doesn't feel native. Now, one of the advantages of a hybrid app is that we've all heard the horror stories about it taking two and three weeks to get something approved on the Apple App Store, and you've still got to get approval to do it and everything. A hybrid app can actually give you a little bit of a way around that, in that you can ship one version of your application, but on startup, you can go download. You're free to just go download fresh HTML, CSS, and JavaScript from your server. So you can build what amounts to a local application. But on startup, you can say, well, let's just go check and see if we've got any updated JavaScript. Maybe you fixed a bug, and instead of having to submit to the app store, you just ship the JavaScript file up there, and your application automatically says, hey, let me go grab the latest assets and bring that down and use this locally. And now you've just shipped an update to your app and fixed a bug that was plaguing your users without having to wait for Apple to approve it or anything like that. More questions? Sorry, these spotlights are hard to see. Yes? OK, yeah, great question. So the question is, with all the different screen sizes and resolutions and portrait versus landscape and rotation, is that something that's better addressed with platform specific UI or with a hybrid solution using CSS? I very much think CSS, especially with CSS3. Your advantage in building a mobile app is that even the worst mobile browsers are better than IE8. So you get to use CSS3 and media queries and really smart selectors, so you can actually customize your UI to handle all of those different screen resolutions and the rotation between them very, very well by writing CSS. Now, if you don't already have a good, strong, responsive design background, yeah, you're going to have to learn it. But which do you feel like is a more worthwhile investment? Learning how to solve the same screen resolution and UI problems on two or three platforms or learning how to solve it using CSS, which, hey, that also applies to the web where a lot of stuff goes on. So to answer your question, yes, I think that those are very well-addressed in hybrid apps by simply using CSS and JavaScript. One of the frameworks I mentioned earlier, Ionic, it does some really nice stuff on startup, whereby it does platform detection, and it slaps CSS classes onto the body tag of your HTML page that says things like platform dash iOS, platform dash Android. And it even assigns grades to these platforms, like grades A through D, based on the capabilities of the hardware. So you can very, very easily, with just CSS, change the layout of your application for a specific platform, maybe disable animations on a lower grade device that's not going to handle them very well. You can do all of that very, very easily by utilizing a lot of these tools. And it actually brings up another great point in that one of the ways in which you can really get more leverage out of your hybrid app is by also making it a web app. But actually, I think Luke was just talking about this in the keynote, that there's a lot of companies that have both a native app and a mobile web experience, and they end up being complementary. When you build, especially like a phone gap app, you're building a native web app. You're building a mobile web app that happens to run on the device. And if you take a little bit of an intelligent approach to it up front by doing a little bit of detection to figure out, hey, am I running on the device, or am I running in a website? You can present the same UI. I've actually done this before with an app that I shipped to the app store, and we had a mobile web version. It was one code base. And so when the users landed on this mobile version of a website, they got the exact same experience as they did in our app that was on the app store. The only difference being that I had a barcode scanner in this app. Well, I can't do a barcode scanner from the web. So all I did was check to see, hey, am I in phone gap, or am I in the web? If I'm in the web, then whenever they clicked that button that would normally bring up a barcode scanner, it said, well, just type in what you're looking for. And maybe you could do it without typing, like Luke said. You could do something more intelligent. But the point being, now you can not only go to all these multiple platforms, but you can also go to the web. Because as you get into native app development, you're going to find that one of the challenges is, now you're expecting your users to install an app. I work for a company that makes a shopping app. Or we used to make a shopping app. Now we only make a shopping mobile site. Because the idea of getting a customer to walk into a store and download a third party app in order to do some additional shopping was too much of a bridge to cross. But I didn't lose any time, because I built all this in phone gap, and I was able to take that code base that I was already using for mobile web and just ditch the native app side of it and only use it as mobile web. We didn't have to backtrack for months and months and months to recreate this as a mobile website. So it's one more advantage of a hybrid app is that now you already have a mobile website available. Yes, sir? How do you handle offline functionality in the network app? Do you use local storage? That's a great question. So how do you handle offline in, say, a phone gap app? There's a lot of ways. Yes, local storage is my favorite. I typically am using just HTML5 local storage to do a lot of things. There are also plug-ins that you can use, such as CouchBase. If anybody's used CouchBase before, they now have a mobile plug-in that has a sync back-in built into it. So it kind of will automatically do some stuff so that you've got CouchBase on your server. You've got a CouchBase plug-in in your mobile app. And whenever you fire up your mobile app, it kicks off a sync in the background. It starts pulling down background data. And then we'll do the same thing. Whenever you lose a connection, it'll go ahead. And as you continue just interacting with your local app, whenever a connection is available again, sync it back up to the server. And you can also just build your own solutions for this in that there are phone gap, for example, raises events that says network connected, network disconnected. So you can get those events and you can start handling them in your code to say, oh, OK, I need to switch this into offline mode, or I need to switch back into online mode and sync any offline data that happened. So yeah, offline is absolutely something that you can handle very well in a hybrid app, just like you can in a native app. More questions? No? All right, well then, my name is Jeff French. You can follow me on Twitter at Jeff underscore French or check out my blog, geekindulgence.com. And if you have any additional questions that come up after this, feel free to hit me up in one of those two places. Thank you very much for your time today. Thank you.
 Can you guys hear me okay?  Yeah, good?  All right.  So good morning.  Welcome to the first session of NDC 2014.  Glad you guys made it out.  My name is Jeff French.  I am a mobile app developer.  Been doing mobile apps exclusively for about a year now,  off and on for a few years before that.  So let's start by kind of finding out more about you.  So how many people in this room have built a mobile app before?  Okay, maybe half.  Out of those, how many built a hybrid app?  Okay, a few.  Native app then?  Okay.  So how many of you are about to start a mobile project  in the next six months?  Okay, looking for some timely advice?  Great.  So we're going to go ahead and conduct this session  in a little bit different fashion.  I'm going to start at the end and then we'll go back  through the beginning and the middle and figure out  how we got to the end.  So let's do that now. There you go.  If what you came here to here was someone stand on stage  and tell you to choose hybrid or choose native,  this is what I'm going to tell you.  If that's all that you were after, great.  You got time to go catch somebody else's session.  If you want to know why, I'm going to tell you that.  I'm going to stick around and we'll go through it.  And I'll take you through.  You know, my experiences in delving into hybrid app  development and why I think it's the right choice.  So for starters, am I a hybrid fanboy?  Yeah.  Have I ever built a native app?  Nope.  And does that make me grossly under qualified  to advise you on this subject?  Maybe.  But no. Really, it just means that I have already  kind of done a lot of this homework.  I've, you know, I'm going to let you know my experiences  in spelunking through all these Google results  and sifting through all these blog posts  and trying to figure out, should I invest  in learning a native technology or make use  of the existing web skills I already have, right?  Like, I'm going to be a hybrid fanboy.  I already have, right?  Like the upfront trade-off seems pretty obvious, right?  Because you say, well, if I've already got web skills  and I can use those technologies to build a mobile app,  then it's going to be better, right?  But that may not be true.  Now, I've gone through this kind of research cycle,  I guess, a few times over the last three or four years.  And every time I've come to the same conclusion,  I always keep coming back to hybrid apps.  And every now and then I say, yeah, you know,  well, maybe, and then I go back and I start thinking  about it again and I start doing the research  and trying to figure out if there really is an advantage  to going native, and I always come back to choosing hybrid.  So TLDR, choose hybrid.  So let's go back to the beginning and start  by kind of defining some things.  What is a native app?  What are the components of a native app?  You're going to find a native app is going to have  a platform-specific language.  You're going to be using a different language  for pretty much every platform that you need to develop for.  So if that's iPhone, Android, Windows phone,  there you go, three languages.  Three UI designs that you have to build.  Three UI design languages, I guess you could call them,  that you're going to have to learn.  Cocoa and XAML and whatever that thing is on Android.  You're going to have to go through and build out a UI  for each one of these platforms that makes sense for your app.  And you're going to have to build it three times, four times,  however many platforms you've got to go to.  And as you're building the same app to solve the same problem  for your end users or provide the same value for end users  on all these different platforms,  when you're building a native app,  do you know how much code reuse you're going to get?  Zero.  You're going to have to do everything on all of the platforms  that you need to deploy to.  You're not really going to be able to share much logic.  I mean, yeah, you might say, well,  if I'm building something that's more of a thin client  and I can put the logic on the server through an API,  yeah, absolutely.  And that's going to be true of any mobile app  you build hybrid, native, or otherwise,  and really any other app.  If you can centralize some of that logic into an API,  that's definitely going to get you some more reuse.  But on native apps, your actual device-specific code  is not going to get much shared usage.  So these things here, Objective-C slash Swift now,  if you saw yesterday's announcement or two days ago  announcement, Java, XAML, if any of those terms  give you heartburn, if you have built something with XAML  for Windows Phone 7 and now you suffer  from post-traumatic shock syndrome,  native might not be the best choice for you.  OK?  So let's look at the anatomy of a native app.  Here's what you're going to end up having.  On every one of these, in some form or another,  you're going to have this stack of view that has your UI,  some type of a view controller that's  going to present that UI, some business logic that's  underneath it.  And as you can see, they're in silos.  We're not sharing anything across them.  We're having to solve the same problem multiple times.  All right?  So on here, that's your problem.  OK?  In each one of these, your problems  are being solved multiple times.  OK?  Now, you're going to be challenged with trying  to build a somewhat consistent UI for your users.  That makes sense.  If you've got users who switch from iOS to Android  and they're using your app, you want them to understand  how to use your app already.  They shouldn't have to relearn it,  just because they're on a new platform.  You're going to have to have feature parity, not only  in your initial development, but in your ongoing development  as you continue to try to add value to your application.  You've got to add it on three platforms,  considering that's all of the market right there.  But if you're doing BlackBerry, have fun with that.  You're going to have to solve that same problem, every business  problem, every UI problem, all the great stuff  that Luke was just talking about out there with designing  for good user experience on a mobile device.  Well, now you've got to figure out how to replicate all of that  across all the platforms that you go to.  OK?  So you're going to have to solve your problem n times,  where n equals the number of platforms you need to deploy to.  And you're also going to have to overcome multiple learning  curves.  Unless you were already born an expert in all three  of these mobile platforms, you're  going to have to go out and learn these technologies.  Or you're going to have to go out in higher teams that already  have these technologies under their tool belt  and can be effective at building them.  So what's a hybrid app?  Well, one thing all hybrid apps tend to have in common  is a native web view.  There's a web view in every mobile SDK.  They've got some way for you to display a web page.  And hybrid apps take advantage of that  by having a native web view that lets you  present an HTML and CSS and JavaScript-based UI inside that web view.  And it doesn't look like a browser.  There's no Chrome around it.  It's just a full page most of the time,  unless you want it to have a toolbar.  They're going to have a JavaScript API that's  going to let you access native functionality.  So when you want to get to native device capabilities,  such as a camera or access to an NFC chip or GPS  or the contacts on a phone, they're  going to have a JavaScript-based API that's  going to let you access that in a consistent manner  across all the platforms that you deploy to.  And as discussed, we're going to have an HTML5 and CSS-based UI.  And JavaScript can be in your UI as well.  And that means that if you already  know how to build web pages, which quick show of hands,  who knows how to build web pages?  Yeah?  Pretty much everybody.  That's good.  Congratulations.  You already know how to build a UI for a mobile app then.  Are you going to have to learn some mobile UI paradigms that  make use of HTML5, of course?  Maybe you already know some from building mobile web apps.  But the really nice one is your code reuse.  When you choose to go down the path of hybrid apps,  you're going to get close to 95% to 100% of code reuse  across your platforms.  And that's going to skew more toward the high end  of that number for most apps.  Now, you're not going to get that with a native app.  So let's look at the anatomy of a hybrid app.  They're going to look like this.  You're going to have a native web view and native API  and a unified JavaScript API that goes across all those.  And then you're going to have JavaScript-based app logic,  and HTML and CSS-based UI sitting on top of that.  So here's how that breaks down.  Those top two, those are your problems.  All the bottom ones are somebody else's problem now.  Not yours.  You're going to lean on a framework, such as PhoneGap or  Senka Touch or something, where they are building out the  native web view.  And they are integrating the native APIs and exposing them  via a common JavaScript API.  And all you have to do is write one code base.  Whenever you want to get a picture from the camera, you  just say navigator.camera.getPicture, depending on  whatever kind of framework you're using.  And whether that code is running on a Windows phone or an  iOS device or an Android device, it's just going to work.  And you don't have to care.  All those differences in the platform are nicely and  neatly abstracted away.  So you don't have to worry about them.  Because last time I checked, unless you're actually  building one of these native frameworks, the details of how  to get a picture from a camera on three or four different  platforms is probably not the business case that you're  solving.  It's probably not what your app is intended to do.  If your app's primary function is to figure out how to get a  picture off of a camera, OK, yeah.  Maybe it makes sense for you to write that native code.  But probably not.  Probably you're building some sort of a social app or maybe  a line of business app.  And you need to grab the user's location for something.  You don't want to have to worry about how to write that on  six different platforms.  You just want to have one nice call that says, well, just  give me the location.  This is very similar in concept to something like the .NET framework.  You can go ahead and write lots of Windows-based code in C  or C++ that makes use of native low-level Windows APIs.  Or you can use the.NET framework and be way more  productive.  And then you can also know that some other engineer who  probably has more time and experience in optimizing native  API calls in the Windows framework has optimized that  and exposed it to you in a good way in the.NET framework for  most of your use cases.  That's the same concept with the hybrid app.  You're kind of standing on the shoulders of giants by letting  a whole team of other developers who work on  something like, say, PhoneGap that have a lot of  experience in building this native piece of the code so  you don't have to.  And it's also going to come back to, see how we've got  JavaScript app logic up there?  That means that you notice it's one big pink block across  all the platforms.  You have to solve your problems once.  And yes, some of those are going to be solved, like we  said before, at the API level up on your server.  But if it's a local device application, if it's something  that's offline and you don't have access to a server, it  doesn't make sense to have an API, you still only have to  solve your problems one time.  And the same goes for your UI problems as well.  When you start designing out a UI paradigm, you're going to  be able to reuse that across platforms and then just tweak  it ever so slightly as needed for each platform.  There's a gray area that exists between native and hybrid.  So this gray area is what we would call transpiled  applications.  A transpiled application is going to be something that you  write code in one language and it gets transpiled down into  another language.  So examples of that might be something like, say, Xamarin,  where you write C sharp and it gets transpiled down into  Java or Objective C or whatever else to run on all these  different platforms.  Now, in these transpiled apps, you're still going to have  some of the advantages of kind of like a hybrid app in that  there's going to be native device APIs that are exposed in  a common language.  Hybrid apps do it with JavaScript.  Some of these transpilers do it with JavaScript, like, say,  AppCelerator.  Some of them do it with C sharp like Xamarin.  You're going to have common business logic across your  platforms.  So once again, we're getting that nice advantage here of  being able to solve your business problems with one  code base one time and have it work on all the platforms,  which is very nice because as a developer, you probably, like  I do, adhere to the kind of philosophy that, well, if I have  to do something more than once, let's automate it because I  don't want to do it three times.  Same thing with building a native app.  Why solve the same problem three or four or five times  when you can solve it once by using a better set of tooling?  Now, most of these transpiled applications, you're going to  have to build a platform-specific UI.  Now, these are going to be usually in the native UI  language and tooling of the platform that you are trying  to target.  So typically, you'll have to build out a cocoa-based UI  for iPhone.  You don't have to do your Android thing.  You don't have to do XAML.  Now, that's not 100% true.  Some of them, especially if you saw the release of Xamarin.  Forms, they've released a lot of nice cross-platform UI  components.  But you'll probably still have to dip down into native UI  stuff in order to use most transpiled mobile app frameworks.  So code reuse.  Transpiled apps do get a lot of good code reuse.  You're still probably going to get, on average, I'd say,  about 70% to 80% code reuse by going this way.  Most of your business logic is going to be there.  It's going to mostly be UI code that you have to, that you're  not going to be able to actually use between the things.  Now, that still leaves you in that area of having to solve  these UI paradigms on your own.  To solve these UI paradigms on multiple platforms.  So you're still going to have to figure out how to make this  work on each one of these platforms and how to plug it  in to your transpiled app framework.  So like I said, some examples of the transpiled apps would be  Xamarin, AppCelerator, Titanium.  I haven't built a full app with either one of these things.  I've maybe done about Hello World on each one.  And they definitely have some potential.  But again, I've always fallen back to doing a straight up  hybrid app with something like PhoneGap.  So when should you choose native?  I've spent this whole time up until now telling you, well,  you shouldn't.  You should just choose hybrid, right?  But that's not always going to be the use case, right?  There are times where a native app is the way to go.  One of those times is when you only care about one platform.  If all you care about is having your app on Android,  then whatever, just build it on Android.  If your app is highly dependent on a feature that only  exists on one platform, right, for a long time, NFC was  only on Android.  And if you were building some sort of a mobile wallet app  that used NFC for payment or something like that, OK,  build it on Android.  There was no reason to go to iOS or Windows Phone at that time.  Or the big one is when your app uses heavy 3D rendering,  you're building a game or something  that's going to have a really, really intense 3D UI,  you're probably going to get a lot better performance  by going native with that.  But the caveat is none of those reasons  mean that you have to choose native.  You can do all of those things with a hybrid app.  I've shipped many hybrid apps that are only on iOS.  But it was faster and easier and cheaper for me  to build it using PhoneGap and some other UI frameworks  and ship it.  And now if the client comes back to me and says, oh, man,  we got to go Android and say, OK, cool.  We can do that tomorrow.  Just got to run a build script.  We're done.  And they go, oh, wow, that's cool.  3D rendering, you can do a lot in the browsers and web views  that are available today.  Most of them have OpenGL.  And you can build a lot of really intense 3D games  using nothing but JavaScript.  You can also do this in transpiled apps.  I talked to a guy who had used, I think he had used Xamarin  and built a fully 3D UI.  And he didn't care about having to redo his UI on every platform  because he wasn't making use of any native stuff anyway.  It was all his own UI.  So he was able to reuse one set of UI components  across all the platforms as well because of the way  he had to build it.  So why is hybrid good for the 95% use case?  Most of the time, you're going to find that a hybrid will  probably suit your needs.  So a lot of people are building line of business apps, which  end up being lists.  You don't need a native app for that.  You can do nice, rich UI in a hybrid app as well.  So hybrid apps are good because they're going to have native  functionality available to them via plugins.  If there is something that you can't do in HTML and CSS,  you can write a program that's not available to you.  In HTML and CSS, you can write a plugin for it.  But even better than that, most of these frameworks already  have big plugin ecosystems where other people have already  contributed plugins that will probably meet your needs,  or at least serve as a good starting point for writing  your own plugin.  Some examples of that would be things like barcode scanners,  GPS contacts, camera, NFC, Bluetooth.  There are tons and tons.  Facebook and Twitter integration for authentication,  being able to build SMS text messages in the device's  native format and actually send them out.  There are tons and tons and tons of plugins out there that  will give you the native access you need.  And even if you have to write your own plugin,  you're now only having to write and maintain this much  platform-specific code on each platform instead of 100%,  instead of the whole thing.  The other reason that they're great is that there are a lot  of frameworks out there to help you build good, close to  native, or fully native-looking UIs on each platform.  And also give you a lot of the same native behaviors people  expect on your platforms.  A few examples of this are like Ionic, Senka Touch,  Kendo UI.  Some of these take different approaches.  I've been using Ionic to build a lot of apps lately,  and it's been really, really nice.  It's heavily integrated with AngularJS, and single-page  apps are great for building mobile apps.  So Ionic gives you a lot of cool stuff, such as behaviors,  in that they've got AngularJS directives to build out a  list that automatically has swipe to edit and delete, and  have all those native UI paradigms that your users are  already accustomed to available to you without you  having to write all that extra code to figure out how to do  it.  And it's going to work on all these multiple platforms.  And then because it's just CSS and HTML that's used to  style the UI, now you can tweak it and make it look right  for your brand and match what your users are going to  expect.  OK?  A phone gap has always been my hybrid platform of choice.  And they have a ton of plugins.  Now, a phone gap plugin and most hybrid app plugins are  going to consist of the same thing.  You're going to have native code written in the platform  that you are developing for.  So Objective-C or Swift for iOS, Java for Android, C-Sharp  for Windows Phone.  And on top of that, you are going to expose a JavaScript  API for your plugin, which then gets kind of exposed  through that common JavaScript API that we saw on the slide  before.  So this lets you build out a scenario where you only have  to write, like I said, a little bit of code for a given  platform and still be able to access full native  functionality in that area, which is way better than  writing it for every platform.  So if any of you have already been doing any research into  hybrid versus native, you've surely come across a ton of  stuff on the internet about how hybrid apps don't perform as  well as native apps.  This is one of the first things that I came across when I  started looking into it.  I said, oh, that seems too good to be true.  And sure enough, I found a whole lot of blog posts telling  me, yeah, it is too good to be true.  The hybrid apps don't perform well.  Well, I think you're going to find, if you go and look at  that, that, A, most of that is based on hybrid technologies  that existed around 2010 when they kind of started really  coming into popularity.  They weren't that great.  Like a lot of software, they didn't come out of the gate  killing it.  They took some time to iterate and figure out how it was the  best way to do things.  And I can tell you that the hybrid solutions that are  available today, this is not a statistic that I have a  benchmark on, but in 90% to 95% of the use cases, they  perform just as well as native apps.  So when you are going out and conducting your own research on  this topic, please make sure you check the dates on those  blog posts and really kind of go investigate the frameworks  that you're looking at and figure out, well, have these  people made any progress in the last four years?  I sure hope they have.  Now, you're also going to come across the Facebook story.  Facebook, very famously a couple of years ago, ditched  their HTML5 apps and went to native apps.  And I even saw a quote from Mark Zuckerberg that said that  betting the farm on HTML5 was one of the worst strategic  decisions that the company ever made.  Maybe it was just feeling pressure from the IPO.  I don't know.  But I will say this, should you do the same because Facebook  did?  No.  I've done a lot of looking into that because it was a  really big driver for me when I first started looking at  hybrid apps and saw that Facebook was ditching their  hybrid web view-based application to go native.  I said, oh, man, if it's not good enough for Facebook, it's  probably not good enough for me either.  Well, first thing is then I remembered, oh, yeah, I don't  have Facebook's problems yet.  One day I'll have billions of users on my app and then I'll  have Facebook-level problems.  Today I don't.  Then I came to the realization, if I built a hybrid app and  got to Facebook scale, hopefully I would be making  enough money that I could hire teams of engineers on each one  of these platforms to build me native apps, just like  Facebook did.  If not, then maybe there's more of a problem with my  business model.  Maybe I have done something wrong upfront that  caused this problem.  Now, I don't know a whole lot about Facebook's actual  implementation, but from what I've read and what I gathered,  I was able to draw some pretty interesting conclusions.  Remember this slide?  Remember how I said that the things at the top are your  problem and the things on the bottom are somebody else's  problem?  Well, this rule only applies if you actually choose a  mobile framework, like, say, PhoneGap or Senka Touch, where  other engineers are building the native components and  giving you a place to plug in your HTML and CSS.  Now, from everything I've read on the Facebook situation,  they didn't take this approach.  They decided they would build their own native container  with a web view to display their HTML stuff in.  If you're going to go that far, you may as well build a  native app, because now you are in charge of all of the  native code that displays your web view and making sure that  it's patched for security and that it's performing well and  that you're keeping up on all the SDKs.  You've already taken on the overhead of native app  development at that point.  You've already had to learn the language.  You're probably not getting a whole lot of gains out of doing  a hybrid app if you are building your own web view on  each platform.  Now, the other thing with regards to our performance  myth is I will tell you right now, having never even built a  native app, that it's just as easy to write crappy code  in a native language as it is to write crappy code in  JavaScript.  Ever been is easy.  In fact, if you are maybe an experienced web or JavaScript  developer and have never touched a native language before, I  would say it's probably even easier to write crappy code in  a language that you're new to.  I mean, how many people here have spent a lot of time  learning how to optimize your web view?  How many people have learned how to optimize for the  platforms that you build for?  If you write.NET code and C sharp, you've probably learned  a lot over your years of experience.  That's why we look for developers that have five  plus years of experience for things.  Because we know that they've already learned, or hopefully  have learned, how to write better code in that language and  how to get more performance out of it.  So if you have already spent a lot of time, especially if  you're a web developer who has already spent a lot of time  really good at optimizing your HTML and doing smarter and  more efficient DOM manipulation and writing good  effective CSS selectors and writing good high-performance  JavaScript, you're probably going to be able to write a  good, well-performing hybrid application using those skills.  Those skills are going to transfer right over into your  hybrid app development.  However, if you have never written Objective-C before and  you file new in Xcode and start building out a native app,  there's a very good chance that you're going to do a lot of  things wrong or do a lot of things poorly.  It's the old saying that the first step to getting good at  something is sucking at something.  Well, oftentimes in mobile app development, time to market  is critical.  If you can get out there first with your idea, you're going  to gain some mind share and some market share.  Well, if you've got to go build something really, really  fast on three brand new platforms that you've never  touched before, there's a good chance you're going to put out  crap.  But if you can leverage existing skills that you've  already spent time developing, you've given yourself a much  better chance of putting out a good,  well-performing application.  So our conclusion here is that you should choose hybrid.  I told you I was a fanboy.  Now, as we've said, there's a lot of reasons that you might  choose something other than hybrid.  But if you're going to go down that path, I really, really  want for you guys to go down that path with your eyes open.  Understand the caveats, because it's easy when you're jumping  out into a new language to find a lot of let's get started.  Here we go.  Quick start tutorial on Android development.  And it's going to have you build Hello World.  And you're going to say, OK, that wasn't too bad.  I mean, I had to struggle through some tool installations  and some configurations and maybe a little bit of language  learning stuff.  But I got Hello World out the door in a day or less, so it  can't be that hard.  Just stop to remember the first time that you wrote Hello  World in your favorite language.  You wrote it, and you probably learned a lot since that  first Hello World.  So don't throw that out the door, especially if your  language of choice is already JavaScript.  Don't throw away that skill set, just because some random  blog post from 2011 says that Facebook had a problem with a  web view.  That's not really a good reason to go that route.  So at this time, I'd like to go ahead and just open it up  for questions.  Generally a lot of questions at the end of this talk.  Go ahead.  OK, great.  So the question is, out of the stuff I've mentioned, what  kind of concrete examples can I give of stuff that I've  used?  As I said earlier, every time I've looked at stuff, PhoneGap  has been my tool of choice for building these hybrid  applications.  And it's the only thing that I've actually shipped  something to the app store in.  And it's been my experience, especially since PhoneGap went  from 2.9 into the 3.0 era.  They made huge, huge gains in the way that they handle their  framework and performance.  And it's gotten us a lot closer to a native app  type experience.  As far as Xamarin, like I said, I haven't done anything  beyond, say, Hello World using Xamarin or  Accelerator Titanium. So I can tell you that my experience in  those, in writing Hello World, was such that I felt like I  wasn't going to get enough gains out of investing in  learning their system.  With PhoneGap specifically, I found that I didn't have to  learn very much new stuff beyond HTML and CSS and  JavaScript.  It was very much about building a web app that could run on a  device.  But so I don't have a lot of good, I don't have a lot of  good negative experiences to tell you about because I don't  waste my time on negative stuff.  When I feel like there's nothing there, I bail out.  But excellent question.  Did I answer that?  OK, great.  So any more questions?  Yes?  What are some high profile?  Excellent, excellent question.  I actually had a bullet point on here, and I forgot to  bring it up.  So with PhoneGap, I was just looking this morning, and a  couple that I found as high profile examples were the  BBC in the UK did an Olympics app for the Summer Olympics.  Or no, maybe it was just recently, Winter Olympics,  whichever one.  I don't know, I'm not in the UK, so I didn't get to use the  app.  However, it was featured on PhoneGap's featured app page to  show that the BBC had built this thing.  And it looked beautiful.  And it was available on iOS, Android, and BlackBerry.  That was the platforms they decided were  important to them.  And this app had 24 live streaming feeds of the  Olympics.  It had social integration, it had medal rankings, it had a  page for every sport, a page for every country where you  could go see all this stuff.  And obviously, if it's put out by the BBC to allow people to  use it, I don't know what their usage numbers were, but I  got to guess, there was a whole lot of usage, a whole lot of  simultaneous usage.  And again, the thing you remember on mobile apps is  simultaneous usage doesn't really amount to anything  except for server load.  Everybody's using their own device.  But another one that I see, has anybody here ever used  Untapped?  No?  Craft beer drinkers?  No?  OK.  But it's big in the States anyway.  And it's another one that is available on iOS, Android,  and Windows phone, and has great experiences.  And to be honest with you, I've used the app for probably a  year now.  And until I looked it up and noticed it on the Phone Gap  page, I had no idea it was a hybrid app.  Like, I've been using it every day, or not every day, but a  lot over the last year, and had no idea that it was a Phone  Gap-based application.  And I was like, oh, OK, cool.  Well, that's good to know.  So now there are other, one of the ones that I here pointed  out a lot as an example of hybrid apps, but it's not  Phone Gap, to my knowledge, is Instagram.  Now, Instagram is still, as far as I have guessed, in the  same boat that Facebook was with their HTML implementation.  I believe that they have a native app with their own web  view, and so they load up native navigation, and then the  actual pictures and posts that you view are loaded in a  web view.  Now, again, they have taken on the task of writing,  essentially, a native app.  Probably the only reason they showed in a web view is  because it's a real easy way to load a bunch of pictures and  text into your app, because those are coming live from  the web, which is actually a really good, important point  to bring up.  When you are building a hybrid app, especially with  something like Phone Gap, a common misunderstanding or  pitfall that people get into in the beginning is they say,  well, I've already got a mobile website, so I can just take  Phone Gap and create this little container that will load  up the mobile website I've already got on my server,  and it's just going to work.  No, it's probably not.  Phone Gap is going to require at least the first bit of HTML  to be on the device.  And you're going to get the best experience by serving all  of your JavaScript and HTML and CSS from the device itself.  If every time a user clicks on something in your app, it has  to make a web request, just like they're in their browser.  It's going to feel like a website, not a native app.  And that's one of the areas where, when you go down that  path, it creates a hybrid app that doesn't feel native.  Now, one of the advantages of a hybrid app is that we've all  heard the horror stories about it taking two and three weeks  to get something approved on the Apple App Store, and you've  still got to get approval to do it and everything.  A hybrid app can actually give you a little bit of a way  around that, in that you can ship one version of your  application, but on startup, you can go download.  You're free to just go download fresh HTML, CSS, and  JavaScript from your server.  So you can build what amounts to a local application.  But on startup, you can say, well, let's just go check and  see if we've got any updated JavaScript.  Maybe you fixed a bug, and instead of having to submit  to the app store, you just ship the JavaScript file up  there, and your application automatically says, hey, let me  go grab the latest assets and bring that down and  use this locally.  And now you've just shipped an update to your app and fixed  a bug that was plaguing your users without having to wait  for Apple to approve it or anything like that.  More questions?  Sorry, these spotlights are hard to see.  Yes?  OK, yeah, great question.  So the question is, with all the different screen sizes and  resolutions and portrait versus landscape and rotation, is  that something that's better addressed with platform  specific UI or with a hybrid solution using CSS?  I very much think CSS, especially with CSS3.  Your advantage in building a mobile app is that even the  worst mobile browsers are better than IE8.  So you get to use CSS3 and media queries and really smart  selectors, so you can actually customize your UI to handle  all of those different screen resolutions and the rotation  between them very, very well by writing CSS.  Now, if you don't already have a good, strong, responsive  design background, yeah, you're going to have to learn it.  But which do you feel like is a more worthwhile investment?  Learning how to solve the same screen resolution and UI  problems on two or three platforms or learning how to  solve it using CSS, which, hey, that also applies to the web  where a lot of stuff goes on.  So to answer your question, yes, I think that those are very  well-addressed in hybrid apps by simply using CSS and  JavaScript.  One of the frameworks I mentioned earlier, Ionic, it  does some really nice stuff on startup, whereby it does  platform detection, and it slaps CSS classes onto the body tag  of your HTML page that says things like platform dash iOS,  platform dash Android.  And it even assigns grades to these platforms, like grades  A through D, based on the capabilities of the hardware.  So you can very, very easily, with just CSS, change the  layout of your application for a specific platform, maybe  disable animations on a lower grade device that's not going  to handle them very well.  You can do all of that very, very easily by utilizing a lot  of these tools.  And it actually brings up another great point in that  one of the ways in which you can really get more leverage out  of your hybrid app is by also making it a web app.  But actually, I think Luke was just talking about this in the  keynote, that there's a lot of companies that have both a  native app and a mobile web experience, and they end up  being complementary.  When you build, especially like a phone gap app, you're  building a native web app.  You're building a mobile web app that happens to  run on the device.  And if you take a little bit of an intelligent approach to it  up front by doing a little bit of detection to figure out,  hey, am I running on the device, or am I running in a  website?  You can present the same UI.  I've actually done this before with an app that I  shipped to the app store, and we had a mobile web version.  It was one code base.  And so when the users landed on this mobile version of a  website, they got the exact same experience as they did in  our app that was on the app store.  The only difference being that I had a barcode scanner in  this app.  Well, I can't do a barcode scanner from the web.  So all I did was check to see, hey, am I in phone gap, or am  I in the web?  If I'm in the web, then whenever they clicked that  button that would normally bring up a barcode scanner, it  said, well, just type in what you're looking for.  And maybe you could do it without typing, like Luke  said.  You could do something more intelligent.  But the point being, now you can not only go to all these  multiple platforms, but you can also go to the web.  Because as you get into native app development, you're going  to find that one of the challenges is, now you're  expecting your users to install an app.  I work for a company that makes a shopping app.  Or we used to make a shopping app.  Now we only make a shopping mobile site.  Because the idea of getting a customer to walk into a store  and download a third party app in order to do some additional  shopping was too much of a bridge to cross.  But I didn't lose any time, because I built all this in  phone gap, and I was able to take that code base that I was  already using for mobile web and just ditch the native app  side of it and only use it as mobile web.  We didn't have to backtrack for months and months and months  to recreate this as a mobile website.  So it's one more advantage of a hybrid app is that now you  already have a mobile website available.  Yes, sir?  How do you handle offline functionality in the  network app?  Do you use local storage?  That's a great question.  So how do you handle offline in, say, a phone gap app?  There's a lot of ways.  Yes, local storage is my favorite.  I typically am using just HTML5 local storage to do a lot  of things.  There are also plug-ins that you can use, such as  CouchBase.  If anybody's used CouchBase before, they now have a mobile  plug-in that has a sync back-in built into it.  So it kind of will automatically do some stuff so  that you've got CouchBase on your server.  You've got a CouchBase plug-in in your mobile app.  And whenever you fire up your mobile app, it kicks off a  sync in the background.  It starts pulling down background data.  And then we'll do the same thing.  Whenever you lose a connection, it'll go ahead.  And as you continue just interacting with your local  app, whenever a connection is available again, sync it back  up to the server.  And you can also just build your own solutions for this in  that there are phone gap, for example, raises events that  says network connected, network disconnected.  So you can get those events and you can start handling  them in your code to say, oh, OK, I need to switch this into  offline mode, or I need to switch back into online mode  and sync any offline data that happened.  So yeah, offline is absolutely something that you can  handle very well in a hybrid app, just like you can in a  native app.  More questions?  No?  All right, well then, my name is Jeff French.  You can follow me on Twitter at Jeff underscore French or  check out my blog, geekindulgence.com.  And if you have any additional questions that come up after  this, feel free to hit me up in one of those two places.  Thank you very much for your time today.  Thank you.
Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_0_2015.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2016_2147.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2148_2207.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2208_2279.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2280_2351.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2352_2903.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_2904_3071.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_3072_3215.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_3216_5111.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_5112_5159.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_5160_5471.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_5472_5903.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_5904_6971.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_6972_7967.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_7968_8819.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_8820_9539.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_9540_11507.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_11508_11903.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_11904_11951.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_11952_12755.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_12756_13451.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_13452_14351.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_14352_15059.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_15060_20687.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_20688_20747.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_20748_20987.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_20988_21791.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_21792_22511.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_22512_23627.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_23628_24803.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_24804_25739.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_25740_26495.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_26496_26543.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_26544_26927.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_26928_27215.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_27216_27779.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_27780_30251.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_30252_31235.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_31236_32099.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_32100_33119.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_33120_36623.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_36624_36707.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_36708_38003.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_38004_39011.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_39012_41987.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_41988_44363.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_44364_48203.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_48204_67991.png Jeff_French_-_Hybrid_vs_Native__Choosing_a_Mobile_Strategy_67992_70318.png