16 ms·

If It Weren’t for Apple, Hybrid App Development Would Be the Winner Over Native

• trey-jones 9y ago
  Occasionally I find an article on Hacker News that I both strongly disagree with, and feel I have enough domain knowledge to speak intelligently about. This is my opinion, and may be different from yours. > Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps I think that is very presumptuous. Maybe it is for some developers. I used Cordova sparingly a few years ago. Most of my hybrid development going back to 2012 is using Appcelerator Titanium. In fact, at this very moment I'm putting off working on a project built on the Appcelerator Platform, because of the giant headache that it has caused me. Here are some of the reasons that I'm in favor of native development, with completely separate codebases for each platform, possibly using some shared libraries when appropriate. 1. As alluded to in the article, even with hybrid you have to put up with Apple BS. And it turns out, Xcode is not completely terrible; eg. in 2017, building a native app, you don't have to worry about provisioning profiles (much), because Xcode handles this for you. I was shocked when I discovered this after developing hybrid apps for years. If I have to learn it anyway, I might as well use it. 2. Quality/reliability/ease-of-use of third party libraries is higher. Yes, there are legions of Javascript developers out there, and some of them are trying to build mobile apps. There are also a great number of native developers out there and (trying not to ruffle too many feathers, and with no data to back this up) they are on average more experienced than the average javascript developer. They are also writing COMPLEX apps, and as a result we have a large ecosystem of good libraries that do a lot of the things that one might need to do when writing a mobile app, and they probably work out of the box with your toolchain, because the developer is using the same toolchain as you. Just drop it in, and use the API. 3. Hybrid app frameworks do not expose the full feature set of native platforms. Yes, Appcelerator just released "Hyperloop" to the masses which claims to do just that. I haven't tried it. Why make native calls through Appcelerator when I could just make native calls to the OS? 4. Hybrid app frameworks have their own bugs, and limitations that require strange workarounds. One might think that running into these would be uncommon. All it really takes is one, if you then have to sidetrack into learning about the codebase framework you are using, potentially rebuilding from source if there's no way to work around it at the top level. By the time you get it all sorted, you may as well have just done native. Sure Xcode has bugs and limitations too, and Appcelerator has definitely improved in this area over the last 5 years, but with layers of abstraction comes layers of new problems. 5. Technical support is easier to come by with native. Having a problem with something complicated? Good luck finding an existing question and answer of Stackoverflow. There just aren't enough knowledgable Javascript devs doing complex things with hybrid apps compared to native. Also, the hybrid app development ecosystem is fragmented: the problem you are having with Cordova is probably not the same as the problem I'm having with Appcelerator. Or maybe it is, but it's not readily apparent. 6. Native toolchains are superior to hybrid ones. I'm stepping out a little bit here. I abandoned Appcelerator Studio years ago in favor of the CLI, so I don't know what I'm missing there today. Well, I do know that I'm missing a decent debugger. Maybe that is in Appcelerator Studio - I have no idea. Feel free to call me out on this one. In summary, hybrid is probably the right answer for SOME apps, and SOME developers. Based on 5 years of experience building hybrid apps, there are very few apps that I think wouldn't have been better (without consuming additional budget) as native apps. There are too many unknowns for me to commit to building anything more complex than the most basic of apps with a hybrid framework.
  • ourcat 9y ago
    I've been using Titanium for years now. Since the very early days. It's certainly had its fair share of painful upgrades, but I've learned a lot of Java and Objective-C in the process as I've built a few cross-platform native modules to do things the main SDK can't do. And recently, they've opened up 'Hyperloop' to the (now) free Indie Tier. Hyperloop allows direct access to native iOS and Android code, modules, pods, Frameworks, jars, aars, etc. right from within the Javascript code. I used Angular a lot too and have built Ionic apps with that knowledge too. But, my overall opinion is that Titanium is by far the best. (As long as you pick a good stable SDK version! ;) )
    • doublerebel 9y ago
      Wait -- hyperloop is alive and well?? How do you like it? I may have to revisit Titanium, it's been a couple years but I had good experiences with the platform pre-hyperloop.
    • trey-jones 9y ago
      I don't really disagree that they have the right idea, and are the best that I've tried in the hybrid space. I've just spent so much time fighting the platform that I feel native is a safer, more powerful, and better option.
• sidlls 9y ago
  If the title were literally true it would be a positive mark in favor of Apple, in my opinion. A good many of the paradigms in web development exist, it seems to me, simply because the desire for cheap apps built with cheap labor outpaced the platform on which these cheap apps are built. Whoever thought using the browser as a substitute, psuedo, or virtual OS was a good idea?
  • mattkevan 9y ago
    What's funny is Apple's original plan for iOS was that additional functionality would only be delivered via cross-platform web apps. With iOS 1 lot of developers thought Apple was terrible for promoting web apps and that native should be the way forward. And so the app store and native apps arrived in iOS 2. Now, apparently, Apple is terrible for having native apps and that web apps should be the way forward. How things go in circles...
    • protomyth 9y ago
      I'm still convinced this was BS, and they were late with the SDK. I cannot imagine anyone inside Apple thinking they could get away with the quality of IOS 1 (well iPhone 1.0) web apps.
      • MBCook 9y ago
        It is. There have been interviews. They didn't have the SDK ready (it was a total mess on the preinstalled apps). When people demanded a way to develop they pushed out web development because they could do it fast while they got everything else documented and into a consistent state and secure. It sounded like they always expected to do native apps, just not nearly as fast.
    • ElijahLynn 9y ago
      Apple has abandoned the web. WWDC 2016 didn't mention the web once. They are holding web apps back. They still haven't announced service worker commitment for Safari. What a joke. https://jakearchibald.github.io/isserviceworkerready/ https://jakearchibald.github.io/isserviceworkerready/
