The answer would vary GREATLY depending on what the business is, but in a generic sense of just plain marketing a business? NONE OF THE ABOVE!!!

What you want is a normal everyday website; it has the widest reach, widest usability, and widest range of accessibility. Native applications are typically platform specific and are a pain to get working cross platform, requiring a download. Web apps remove a lot of the cross platform woes but still require the download. Hybrid is cute, but like web apps are nothing more than flipping the bird at accessibility since they are inherently JavaScript reliant...

... and if it REQUIRES JavaScript to function client-side, you've built a walking talking WCAG violation and told users with accessibility needs to go **** themselves.

Which is why if we were talking normal everyday business marketing, I would suggest a normal everyday website. Unless you are doing something VERY specific that REQUIRES realtime updates in a push fashion -- something that just pisses off most users -- there is no reason to be screwing around with much more than that.

But again, what's the business? What particularly are you wanting to do in terms of "marketing" that a normal website cannot? Your question simply begs more questions.

When writing an app, which should run on many different platforms, mobile included, I try to fit it into a WebApp first. I can simply add a manifest file to the app, so it can have an icon on the user's home screen, which opens a separate browser in fullscreen (looks just like a native app). A browser gives me access to most-needed APIs, so I can do most things easily.

Only if I encounter a feature which is not useable from a browser, I try to rethink my strategy, usually setting up a hybrid app, which displays the WebApp, but also makes the needed API available. The browser version is missing that feature, then, however can still reuse most of the code and most of the time is 90% operable (maybe a bit more inconvenient to use, depending on the app).

I only go for native apps if a core-feature does not work in a browser (for example if you need file-access) or if the app needs a lot of performance, which is not available in the browser (for example 3D or maths, though those two use-cases are already being remedied by WebGL and WASM).

Imho, native apps are slowly dying out. We have so much technology (WebApp Manifest, Service Workers, WASM, WebUSB, WebRTC, MediaDevices, etc.), which allows for WebApps to work, to be stored and to be used just like a native app, with the power to run WebApps performant enough in most situations, that it just does not make a lot of sense to port an app to different platforms, when you can have them all platform independently with a unified code-base as a WebApp.

I'm not an expert but I think it depends on what are your needs. If you need the app to be done quickly without including any complex task (such as accelerometer/gps/3D graphic features) hybrid might be the way, because with some frameworks you can build three apps for the most famous OSs by writing the code just once . On the other hand native apps have more performance and allow you to include powerful and specific features. It's up to you to choose the right way to build your app/system. Talking about Web Apps I think they're necessary only if your users connect to your service throughout PCs; Web Apps via smartphone usually are slower and sometimes more annoying than normal apps.

I repeat: I'm not an expert, I'm talking through my personal opinion and experience. I'll be glad if someone would like to correct me.