If It Weren’t for Apple, Hybrid App Development Would Be the Winner Over Native
hackernoon.com
hackernoon.com
>> 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.
So,you've pretty much established yourself as an expert in the ecosystem. That actually lends less credence to your counterarguments in my eyes. It's all too easy as an expert to overlook the pain points that you've become accustomed to, or did not notice as they were slowly layered up over the years. In my experience, the expert that rages against the system they use is far more likely to have valid input than the expert that apologizes for it.
That's not to say you're wrong. Just that in my eyes the likelyhood of you being right dropped as you explained how much experience you had (past a certain threshold. Amateurs often don't understand enough to accurately critique as well).
Same holds for the inverse: it's easy as a newb to consider everything as a pain point, even if it's a well designed procedure.
Sure, that's why I noted as much with my last sentence. :)
Seriously if your app gets rejected that much that you'd bitch about it, it's because you're not paying attention to what you're doing and/or are up to some shady shit. It's really not difficult to avoid.
I'm not saying JS doesn't have more general use constructs but HMTL/JS always feels like a strange, uncomfortable way to describe native UI. I guess what I'm saying is that you tend to feel the compromise.
In the end, I just think the language and tools used by the teams that build core apps for a platform will always beat those designed to abstract away what makes the platform special and compelling.
Instead of a common standard we have 3 competing stacks.
Having developed several hybrid and native apps on both platforms, I can say that usually the worst layouts are done by devs with experience only in one platform. From a high level, it's easy to accomplish the same thing on all platforms, animations included. It would be a ton easier if they just would actually converge.
Storyboards and xib files use XML as a serialization medium, but you never actually work with the XML directly, it's literally just an underlying file format and the only reason it's used over a binary format is to make VCS merge conflicts easier to deal with. And more importantly, the actual built iOS app does not contain XML. Instead the build process constructs the view hierarchy based on the storyboard/xib (just as the interface builder editor does) and then serializes that to a binary plist (this is why UIView and UIViewController conform to NSCoding).
None of that changes this fact for me: JS/ES is completely irrelevant to me as a development language. I've learned a bit and found portions reminiscent of a few other languages, but I don't really have a practical use for it, myself.
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.
Boyancy is the foundational concept of naval transportation, but it's not the foundational concept of all transportation.
[*] Not sure if I was right before or after, check back in a few years :)
In Android, our beta users download the app from the Play Store just like normal. The app automatically updates and for them, performs basically exactly like a normal app. On iOS, every update has to be a manual intervention for a beta user.
Look, the whole point of our beta community is to get early testing on new code. If half or more of the community put off updating for a few days because it's an annoying process, that's the exact opposite of useful. And it's worse than that -- I have no doubt that a great many of our beta users are now significantly behind our normal production users, because normal production users get automatic updates and beta users don't.
Almost entirely avoided still means you have to go out and buy a Mac and keep Xcode running on it.
I understand that some of these EULAs aren't enforceable everywhere, in the form of consumer protection laws inhibiting what's basically perceived to be bullying behavior. At least in the U.S. consumer protection laws are weaker, depending on the idea that when consumers are bullied, they'll spend their money elsewhere.
In a global market, asymmetric consumer protection laws aid bully behaviors. The countries were people are safe flaunting EULAs may have higher usage rates of software with unfavorable EULAs, rather than using alternatives with a more favorable EULA.
I totally understand not liking the license, but if you click the agree button when installing the software on non-Apple hardware, you're basically lying.
If you acquired Mac OS X legally how would this be illegal? I will admit acquiring it legally could be tricky, but that is not what we were calling illegal was it?
The (mostly-untested) theory is that clicking "I agree" on the license is a legally-binding contract between you and Apple. The Mac OSX license repeatedly says that a requirement of the use of the software is that it be used on Apple-branded hardware.
So, "illegal" based on unlicensed use of copyrighted material or based on breach of contract. At least, that's how I understand the argument.
Seriously, I can never take this argument seriously.
I can easily develop iOS software without owning an Apple computer...but I can't do it legally. I'm happy I'm not in mobile dev, and this is one reason.
Yeah if it's just Swift/ObjectiveC vs HTML/JS/CSS, then it's a moot point, just pick one.
However it's Swift/ObjectiveC/Java(Andorid) vs HTML/JS/CSS
The latter comparison is not even equivalent.
> Provisioning Profiles
Provisioning profiles are still an annoyance if using tools such as Jenkins to compile and distribute builds, as xcodebuild has to be used to build the app. This forces you to manually set up the profiles and consequently run into many of the problems that have been solved with automatic signing. This also affects ad-hoc deployment as the process of adding new testing devices requires the generation and download of a new ad-hoc provisioning profile onto the Jenkins machine.
>Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
I don't think this is the case of all apps. In the past few months my company has easily over ten rejections, due to the fact that our app targets a niche that the reviewers are not knowledgeable on. For instance, we received two rejections in the last month over the wording of our background location services requests. We use industry specific keywords that reviewers did not know, but users of our apps most definitely would know. It is true that these issues are generally sorted out easily, but we still receive rejections and it can get frustrating.
Regardless, the author stated he received 7 rejections before being approved. It seems to me that if the author's app was rejected this many times, he failed to follow Apple's app review guidelines in some form (Complete conjecture of course).
Yes, there's an appeal process, and yes, it's much faster than it used to be. But it has happened enough that I can't confidently predict how long an update might take because of uncertainty with the review process.
Not a terrible assumption. There are way more web devs than any others.
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.
Actually, CouchDB is great at supporting offline-first, local data that syncs behind the scenes.
Here are two mobile implementations that will work cross-platform:
https://github.com/couchbaselabs/Couchbase-Lite-PhoneGap-Plu...
Hybrid definition: a thing made by combining two different elements; a mixture.
Using a cordova plugin to tap into native code while developing with web standards is a hybrid approach.
So what would CouchDB give me? Offline data sync? That's useful but wasn't hard to implement on my stack.
The reason I didn't use something like CouchDB is the time saved up front probably wasn't worth the cost in optimizing/debugging. It's just much harder to track down and fix bugs and address bottlenecks when relying on a large library designed for general use cases to do much of it.
I'd also have to buy-in having CouchDB on my server.
In this case I'm pretty sure I made the right decision. If the requirements were less rigorous, CouchDB Orr something similar might be better.
I also personally find it way easier to use than the standard stores on Android and iOS for on-device persistence. 2.0 is coming up and should simplify the use a bit, too. So as it stands now I'd say the main sweet spots are, ironically, around the two ends of the spectrum. Easy to use for persistent local storage with no sync, and the industrial strength solution when used with sync.
(I work for Couchbase on the mobile side.)
I have lots of business logic on back-end tho, how hard is that to implement on the server?
Most notable: You write your logic in JS (See _view and _list functions). There are no transactions. Geolocation is not easy.
As someone who has never developed for mobile, is that OS provided, or something you had to implement yourself? It seems like something like that (at least for HTTP) should be included, and with some rich controls to toggle whether jobs should persist app closes and restarts, or jobs should wait for wireless or are okay on cellular, whether jobs of type X should replace other jobs of type X (no reason for 5 queued requests for latest updates to the same feed to all fire when conditions are right...), etc.
There are lots of classes to help with setting up and tearing down network connections, and convenience classes for standard things like encoding/decoding, parsing, etc, but complex task management is entirely up to the developer.
Operation Queues[1] do provide some of this functionality in a non-network-specific context and can handle priority/concurrency/dependencies between multiple tasks, but it's still up to the developer to layer any network activity on top of it.
Things like limiting some connections to cell/wifi, job persistence between app instances, and job deduplication, are entirely in the dev's hands - though the system does provide all the necessary APIs to implement all of the above.
A caveat though - the OS itself imposes some concurrency (max concurrent network connections for a single app) limits in an opaque way for the purposes of throttling, but the developer doesn't really have access to this.
[1] https://developer.apple.com/reference/foundation/operationqu...
I bring that up because this seems to be a common pattern in Android development, where in contrast to native desktop work, you look to the system first to do anything hard, and only build things yourself if the system absolutely can't do it, or the way the system does it can't be bent to do what you need. I'm not sure how much this applies to iOS development too, but I presume it's similar.
That means that hybrid development may be much more practical than you would think, because you aren't supposed to be building the things that are hard in hybrid/JS, as the system already handles it for you much better than you could. I'm not actually sure how these hybrid frameworks handle calling out to things like that, presumably they have a way to abstract it out, since they wouldn't have much point to existing without that.
[0] https://developer.android.com/training/sync-adapters/creatin...
I remember prior to Cordova building an app that had native image resizing/uploading code for both iOS and Android, and native notification support, but used a WebKit view for the UI.
That was a significant amount of work that would otherwise need to be duplicated across the two platforms, and double code maintenance.
Hybrid doesn't mean "don't ever touch native code," it simply means "don't touch native code unless you really have/want to."
In a bigger sense I don't understand why people make it such a big deal that you need to learn two languages. Swift and Kotlin are really simple to learn. Granted I've been programming for a long time (over 25 years and 19 professionally) but I've worked in at least 10 different languages over my career and learning a new one is ALWAYS the easiest part of working on a new platform.
But ultimately my plan was to try Kotlin, and full rewrite so it was as optimal as possible.
Didn't get this - you will write an Android version?
Also, do you think two apps (one in Kotlin and another in Swift) can be done faster than a React Native (JS + platform specific code) that works on both, due to the tooling being so mature for each platform?
I'm starting a new job next week, and ironically I'm planning to ask if they've considered react native.
If you would consider writing up your experiences in a blog post I'd be interested in reading.
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.
The amount of energy javascript pages now take makes me in some ways wish we had the ease of blocking crap like flash back in the day to not make my fans spin.
Also a webpage or app taking up 900MiB of memory? Really, this is what I want? Hell no, i'll stick to what I have thank you very much.
Certain web developers are an interesting breed of late.
We live in an age of unparalleled abundance. "Evolution" no longer selects as aggressively against devs who are inefficient.
It still does - but now efficiency is measured in development/maintenance time.
If you want to use a WebView, you must invoke a WebView.
And that V8 engine contains functionality which is surprisingly similar to Chrome.
Except they decided to reinvent the wheel.
(Though, as the sibling comment notes, it uses JavaScriptCore, which is Webkit's JavaScript engine, not V8 at all.)
If you want to see what's going on in WebKit, just check out https://webkit.org. A simple way to follow along is to read the "What's New In Safari Technology Preview ##" blog posts (and install the Safari Technology Preview to actually try this stuff out).
There's always room for improvement, but it's not shit if you ask me. In my opinion it's the best mobile OS we've got.
The latest version of iOS runs on all iOS devices back to the iPhone 5 -- introduced in 2012. How many Android phones still get updates from their manufacturer 5 years later? When Apple releases a security patch, it's available from day one to all users worldwide over the air. Can you say the same for Android?
Have new iOS versions stopped getting aggressively slower on old devices yet? Technically running but in a broken way doesn't stop it being planned obsolescence. If that did change then great, more people should be made aware.
> Can you say the same for Android?
This is about iOS's faults, not Android's.
But even if the new OS runs slower on old devices, that's not even remotely Planned Obsolescence. Planned Obsolescence means they deliberately make older devices run badly in order to drive upgrades. But there's not even a snowflake's chance in hell that Apple is doing that, and saying they are is pretty insulting to all the work they do ensuring the OS is at least usable on those devices. The simple fact is, as devices get more powerful, the OS expands to take advantage of that power, and so when you run the OS on older hardware it's now doing more work than it used to and frequently ends up slower.
Android is open for anyone to do anything with, and there is no way to force someone to support something after they release it any more than it is possible to get them to not use Android in the first place.
If we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
If you don't want it, like if you are planning on installing your own OS or have other plans for the hardware then this is misfeature. It becomes a thing you have paid for but will never use.
Well...yes. Great upgrade policies: Apple. Crappy upgrade policies: Samsung, LG, HTC, etc.
Let's look at the flagships:
Apple: iPhone 5 from 2012 supports their newest OS release.
Samsung: Galaxy S3 from 2012 supports Android 4.3 and 4.4 (depending on model). Those are 2012 and 2013 OSes.
HTC: One X from 2012 supports up to Android 4.2.2.
LG: Optimus G from 2012 supports up to Android 4.4.2.
Google itself: Nexus 4 from late 2012 supports up to Android 5.1.1. A maintenance release from last year, with a base OS release 2.5 years ago...but certainly better than other Android vendors.
Android itself is still being updated as far back as 4.4.x, but that doesn't help much when the vendors aren't picking up the updates (and installing LineageOS tends to lose access to some of the features I paid for).
Do any android handset manufacturers ship updates?
Whether I buy a computer from Dell, HP, Lenovo or any other PC vendor, I still can get upgrades and security patches from Microsoft. I don't have to wait on the vendor for updates.
we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
Tell me one Android vendor who supports their phone with security patches for five years?
I have seen plenty of preinstalled crapware from all those companies that never gets updated.
All I am trying to say is that android, the OS is not the reason updates don't happen. The Vendor is and largely your point point agrees with me.
Are you really comparing the ease of clicking one button to upgrade Windows or iOS devices with using some semi supported "Android" OS that may or may not be supported for your phone?
I finally switched back to an iPhone, and realized how silly I was trying to convince my iPhone using friends to switch to Android. It just works. My friends don't care about kernels or custom ROMs. They want an OS that works, is secure, and stays updated. iOS does that. Apple will have to really mess things up for me to leave iOS at this point. For something I interact with on a daily basis, I don't have the time or the patience to deal with Android.
The things that iOS does, it arguably does better than Android. The things it doesn't do are what have kept me away.
External storage seems to be pretty rare on Android though?
My #1 complaint about iOS is that they don't really allow other browsers.
Not too rare. Google doesn't like it, so their stuff usually doesn't have it, but Samsung, HTC, and LG seem to have it in most of their flagships, anyhow. Maybe a generation skipped, here or there. It's not guaranteed, but not rare. I checked some budget phones from Blu, for the other end of the price spectrum. Some of those have microSD slots, too.
People really have no context...
Battery usage can still be a problem even if the app appears to run smoothly.
"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
That's probably putting it a bit too strongly, but "nobody complains" is probably putting the bar too low.
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.
The thing about phones is the immediacy of using it. Nobody uses a phone like you say.[0]
[0] Okay, nobody is a definitive. Almost nobody, then.
The idea I'm really calling into question is "So if you make it boot ten seconds faster, you've saved a dozen lives." Waiting for your phone to do something isn't like being in a coma, where the time is irretrievably lost and provided no benefit (beyond what it might have allowed recovery wise), nor is it like sleep, where we spend a significant portion of our lives doing it and we can't do anything else during that period (even if that period itself is beneficial).
Delays are annoying. Making delays shorter is good. Saying shortening delays saves lives worth of time is problematic. Even the original commenter acknowledged that was probably reaching (it wasn't his quote).
This is a problem. Some user not even know what a fast app look like, neither have the hardware (hello old PC, hello cheap Android) or blame themselves for any problem or just assume "is supposed to be like this".
Take for example the Android emulator (and in this case, using developers). In the moment I launch it, the FIRST TIME, i instantly look for a alternative (was impossible slow). However, how many developers stick to it, and have even less powerful machines than mine?
Or using something else: How many people think that miss keys in the keyboard is his fault and not a problem with cheap rubber domes? And how many know exist mechanical or have used a old quality keyboard?
Ignorance of the users is NOT their problem. Is OURS.
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.
They're already paying a 30% cut of all app sales.
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...
It sounded like they always expected to do native apps, just not nearly as fast.
As I watch HN I see people talk about things that are 'missing' in Safari and they should be able to do from JS and many of them horrify me. I don't want random sites to know the light level of the room I'm in. I don't want them recording audio. Log running background tasks? Didn't we learn from TSRs? I don't trust random devs with that.
My point being, this isn't new. Since interactive applications first happened in the browser, this has been the objective whether we like using these things or not.
- 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.
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?
>A resource-hungry 3D game or similar does not fit into my definition of “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.
the time it takes to create workarounds for UIWebView/WKWebView is only
slightly less than the time to get familiar with Swift/UIKit
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.
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.
eBay's app, for example, adds little for most users.
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cacheA 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.
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.
- 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
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.
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.
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.
> 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.
http://www.androidauthority.com/apple-iphone-average-selling...
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.
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.
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.
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.
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.
If you don't need native functionality, or video capability, then mobile web is going to be a 1000x better choice.
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-...
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.
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.
https://sensortower.com/ios/rankings/top/iphone/us/all-categ...
> 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.
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! ;) )
This goes against Apple's terms and conditions. Because of this alone, you can have your app removed at anytime.
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.
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.
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.
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.
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.
Flash the development environment was pretty great, and nothing comes close to it today. The closest I can think of in terms of ease of picking it up for artists/designers/etc is Unity, but it really is built for 3D first.
I'm sure it could be made to work great, but it never did.
These are probability the same developers that were writing sloppy Flash banners a decade earlier.
Compare that to being at the mercy of a company like Adobe that bundles at least 3 different JavaScript interpreters, a full blown WebKit and who knows what else to Photoshop. All while having a custom made cross platform UI layer across all of their apps.
Nowadays of course we have CPU core swallowing and battery draining JavaScript ads, along with massive JavaScript bloat in general. For the heck of it I just went and had a look at one of my own pages, which runs an HTML5/JS/CSS game, and includes Adsense. It downloaded 633KB of JavaScript. By today's woeful standards that's not even particularly bad. To break it down a bit though, 52KB of it is scripts I use directly, of which 47KB is required for the game. The other ~5KB is FontAwesome, which I use for icons on the menu buttons. The other 581K? Well, Adsense itself is also fairly small (about 35K for two scripts), which leaves the rest - the vast majority - which is loaded by the ads themselves.
Like you, I've come to realise that it wasn't the tool/platform, but the people building for it. Clearly the best developers are not building ads. It feels like there should be some scope for disruption here.
At the time, it was such a great idea (in theory)
Android was hit or miss depending upon the specs of the device.
Remember how in the early days it was a "big deal" that android phones supported flash but iOS didn't? Tech people used to think that was important, and it netted android some sales, but in the end everyone had to admit that it was kind of a bad idea.
However, as a platform the player was lean and optimized. A lot of people wrote horribly inefficient things with it, which gave it a reputation for being power hungry and slow.
There were additional performance issues on Mac desktops where certain APIs for video playback were blocked.
Today things are different since most site use html5 instead but back then iPhones were seriously crippled on the web.
Shortly after, most of those sites released normal mobile versions anyway.
That said, I'll never miss Flash. The web became a much better place the day it died. Maybe it could have worked better on mobile devices? I have no idea, but I'm definitely not sad that Apple said no (because that kept it out from my Android phone too)
Granted, mobile devices were never a target for Flash games, so the biggest problem was that all the sudden our clients needed content to run on a new lower power device in addition to desktop browsers. Previously our biggest problem was clients that needed things to run in old versions of IE (IE6 anyone?!). Our last couple of Flash games that we built 5+ years ago are still far more impressive (on desktops) than any HTML5 game we've since developed (and we've developed A LOT of them!). GPU access was made available for the Flash player shortly before it died. A lot can be done now with WebGL, but wide device/OS/browser support is still a problem.
We've since branched a lot more into native app development where we can continue pushing the envelope visually. Our JS games continue to feel like they have handcuffs on them and still can't compete with Flash 5-7 years ago.
A few really big indie hits were however written in flash and related languages.
Why would Apple want that?
I think it could have been a contender for winning the 'cross-platform-mobile-dev-tool" war; but Adobe abandoned it along for the most part.
This is complete nonsense.
Adobe screwed over Flash and the number of major vulnerabilities discovered in the decade since iOS 1.0 has proven this to be absolutely the right decision. Apple has the responsibility and the right to put their user's security above and beyond the needs of a minority of developers.
Also your point about AS3 versus Objective-C is hilariously stupid. Anyone experienced in a platform is going to find development quicker than someone who isn't. I would be 10000x faster building an app with Objective-C because guess what I don't even know AS3.
Programmer productivity is measurable.
But my point still remains that people are more productive in the technology they know the best.
EDIT: 33 years ago, not 1970s.
The problem rather is in the Apple users that accepted this behaviour from "their" company.
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.
> 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.
I just came here to say the same thing.
I guess it's still useful in 'enterprise' scenarios though, where you are distributing apps to a restricted set of users by some other means, such as through Microsoft's Intune. I don't know why Ionic Deploy and CodePush don't make this plain though.
Edit: I just checked the CodePush FAQ, and they seem to be interpreting the Apple developer agreement such that updates outside of the app store are allowed as long as they don't radically change the app [1].
Personally, I'd be really wary of going down this path, worried that Apple or Google would pull the rug out from under it. Anyone here had any apps rejected or pulled for using CodePush, Ionic Deploy or something similar?
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
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.
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.
Wow. People like this are why people hate JS devs.
Lest anyone forget, the iPhone's original "SDK" was web apps. People cried out for a native SDK.
You can even do push notifications on webapps. https://developers.google.com/web/fundamentals/engage-and-re...
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.
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.
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.
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.
...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.