• jackmott 9y ago
  >Put simply, if your users never complain about the performance of your app then it is fast enough Suppose the users aren't aware that your app is wasting their battery power, because of it's bad performance? Suppose your users don't complain because ~90% of software is written slow, and so they expect sluggish response. Maybe you could be getting rave reviews about how responsive your app is. Example: saw recently a discussion on reddit where a guy did an Android app in rust, instead of the usual Java/Unity etc. People who tried it out all remarked "wow that was the fastest opening game I've ever clicked on!" CPU designers have been doing amazing things with hardware, let us not waste it.
  • deleted 9y ago
    [deleted]
  • MBCook 9y ago
    I remember two years ago I was playing a fun little game on iOS and it felt nice and fast and I had no problems with it. Until I got complaints from the network manager at my work because it seems that when you skip the video ads it continued to play them in the background and used up the very meager bandwidth we had at the time. It's very easy for a simple accidental mistake to cause all sorts of issues while the app still feels "fast". (I'm still kind of surprised/disappointed that got through app review). Also, just because something is fast enough that people don't complain doesn't mean that it's fast enough that people are happy. I'm used to the speed of my TiVo, it could be MUCH faster. The truth is: people are used to poorly designed things that don't go very fast. That doesn't make it OK to give them more of them.
    • votepaunchy 9y ago
      Why do you think hiding skipped ads was a mistake? Seems a potential way to increase ad revenue if only paid for viewed ads.
      • sqeaky 9y ago
        That sounds like fraud if you mean that the ad counts as viewed even when it isn't.
• tyingq 9y ago
  There's a fair number of "apps" that could be replaced by a plain old web site as well.
  • cowmoo728 9y ago
    Like facebook messenger. It worked great, and then they took it away, and then "request desktop site" still worked fine on larger phones, but I think they've recently done some weird WebGL things that make it impossible to type in any of their input fields without a proper desktop browser.
    • zem 9y ago
      mbasic.facebook.com still works
  • mcphage 9y ago
    Except for that pesky requiring an internet connection...
    • tyingq 9y ago
      There are apps that don't work without that as well. eBay's app, for example, adds little for most users.
    • tambourine_man 9y ago
      Local storage has been a thing for a really long time
      • mcphage 9y ago
        You can't even go to the website in your browser if you don't have internet. Local storage is nice, but by that point the problem has already occurred.
        • tambourine_man 9y ago
• wolfgke 9y ago
  "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough. Put simply, if your users never complain about the performance of your app then it is fast enough." Battery usage can still be a problem even if the app appears to run smoothly.
  • eberkund 9y ago
    Is this still true of cross platform apps that supposedly "compile to native" like Reactive native and Xamarin?
  • mikeash 9y ago
    In addition, just because nobody is complaining doesn't mean you aren't wasting their time. "Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" http://www.folklore.org/StoryView.py?story=Saving_Lives.txt http://www.folklore.org/StoryView.py?story=Saving_Lives.txt That's probably putting it a bit too strongly, but "nobody complains" is probably putting the bar too low.
    • kbenson 9y ago
      I suppose the assumption there is that me must stay perfectly still and stare at our phones during this time? My toaster takes a while to toast break. My coffee maker takes a while to brew coffee. I don't really consider that wasted time, because it doesn't require anything of me, and I'm free to do something else.
      • _jal 9y ago
        Which explains why nobody cares about hold times, shipping speeds for purchases, or when other people are late. You can just make toast while you wait. More power to you, but I find the short pauses in apps the worst. If some function is going to take time to run and I expect that, absolutely, I can walk away and come back to it. I do this frequently. But these are not the sorts you generally see on phones - you get terrible 7-10 second pauses as something slow launches, talks to a slow server, thinks weirdly hard about something because of a slow loop, whatever. Especially when unexpected, 7 seconds is insufficient to task-switch, so yes, you end up staring at your phone.
• ransom1538 9y ago
  AS3/Flash was an amazing language + ide. It included a simple syntax, layers, a great system of events and callbacks, animations built in, timelines, vector graphics, etc. I and other AS3 devs (2011) could write code x10 faster than anyone in obj-c. The concept of AS3/swfs running on an iOS store could mean the end of control of the apple app store and the break down of the obj-c community. Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped. Adobe should have played hardball and yanked photoshop [+studios] from the osX.
  • scj 9y ago
    > The concept of AS3/swfs running on an iOS store could mean the end of control of the apple app store and the break down of the obj-c community. Why would Apple want that?
  • wolfgke 9y ago
    > Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped. The problem rather is in the Apple users that accepted this behaviour from "their" company.
  • tambourine_man 9y ago
    Except it ran like shit everywhere besides Windows, never mind a 2007 iPhone. I'm sure it could be made to work great, but it never did.
    • rkachowski 9y ago
      That's true, I remember when Adobe Air first came out for mobile devices and I was completely heartbroken at my game which ran 30 fps on desktop choking at 4fps on the iPhone. At the time, it was such a great idea (in theory)
    • ransom1538 9y ago
      Right. Apple would never be able to figure out how to get a swf file to run quickly.
