
If It Weren’t for Apple, Hybrid App Development Would Be the Winner Over Native - mmastrac
https://hackernoon.com/if-it-werent-for-apple-hybrid-app-development-would-be-the-clear-winner-over-native-ae64fa37ad48
======
k-mcgrady
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.

~~~
robert_foss
> I've done some React Native development and Xcode is almost entirely
> avoided.

Almost entirely avoided still means you have to go out and buy a Mac and keep
Xcode running on it.

~~~
sams99
sort of, I run a VM on Windows using VMWare workstation, involves binary
patching the vmware executable, but hey, cheaper than buying a mac.

~~~
mixedCase
Also illegal, so not a solution for non-hobbyists.

~~~
Teever
I don't think it's illegal in my country. Or most of the world really.

~~~
cmurf
Technically it's not illegal as in criminal, but it is a violation of the
contract you're agreeing to in the form of the software license. And the macOS
software license only permits running macOS on Apple hardware (it can run in a
VM, but the VM host must be Apple hardware).

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.

~~~
ElijahLynn
Another reason Apple is BS. "macOS software license only permits running macOS
on Apple hardware", I disagree with Apple so hard here. What a scam.

~~~
cmurf
They've always been this way. There was a short period of time with Mac
clones, but there was still a license that said you could only run macOS on
Apple hardware, or Apple licencee hardware.

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.

------
valuearb
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.

~~~
kbenson
> I just finished implementing an iOS app that uses a background operations
> queue for network operations.

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.

~~~
matwood
Native iOS/MacOS provide a rich set of libraries around multi-
threaded/background processing. Look up Grand Central Dispatch (GCD).

[https://en.wikipedia.org/wiki/Grand_Central_Dispatch](https://en.wikipedia.org/wiki/Grand_Central_Dispatch)

------
tambourine_man
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.

~~~
jasonkostempski
But the end user experience is still shit on iOS, it's just a more specialized
kind of shit, delivered through a fancy sphincter.

~~~
coldtea
Shit compared to what?

People really have no context...

~~~
zepto
A naïve utopia that we are being held back from by corporate greed.

------
wolfgke
"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.

~~~
mikeash
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
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.

~~~
JustSomeNobody
Wait, so when you tap the browser icon on your phone, you set it down and go
have a cup of coffee first? No, you don't.

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.

~~~
kbenson
The example wasn't perfect, but often I'm using my phone when moving between
place to place. I don't stop walking to to wait for an app to load. You also
don't need to stop thinking just because you are waiting for something.

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).

------
valuearb
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
It is the free generation, they want to get paid but not pay for their tools.

------
sidlls
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
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
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
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.

------
bschwindHN
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.

------
coldtea
> _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?

------
scarface74
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
The thing is: There is no fast browser that also is flexible, in contrast to
android.

~~~
scarface74
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.

------
tambourine_man

      >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?

------
rstarback
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

      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
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.

------
tyingq
There's a fair number of "apps" that could be replaced by a plain old web site
as well.

~~~
mcphage
Except for that pesky requiring an internet connection...

~~~
tambourine_man
Local storage has been a thing for a really long time

~~~
mcphage
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
Nor can you download the App. The first interaction must be online on both
cases.

~~~
mcphage
Sure, but once you've downloaded the app, you're good. You can open it up
whenever.

~~~
tambourine_man
Same with local storage, that's the point:

    
    
      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_cache

~~~
mcphage
Apparently I'm missing something. How do you go to the website to even load
the code that talks to the local storage? (Also that last link says it's been
deprecated and is being removed).

------
Tloewald
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
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
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.

------
barnabee
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
Thank you for the feedback.

~~~
barnabee
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.

------
jorgemf
> Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5
> [https://techcrunch.com/2012/09/11/mark-zuckerberg-our-
> bigges...](https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-
> mistake-with-mobile-was-betting-too-much-on-html5/)

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.

------
cletus
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
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.

------
digitaltrees
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.

------
scarface74
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...](http://www.androidauthority.com/apple-iphone-average-selling-
price-749145/)

~~~
samdelgado
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.

------
dep_b
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.

------
bartread
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
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.

~~~
bartread
I wonder if there's a way to do that for web apps? Both Safari and Chrome have
pretty good support for remote debugging devices but I've not noticed anything
like this for tracking energy usage. It would certainly be a super-useful
addition.

------
htormey
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
> 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.

------
AndrewKemendo
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
App downloads and revenue increasing year-on-year (for both iOS and Android)
seems to disprove this

~~~
AndrewKemendo
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-...](https://venturebeat.com/2015/09/25/wait-what-mobile-browser-
traffic-is-2x-bigger-than-app-traffic-and-growing-faster/)

------
itsdrewmiller
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
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.

------
blahbwah777
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.

------
martin_bech
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.

------
kartan
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-
categ...](https://sensortower.com/ios/rankings/top/iphone/us/all-
categories?date=5/24/2017)

~~~
dimillian
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.

------
trey-jones
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
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! ;) )

~~~
trey-jones
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.

------
eecc
Peeps tend to forget that back in the days when "Apps" became a thing,
responsive design wasn't even a term...

------
rezashirazian
_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.

------
Shorel
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.

------
HodGreeley
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.

------
kbutler
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.

------
pmontra
> 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
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

------
ransom1538
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.

~~~
tambourine_man
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.

~~~
robmcm
To play devils advocate, we are in 2017 and JS adverts on normal websites can
slow the latest phones down to a crawling stuttering mess.

These are probability the same developers that were writing sloppy Flash
banners a decade earlier.

~~~
tambourine_man
Sure, but JavaScript is an open standard and you can tune your implementation
at will.

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.

~~~
bartread
True, although sadly you can't also tune JavaScript developers at will.

------
JKCalhoun
By all means, we should bring back Visual BASIC for developing mobile apps.

------
potatolicious
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.

~~~
GordonS
>> "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.

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?

[1] [https://microsoft.github.io/code-
push/faq/index.html](https://microsoft.github.io/code-push/faq/index.html)

------
cxromos
If it weren't for Apple there wouldn't be app development.

------
DiNovi
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!

------
anotheryou
try using some nice animations...

------
ranci
>> 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

~~~
samdelgado
Thanks for the feedback. Is there anything I can do for you? Sounds like you
are having a bad day.

------
jackmott
>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.

~~~
MBCook
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
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
That sounds like fraud if you mean that the ad counts as viewed even when it
isn't.

------
s73ver
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.

------
williamle8300
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.

~~~
enjoiful
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
Get media device, you get camera and mic

------
threeseed
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.

~~~
YooLi
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
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.

------
tritium
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.