• threeseed 9y ago
  Talk about revisionist history. Apple never had an SDK to begin with because they thought developers would write their apps in HTML5/JS. Guess what ? They were awful and users hated it compared to the native applications.
  • dimillian 9y ago
    One of the best answers here. Initially, if you watch the WWDC keynote, and if you look on how to make "apps" for iPhone Software 1.0, you'll see that Apple had a website to teach you on how to make "webclips". So iPhone app would be mobile site you pin to your springboard and that was it. The experience was painfully slow and clunky, so by iPhone Software 2.0 they rushed a native SDK. Which you could see it was rushed because it was very lacking and buggy at first.
  • YooLi 9y ago
    Why is this down voted? It's absolutely verifiable. You can watch the keynote and then go read the headlines lambasting the decision. It's why the phone launched in Summer 2007 but the App Store launched in Summer 2008.
    • ac29 9y ago
      I didn't downvote, but the comment misses the point of the article. Were web/hybrid apps the right choice in 2007? No, but that doesn't mean they can't be in 2017. The hardware is orders of magnitude faster and the software ecosystem has vastly improved. It wasn't a great idea to start a internet-only business in the mid 90s (with some obvious exceptions), but the same isn't true today.
  • PKop 9y ago
    That this was true in 2007 implies it is true today?
  • MBCook 9y ago
    Apple didn't expect developers to want to develop on the iPhone so strongly. There've been interviews that said that they were going to release an SDK eventually but when there was such strong demand they had to get something out and what they got out was the web clips thing. What I've heard is that in 1.0 they were really different bits of software many of the applications had their own implementation of UITableView... basically things were a mess. So Apple put out the Web stuff while they got everything cleaned up and standardized and documented to the standard they want to give out to third-party developers.
• k-mcgrady 9y ago
  Where to start? >> There are some major advantages to the Hybrid approach: You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android. This is assuming you have a JS/HTML/CSS skillset. >> Here’s some Apple BS we can’t avoid no matter what approach we use >> Xcode I've done some React Native development and Xcode is almost entirely avoided. >> Provisioning Profiles It's been a long time since I encountered issues here as it's all managed by Xcode nowadays. >> Needing to use TestFlight for beta builds Why is this BS? You could also use Ad-hoc distribution along with something like Fabric for small scale beta tests. >> The app review process. Admittedly, the app review time has dropped to about 2 days on average, but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin. I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal). Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS. Overall I can't help but feel this was thinly veiled clickbait to advertise the authors app.
  • TillE 9y ago
    The idea that everyone a) knows Javascript/HTML and b) likes Javascript is astonishingly insular. The web is not the world, and you really shouldn't try to crowbar it into literally everything.
    • ElijahLynn 9y ago
      JavaScript is the future. All devs should know the basics.
      • thehardsphere 9y ago
        It's the future of parts of the web, not the future of everything. All cyclists should know the basics, but nobody falts them for choosing not to ride a tricycle once they can choose between tricycles and bicycles. Or choosing to use a tractor trailer instead of a bike if that's what they need.
• kartan 9y ago
  It looks like the Top Grossing iOS apps are Hybrid Apps or games. So I don't see that "IF Weren't for Apple". https://sensortower.com/ios/rankings/top/iphone/us/all-categories?date=5/24/2017 https://sensortower.com/ios/rankings/top/iphone/us/all-categ...
  • dimillian 9y ago
    Game are still native. If you take Unity or Unreal engine 4, as of today it compile against metal for the Mac/iOS renderer. So yeah, actually game development is ahead of applications in term of crossplatform dev.
• tambourine_man 9y ago
  Probably true, and I'm so glad we have Apple in this industry. Otherwise everything would be optimized for ease of development instead of the end user experience.
  • chrisper 9y ago
    Electron phone apps everywhere. That would be horrible.
    • ex3ndr 9y ago
      To be honest React Native is Electron for mobile. On Android it starts custom Chrome engine in it.
      • ashark 9y ago
        That might explain how they got around the horror that is trying have have complex, flexible styling across several major Android versions without every single thing you do being entirely broken on one or another. I'd wondered why the various things I'd tried kept actually working. That'd do it.
      • eropple 9y ago
        I don't believe that this is accurate. It starts a V8 engine, not a Chrome engine, and renders (on the standard framework UI loop) using--as one would expect--native controls. If you want to use a WebView, you must invoke a WebView.
        • amelius 9y ago
          > It starts a V8 engine, not a Chrome engine And that V8 engine contains functionality which is surprisingly similar to Chrome. Except they decided to reinvent the wheel.
          • flai 9y ago
            You are aware that chrome uses V8, not the other way around?
• tambourine_man 9y ago
  >A resource-hungry 3D game or similar does not fit into my definition of “app” That's… one interesting definition. Have you consider writing websites instead?
• AndrewKemendo 9y ago
  Consumers don't want to download any more apps unless there is a SUPER compelling reason to do it. If you don't need native functionality, or video capability, then mobile web is going to be a 1000x better choice.
  • k-mcgrady 9y ago
    App downloads and revenue increasing year-on-year (for both iOS and Android) seems to disprove this
    • AndrewKemendo 9y ago
      Only in volume, not percentage, there are just more people joining the marketplace. Apps vs mobile web as share of user experience is dropping. Makes sense after all, its easier, faster, cheaper, less storage used etc... and more accessible to get to something on safari or chrome than publishing an apk or ipa Now, the real question to me is where are people spending their time? Pretty much all in apps, but only for the top 10-20 apps in the marketplace - which means that unless you have a top 10 app that is going to pull people off of their FB/SNAP etc...app and onto yours, then don't waste your time. [1]https://venturebeat.com/2015/09/25/wait-what-mobile-browser-traffic-is-2x-bigger-than-app-traffic-and-growing-faster/ https://venturebeat.com/2015/09/25/wait-what-mobile-browser-...
• cletus 9y ago
  Sigh, this debate never ends. > You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android. This always reminds me of the quote: consistency is the hobgoblin of small minds. You see this "consistency" argument rear its ugly head all the time. I can remember hearing it when GWT was being pushed ("you can use your Java code on server and client"). The reality of course is far from idyllic. But that was completely predictable. You also see this argument with Node.js. The problem when you try and broaden something like this is it's incredibly difficult not to end up with something that doesn't simply combine the worst of both worlds. Now I'm not an iOS/Android dev but from the sidelines I tangentially keep abreast of what's going on. It seems like React Native has some real potential here. Like some benchmarks I've seen show there's not much of a performance hit. If (and that's a big "if") this turns out to be the case, pulling this off would be a rare feat of success. Now even if it succeeds, there'll still be a cost. I'm sure there are some things that are easier in iOS/ObjC/Swift and Android/Java. For one thing it would be difficult to abstract away the different memory management models (IMHO ref-counting rather than GC in iOS is a competitive advantage). Anyway I don't think Apple killed Web apps or hybrid apps. Two things killed those: 1. HTML/CSS/JS is honestly horrible. Particularly layout in CSS (mainly pre-flexbox). Performance isn't great. People end up with Web apps with 1M+ DOM objects. That's just crazy. 2. Performance is just so much better on iOS/Android (rather than HTML5). Part of this is you know a lot more about the target platform than with a Web app.
  • lnanek2 9y ago
    Yeah, I think the author is kind of out of date. Even people who go the cross platform route nowadays don't use Cordova, where PhoneGap went to die, they use something modern like React Native, which doesn't have the HTML performance penalty.
• coldtea 9y ago
  >If It Weren’t for Apple, Hybrid App Development Would Be the Winner Over Native Thanks god for Apple, I guess, then... Imagine a headline like: "If it wasn't for Apple/MS, most of your desktop apps would be Electron based". How would you like that?
• eecc 9y ago
  Peeps tend to forget that back in the days when "Apps" became a thing, responsive design wasn't even a term...
• rstarback 9y ago
  I disagree with the author that "the Hybrid approach is the right choice for your next app". Speaking from personal experience, the time it takes to create workarounds for UIWebView/WKWebView is only slightly less than the time to get familiar with Swift/UIKit. With knowledge of mobile paradigms it is easy to pick up Java/Android. The advantages of creating two separate native apps are designs that fit each individual platform, better battery life, and overall better performance. The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship. However, the time difference is not as large as one may think. By continuing to invest in hybrid app development the author didn't learn valuable iOS/Android native app development skills and created an app that isn't as performant or designed to fit each platform.
  • jonathan_app 9y ago
    the time it takes to create workarounds for UIWebView/WKWebView is only slightly less than the time to get familiar with Swift/UIKit This times a thousand. I have wasted untold hours on clever paperclip-and-gum techniques to get WKWebView to be something it isn't: predictable and usable. I still develop hybrid apps for clients (glorified web pages, really) but for personal projects I will never, ever go back. Kicking myself for not learning Swift earlier.
    • MBCook 9y ago
      When my job looked at the JS app idea (3 or so years ago) that was one of my big takeaways. If we made a web app, we would spend just as much of not more time polishing it until it felt native than we would have making it native on the platform in the first place. It wasn't a highly complicated app.
  • mnm1 9y ago
    "The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship." So in other words, he spent less than 50% of the time needed to build both an iOS and Android app (if we assume learning Java and building the Android app will take equally as long as learning Swift and building the iOS one). Sounds like a huge win if one can live with the other tradeoffs.
• tritium 9y ago
  Man, wouldn't it be awesome if there were something to inform the reader what is meant by "hybrid app"? ...because neither "hybrid" nor "app" is an ambiguous term taken on its own. Hey, look, here's some niche API, that few people are familiar with, but blame Apple about... something. Get mad about it! OMG. SUCH APP. WANT DEVELOPMENT. MUCH RAGE. HYBRID APP. WOW.
• jorgemf 9y ago
  > Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/ https://techcrunch.com/2012/09/11/mark-zuckerberg-our-bigges... I think Hybrid has it market and it makes sense for some apps, but for medium/big companies you probably end up with a native app (or a hybrid app with more native).If the app is native you can do more things in the device, there is better documentation for how to do complex things and you don't have to use Javascript. Swift and Kotlin are much better languages to use for apps. But I think the main point is that apps, nowadays, most of the logic of the app resides in the server, so the apps are only front ends. And to make a nice front end with smooth animations it is easier to do it native, because animations are different for every platform, so there is not much code to share.
• scarface74 9y ago
  The whole article misses the point. The entire purpose of WKWebView is a compromise that let's the user take advantage of all of the features of Safari within an app -- passwords, bookmarks, shared cookies between the view and Safari, native performance -- without the security implications of random apps having access to everything you type in. If you enter your password into a web view, the app has complete access to it. If cookies were shared in a web view like they are in a WKWebView it would be a major security vulnerability.
  • flai 9y ago
    The thing is: There is no fast browser that also is flexible, in contrast to android.
    • scarface74 9y ago
      Sure there is... the article even said that WKWebView and Safari are faster than his Samsung device. The problem is not that the browser isn't fast, the problem is that he wants to make a sub optimal cross platform app that's not optimized for either iOS or low end Android devices that most people are buying.
• potatolicious 9y ago
  Boy is it time for another round of "Hybrid Apps, Wave of the Future!"? Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK existed, and writing and shipping Android apps for the last couple of years. My opinions may be biased. First, a couple of observations to get out of the way that may support author's thesis, but IMO not really: - A good portion of existing native apps should not be apps at all. These are apps for services that are infrequently used, and should have been websites the entire time. Note that I'm saying they shouldn't be apps at all - native or hybrid - they should simply be websites. Because of the friction of installation, shipping an app for something users will only very occasionally use, is pointless. - If your apps are strictly by-the-numbers CRUD apps without background activity, then a hybrid approach is likely the best bet. Now that that's out of the way... > "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough." This assumes the lack of competitors who are willing to put in the effort to make a performant app. It should be noted that janky, slow UIs that are "good enough" were the norm before the iPhone came around and raised everyone's expectations. If you're building an app for Comcast or your local utility company - where competition is definitionally non-existent, then yes, it doesn't really matter as long as the hybrid version is fast enough. For markets with competition, this simply produces a large window for someone to eat your lunch. > "You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android." This seems user-hostile. For all of Apple's warts, one of the great things they did around the iPhone is to rebalance consumer software development away from developer convenience and towards user convenience. The 90s and early 00s was defined by software that was difficult to use, engineered to be just "good enough", and largely the process was geared around developer ease rather than user satisfaction. Yes, as devs we want all kinds of shortcuts to make our lives easier - and by all means we should pursue them - but the market in many places no longer tolerates the UX compromises of certain shortcuts, and consumers have come to expect apps to respect their platform's UX standards and have a high performance bar. Case in point: Java apps also allowed devs to ship multi-platform from a single codebase, anybody here actually enjoy using those things? Practically nobody does that any more. > "Viewing changes on your device during development is nearly instantaneous." This is legitimately a great feature of web dev vs. native. There is a lot of work being done on iOS and Android to shorten the preview cycle - but it's nowhere near web-quick (and is unlikely to ever be). But again, this is a developer convenience, not a user convenience, and like all developer conveniences, it should only be pursued without harm to user experience. > "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval." This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice. You cannot ship features to the App Store without a binary update. This is also not a hypothetical - Apple has recently started ratcheting up enforcement on apps that significantly modify functionality while bypassing the review process. If you want to build a hybrid app despite my objections, by all means, but do not use code push features and especially do not use it to bypass Apple review processes. This will end poorly for you.
• s73ver 9y ago
  I can't say I buy this for a second. Neither the idea that hybrid apps would be the winners, or that it's Apple's fault. Lest anyone forget, the iPhone's original "SDK" was web apps. People cried out for a native SDK.
• blahbwah777 9y ago
  If the complaint is "cross-platform apps would be ubiquitous if not for Player X" why stop at Apple? Can't we point to this trend more generally being driven by Microsoft for years? Or IBM before them? This is a symptom of our economy as a whole. A big player dictates what is acceptable output. Not directly, but through a kind of market capture. I get tired of these very specific, customized complaints about society, that ignore the bigger picture cause.
• scarface74 9y ago
  If an app is slower but "good enough" on his Galaxy S8, how well does he think it will run on the sub $200 Android phones that most people are buying? http://www.androidauthority.com/apple-iphone-average-selling-price-749145/ http://www.androidauthority.com/apple-iphone-average-selling...
  • samdelgado 9y ago
    I wrote the article and just saw that there was a discussion about it here. I actually primarily tested it on an LG G2 and Motorola Moto G 3rd gen. Both of these phones are fairly slow, and my app runs about as quickly as any other app I open on them.
• bartread 9y ago
  Hmm. I dunno. I worked on a cross-platform mobile development tool called Nomad for Visual Studio (from Red Gate Software) for a while back in 2013, since retired. Back then hybrid mobile apps, for the most part, absolutely sucked balls in comparison with their native counterparts. Performance, in particular, was often choppy, and it largely wasn't possible to offer an anywhere near native user experience. (I know, I know: everyone's going to point at Untappd, which was 2013's poster-child hybrid app, and talk about how awesome that was, but whilst it was decent, it was still noticeably hybrid. And, yes, there were and are companies selling native controls that can be used from a hybrid app to make things easier/better/more performant.) The experience of working on Nomad taught me one thing: if you were serious about mobile app development, and you wanted to provide users with a great experience, your only option was to go native, be that on iOS or Android. Four years has passed and, nowadays, the situation has improved quite a bit for hybrid apps. Still, it's disingenuous to suggest that most apps would be better as hybrid. Sure, your app might run "fast enough" for many scenarios, and the user might not be able to even tell the difference between native and hybrid implementations, but if your hybrid version burns 10 times as many CPU cycles as its native equivalent would you're caning the battery life of the device, which is an aspect of mobile performance that seems to escape a lot of people. Speed is one thing, but how long you can continue to use the app or device also matters to people. (I say this as somebody seriously considering porting a couple of HTML5/JS games to mobile at some point in the future.) This problem becomes particularly pronounced if you're building an app - and this goes far beyond games - with any kind of fancy media component, custom drawing, etc., any kind of rendering, doing anything cool/fancy with music or sound. You can take advantage of WebGL and shove a bunch of work onto the GPU, which will almost certainly do better battery-wise, but if you have some idea that you can just hack something cool and flashy together with HTML5, JavaScript, and CSS, and it won't drain the battery and make the device quite warm, you are likely to be disappointed. I will agree that iOS is an absolute pain in the neck to develop for when it comes to doing anything remotely interesting with web technologies, regardless of whether that's as a hybrid app or even just in browser. But that's a long rant for another day.
  • robterrell 9y ago
    I agree -- energy use is a shamefully under-exmained performance metric. Xcode and Instruments has some solid tools for monitoring this, but if he's a developer who refuses to learn Xcode anyway, he's not using these tools.
• anotheryou 9y ago
  try using some nice animations...
• martin_bech 9y ago
  It seems like this is the authors first time creating a hybrid app, and some of this stuff i highly skewed. I and others have had horrible problems with performance on android, the Chromium engine for instance is not available on all devices, and rendering is not guaranteed to be universally the same across devices. One fix is to use the Crosswalk add on, which bundles a webview with your app.
• valuearb 9y ago
  The author has a shiny hammer, and sees every problem as a nail. For example, I just finished implementing an iOS app that uses a background operations queue for network operations. It's super energy efficient. It doesn't care whether there is an active network connection, the queue will regularly check network access and intelligently retry operations until they succeed. It will continue uploads/downloads in the background, and restart them when the app or phone is restarted. It submits some operations concurrently depending on bandwidth and server, to maximize throughput. It has a smart algorithm for syncing server and app data, that also happens in the background. The user doesn't have to know or care about any of this. They only know that submitting a form always works instantly. And that they can review filed forms from other users even when far out in the boonies, away from any network service. This is the kind of polish that's really hard to do in hybrid, especially power efficiently.
  • ianai 9y ago
    Further, it's far from unheard of for hardware vendors to specify a toolchain.
  • paws 9y ago
    That sounds like an excellent outcome! If you would consider writing up your experiences in a blog post I'd be interested in reading.
    • valuearb 9y ago
      I would like to try. Any blogging platform you'd recommend?
  • exclusiv 9y ago
    You can do that hybrid with PouchDB.
    • valuearb 9y ago
      Nope. It's not energy efficient, you can't control concurrency, and you can't utilize iOS app background time. PouchDB is a nice solution that gets you most of the way for most uses, but it's also another layer. When your pouchdb database suddenly won't sync on iOS, or your battery usage skyrockets, you are in debug hell trying to figure out why. I really like knowing what operations are running on which threads, so it's easy to tune/debug. For a commercial app, debugging problems can easily be most of the work, I want to make solving these problems correctly to be as easy as possible.
• rezashirazian 9y ago
  You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval. This goes against Apple's terms and conditions. Because of this alone, you can have your app removed at anytime.
• williamle8300 9y ago
  If notifications could be brought to Hybrid Apps... that would be the swan song of iOS/Android. HTML5 can access all of hardware on the phone but lacks notifications so it's still not viable to only make Hybrid web apps.
  • valuearb 9y ago
    I think you are missing huge swaths of functionality.
  • exclusiv 9y ago
    You can do notifications on hybrid.https://docs.ionic.io/services/push/ https://docs.ionic.io/services/push/ You can even do push notifications on webapps. https://developers.google.com/web/fundamentals/engage-and-retain/push-notifications/ https://developers.google.com/web/fundamentals/engage-and-re...
  • enjoiful 9y ago
    I don't think HTML5 can access the phone's camera. For my app, this is critical and another reason why we're stuck on native.
    • negative34 9y ago
      Get media device, you get camera and mic
• bschwindHN 9y ago
  Oh I always have fun trying to break these apps. This one did fairly well, but it's still obvious it's not a native app. Does that matter to most of the end users? Probably not, but they probably don't appreciate the heavy RAM usage and extra CPU incurred from running a language interpreter inside of your application. Here are some notes after I downloaded and played with it a bit on a Nexus 5: - Scrolling slowly with your finger held down on the settings page leads to visible stuttering, though flick-to-scroll seems to run at 60 FPS - Tapping the menu button in the bottom right quickly a few times can lead to a darkened screen with no navigation menu displaying - Doesn't respect the back button on Android - The app takes 224 MB of RAM, the next highest is spotify at 176 It's pretty impressive for a Cordova, but I feel like it's more effort to try to mimic native functionality with web dev tools. I still think React Native (or at least the idea of React Native) holds promise, because at least then you're getting native UI elements which behave much more consistently and are more robust against random tapping and swiping on the screen.
• pmontra 9y ago
  > Needing a Mac to compile the app I remember a recent announcement of Microsoft about using xamarin to generate an iOS app without xcode and with the ok of Apple. It was on HN but I can't find it. I assumed that without xcode means without a mac.
  • Kipters 9y ago
    You can develop an app without a Mac using Xamarin Live Player, but you still need a Mac to build the standalone package to publish to the App Store
• JKCalhoun 9y ago
  By all means, we should bring back Visual BASIC for developing mobile apps.
• itsdrewmiller 9y ago
  This article would be great with the title "Apple makes it unnecessarily hard to develop hybrid apps". It's obviously not too convincing on the much larger question of Hybrid vs. Native.
  • bartread 9y ago
    Agreed. I think you've captured the essence much better than my rather long-winded screed above, although there is a good point about battery life buried in there somewhere.
• cxromos 9y ago
  If it weren't for Apple there wouldn't be app development.
• digitaltrees 9y ago
  It's funny. I remember when Steve Jobs announced the original iPhone and said that there wouldn't be any native apps because web apps should be sufficient. I also remember the outcry from developers and complaints about apple's tyrannical closed ecosystem. It's interesting that things are changing now and now people are complaining in the exact opposite way. I guess Jobs was right again, just too soon as usual.
• valuearb 9y ago
  I understand some of the frustration with Apple. You need a Mac for development, you need iDevices for testing, the dev program is $99 a year, and you need to use their tool chain. Their web views are not tuned for hybrid apps, etc, etc. Lots of that is driven by our experience with open source, where you can usually build and release on any platform and your choice of hardware is your own. But these complaints are also very selfish, almost delusional. The author wants access to the largest and most lucrative App Store on the planet, yet they don't want to pay for any Apple hardware to do it. And they think Apple should expend resources to ensure their specific cross platform approach should make it easy to write android apps as good as their iOS apps. Apple makes money only because people buy its hardware. A big reason for the success of the iPhone/iPad is that their apps were historically better than similar apps in android. It's awash with top developers investing substantial amounts to build and update apps. If you don't think it's worth investing $1,000 to develop for a store that pays out over $20 Billion a year to developers, why does Apple need you? Why should they invest to build developer tools for devs who won't buy Apple? Why should Apple invest in cross platform or dumb down its own APIs to help eliminate significant differences with Android? Why shouldn't they focus on better native features for their web views instead of making them better for cross platform devs? How will either sell more iPhones? There is nothing wrong with developing for a single platform. Google Play may surpass the App Store this year, obviously Android is a fine platform to sell on. But never expect a company to undercut their very business model just to make it easier for you to reach their customers.
  • pjmlp 9y ago
    It is the free generation, they want to get paid but not pay for their tools.
  • majewsky 9y ago
    > The author wants access to the largest and most lucrative App Store on the planet, yet they don't want to pay for any Apple hardware to do it. They're already paying a 30% cut of all app sales.
• dep_b 9y ago
  Let's completely forget about the mess that modern web development is nowadays with frameworks for frameworks that manage your frameworks making build chains for C++ projects look refreshingly easy all of a sudden, the requirement for tools for fixing really basic stuff like having constants in a CSS file or the hacky way most frameworks "integrate" with JavaScript and your HTML. Lets forget about JavaScript being forced upon you, a language that has so many holes in it there are a fistful of alternatives that compile more intelligent code to JavaScript just to take the pain away to deal with the intense stupidity of native JavaScript. Then there's the everlasting "can I use feature x on version y of browser/platform z, and if so does does it use a different syntax?" unless you dumb down to only Android and Safari Mobile and don't support all web based platforms (killing one of the main attractions of a hybrid application by choosing so). Ignore that too. Then we can talk how you try as hard as possible to run away for the development stack of the company that created the product you are trying to develop for. Nobody ever complained about having to use at least some part of the Visual Studio / .Net or Win32 / Windows toolchain for the past 30 years to build a Windows application that really would look and behave like a Windows app even when you were just using Java (the hybrid app platform of the past), but that was of course something completely incomparably different. But somehow actually needing a Mac and an iPhone to get work done in the Apple stack: Crazy! Nuts! How can they think everybody has a Mac and an iPhone to spare? Getting WKWebView to hack into native code and vice versa is a pig, but the way Google allows you to hack into everything all of the time has it's own drawbacks mainly in the form of privacy and security.
• Tloewald 9y ago
  In the end this comes down to a gripe that you can't use Chrome for web views on iOS owing to platform restrictions (and, secondarily, that you need to use XCode to submit to the App store, which I agree with, although it's pretty painless if you have a Mac). Guess what, you've now got that problem for Windows (the app store is blocking non-MS browsers) too. The problem doesn't exist for Android because Android is the new Windows -- for good and ill. A lot of web app developers (myself included) are highly reliant today on Chrome in the way that we were dependent on some flavor of IE in the past. In my case, I need WebRTC and the only other major browser that supports it right now (FireFox) does it so badly that in effect I'm developing exclusively for Chrome. That said, all of my non WebRTC code is as agnostic as possible, runs fine on Safari, and Safari/Webkit is supposed to get WebRTC "real soon now". This is essentially a "Safari is the new IE" meme in disguise. The closest thing to the new IE is whatever browser folks are treating as "the web" and that's Chrome right now. Don't forget that IE became the old IE in part because it delivered features programmers clamored for and was the best browser for most people for a long time. It only stopped being dominant because it stopped satisfying users. By most accounts users love Safari on iOS as a browser. If it's not a fabulous app platform that's because Apple isn't trying to meet the needs of app developers with Safari.
  • limeblack 9y ago
    I don't agree much with the article posted but I do slightly agree with "Safari is the new IE." The problem with IE was that is was packaged with the OS with no way to uninstall. iOS is worse in the regard that you must use WebKit if the you decide to create your own browser and Safari is packaged with the OS. Chrome is the one of the first to receive new features from what I have gathered but I guess it all depends.
    • MBCook 9y ago
      My disagreement with the 'Safari is the new IE' is that while Safari may not be deploying feature X, it's still updates with new features every year. It's a preference issue. IE was totally static (except for some security updates) for YEARS. It's lot they didn't add sexy new thing X, it's they didn't add anything. I don't think it's a fair comparison because the situations were so different.
• HodGreeley 9y ago
  The native/hybrid/web discussion has been going on a long time. The general consensus I've found is that web/hybrid is fine for some things, like magazine style apps, and untenable for more complex needs. The app described seems to fit into the magazine style category (and was developed on a pretty high-end device). So to me this comes off as a "works for me" inappropriate generalization.
• htormey 9y ago
  Nah. The main reason why Hybrid web apps suck today is because using a web view to render your ui fundamentally inserts a middleman between you the developer and the underlying memory management and ui rendering systems. This limits the type of apps you can build. Web views dont allow you to embed native components (I.e uicollectionviews)into HTML/CSS. It's an all or nothing solution. This makes it hard to work around certain categories of performance problems. Today this no longer the case But historically (around 2011-2012) the frameworks and tools available to web developers (jquery, es5)were inferior to those available to native developers. Non hybrid approaches like React Native have a much better chance of being the "winner" today over traditional native development.
• khedoros1 9y ago
  > A resource-hungry 3D game or similar does not fit into my definition of “app”. Interesting. Why not just say "There are categories of apps that my argument doesn't apply to"? > You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval. That's a benefit to the developer. It's only a benefit to the users to the extent that the developer's and users' goals coincide. I strategically refuse to update certain software on my phone. Software that doesn't give me that choice usually ends up uninstalled, because it usually changes unexpectedly in a way that makes it unsuitable for my use.
• DiNovi 9y ago
  this is amusing when you consider how reluctant Steve Jobs was the native app development when the iPhone first came out. He wanted everyone to build web apps!
• barnabee 9y ago
  I downloaded the app (iOS) and even if I'd downloaded it thinking it was something I might use longer term rather than to evaluate the claims in the post, it would likely have been deleted within an hour. It fits broadly with my previous experiences of hybrid apps: - touch targets behave oddly - touches sometimes don't even register and you have to tap multiple times (e.g. moving between tabs, dismissing modals) - menus, scrolling and transitions don't feel right (the "physics" is all wrong) - reopening the app gave me the login screen and a spinner while it sorted itself out multiple times - I had to actually log in again once because it just appeared to forget the login info (within 10 minutes) - the UI in general lacked polish and felt clunky Honestly if this was a corporate form filling or inventory tracking app, the trade-off might be fine, but if you're trying to gain and retain users it's likely not good enough for anything but an early proof of concept. Maybe I'm just picky but it amazes me that someone could produce this (given how good we know things can be) and think it's good enough to justify a praise-filled blog post about the merits of hybrid apps.
  • samdelgado 9y ago
    Thank you for the feedback.
    • barnabee 9y ago
      No problem, I hope it doesn't come across too harshly but it's those little things that can make an app frustrating. It'll be interesting to see when/if hybrid does get "good enough" as there are certainly benefits if you can pull it off! I'm already convinced by React Native's approach and have seen really great apps built with that tech (although they keep things easier by sticking with native components) and am intrigued by Microsoft's ReactXP as a more cross platform option.
• ranci 9y ago
  >> Rizer is a Hybrid app that uses Apache Cordova and its plethora of native plugins Plethora of native plugins? Why is it a good thing for my app to have a plethora of dependencies on obscure plugins that someone else has to maintain and update otherwise I am completely blocked from developing? Nevermind the fact that I have to learn all the intricacies of said obscure plugins? Just to be able to do what I can already do more efficiently in native? >> Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps Why are you leading with this after explaining the app you built? Show me why it's better, don't just act like an authority and tell me so. And you don't appear to be an authority on mobile app development, it appears any experience or credentials you have are in javascript. You made a single mobile app with hybrid and are now ready to declare that going hybrid is the right choice for almost everyone? >> A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough. Thanks, and you're right! Native apps are much faster and always will be much faster than the apps you seem to want to make. How one can determine if their hybrid app will be "fast enough" ahead of time is as clear as mud. For apps that do significant things and need to do them quickly, I suspect many hybrid apps won't be "fast enough" and the user will be able to tell that they are on a website. But you'll have to just engineer it and find out later if the framework has an unconscionable defects or limitations. Happy coding (oh and try not to use jQuery)! >> A resource-hungry 3D game or similar does not fit into my definition of “app” Games are apps too, but don't worry, there is a real cross-platform technology out there called Unity for you. You won't be able to use JS with it though I am afraid. >> In these cases a native app is almost certainly your best option Almost certainly? Certainly. >> You get to utilize your existing JS, HTML, and CSS skillset You are assuming that someone who wants to make a mobile app has an HTML, CSS, and JS skillset. Why are you assuming this? Are you writing this because you have a certain set of biases and preferences for web technologies or because you actually think hybrid is the best way? One must wonder. >> single codebase Single codebase isn't a selling point if your app is slow and full of workarounds piled on top of workarounds that probably would have been solved with a single line of native code. >> There are less than 10 times throughout my project that I needed to branch the code based on the platform the app was running on This is utterly embarrassing, and very telling to me that you think it is a selling point. The entire point of doing a hybrid app is to NOT be doing this. "I only had to do it 9 times!!" should not encourage anyone and truthfully could only be seen as encouraging by someone who was dead set on using web skills in a mobile arena to begin with and was determined to make any justifications to do so. >> Viewing changes on your device during development is nearly instantaneous. Great. So are native apps. You click the little play button in the IDE. Nearly instantaneous. Again, it's a mystery why you think this is a win for hybrid. >> You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval. APK upload for the Play Store is almost immediate. Yes, iOS has a significant review time which has been whittled down to about 2 days. I don't think this is really paramount to anyone. You forgot to note though, a downside of doing Hybrid is that Apple rejected your app 7 times which wasted far more time than you would have gained on any of this other stuff. >> Choosing between these two WebViews sucks. Not Apple's fault. This was your choice. >> Thanks to some fantastic work from the Ionic team, some masochistic developers (myself included) are utilizing WKWebView in their Hybrid apps. I will be the first to say that when WKWebvView works, it really works. Sorry, reading between the lines here -- are you encouraging people to use things that you KNOW don't work? If so, why? >> Inability to access files that don’t exist in the app’s root “www” folder. Not Apple's fault, your fault for choosing Cordova. >> Numerous CORS (Cross-Origin Resource Sharing) issues, including being unable to extract image data from a canvas that was drawn using a local image. Not Apple's fault, your fault for choosing Cordova. >> Unpredictable vertical scrolling behavior, and in my experience, completely broken horizontal scrolling. Not Apple's fault, your fault for choosing Cordova. >> No programmatic control over showing and hiding the keyboard Not Apple's fault, your fault for choosing Cordova. >> App-breaking conflicts with stable versions of the Cordova SplashScreen plugin Not Apple's fault, your fault for choosing Cordova. >> App-breaking conflicts with stable versions of the Cordova In-App Browser plugin Not Apple's fault, your fault for choosing Cordova. >> Without a doubt, creating Rizer was a longer and more frustrating experience than I expected it be… thanks to Apple. Not Apple's fault, your fault for choosing Cordova. >> In my experience, all of the potential show-stopping issues caused by going with the Hybrid approach have workarounds. Oh, awesome! Just what everyone was looking for. How to build an app with workaround piled on top of workaround piled on top of a hack piled on top of a workaround piled into a shitty webview. >> They are frustrating to discover and implement, but they do work. Here we go again where you subtly or not so subtly admit the thing which you are advocating for actually sucks (and is the most hated technology on stack overflow). >> It will absolutely take you longer to develop a Hybrid app than it should Correct! >> will feel just as fast as to your users lel
• Shorel 9y ago
  Much better for the developer, but also a worse experience for the user. I have installed a desktop application for Slack, and it eats RAM like crazy. I would love to have a fast alternative that's not IRC in the command line. I want some middle ground like Evolution is for emails. My take is: when products change too fast, this fast iteration development wins. When products have a stable featureset and performance can be a factor, native clients will win. And this has nothing to do with Apple rules or limitations. In fact, this is what is happening between SublimeText and Atom. If both had the same price (zero) and license, I don't think anyone would use Atom.
• kbutler 9y ago
  Of course, if it weren't for Apple, HTML5 development for mobile wouldn't really be a thing either... So, I'd say give Apple credit for launching HTML5 mobile development, but recognize that they haven't pushed it to become a fully viable platform.