Do you all have any thoughts and insights on this dichotomy? On the one hand native programming temporarily allows content creators to further control their content from pirates to some extent. However, I wonder about the effects with content on the web? Can they coexist? I see catering to a specific device has many benefits. However, programing to the web also has many benefits such as immediate and wide distribution. I've always heard the terms mobile first web second. However, with mobile platforms your are limited in that you have to program for each platform rather than giving everyone everything all at once. Any thoughts now that we are several years into mobile apps etc...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Native vs Web Programming
- Thread starter AdonisSMU
- Start date
- Sort by reaction score
Part of the answer depends on what you want the app/page to do.
Apple has been known to crack down on apps that should be web pages. Apple has 1.25 million apps and it's hard to get noticed. Although, web pages can get lost just as well.
The performance of native apps is far above web pages or "web apps".
Control seems to be strongly towards native apps.
Developing an app can be as simple as re-skinning template code or can take in-depth knowledge of the language/APIs which can be costly and take a long time.
So it really depends on what you want the app/page to do.
Apple has been known to crack down on apps that should be web pages. Apple has 1.25 million apps and it's hard to get noticed. Although, web pages can get lost just as well.
The performance of native apps is far above web pages or "web apps".
Control seems to be strongly towards native apps.
Developing an app can be as simple as re-skinning template code or can take in-depth knowledge of the language/APIs which can be costly and take a long time.
So it really depends on what you want the app/page to do.
What do you mean crack down on apps that should be web pages? You mean like the NYT or pretty much any news source?
The experience with apps is far superior to webpages. Most users really don't care that much if it's a web page or an app. Developers like myself care about the open web. The problem with the open web means their work can be devalued somewhat from the developer side and the content side of things. Additionally, the open web makes sharing things easier. A good developer should want to provide a user with superior UX. With the web you have proprietary stuff as it is now with the different levels of support for the web standards etc.
I'm starting to think the open web has as many problems as benefits...and native apps aren't as bad as I had originally thought. The biggest downside is search/shareability. However, the HUGE benefit of that is maybe performance & privacy as you would be specifically giving access rather than companies like google taking access to your personal information if you don't want them to have access to it. You could argue Apple does the same thing with iAd minus the whole search for someone
I'm not sure I agree with the whole if it's on the web we should be allowed to take it for free mantra that has dominated the tech discourse as of late.
The experience with apps is far superior to webpages. Most users really don't care that much if it's a web page or an app. Developers like myself care about the open web. The problem with the open web means their work can be devalued somewhat from the developer side and the content side of things. Additionally, the open web makes sharing things easier. A good developer should want to provide a user with superior UX. With the web you have proprietary stuff as it is now with the different levels of support for the web standards etc.
I'm starting to think the open web has as many problems as benefits...and native apps aren't as bad as I had originally thought. The biggest downside is search/shareability. However, the HUGE benefit of that is maybe performance & privacy as you would be specifically giving access rather than companies like google taking access to your personal information if you don't want them to have access to it. You could argue Apple does the same thing with iAd minus the whole search for someone
I'm not sure I agree with the whole if it's on the web we should be allowed to take it for free mantra that has dominated the tech discourse as of late.
Last edited:
Apple's has rejected apps that they feel are just web pages done up as an app. They are trying to stop people from submitting apps that do the same as a web page.
Example: I met a local dev that was making apps for local businesses where the app was the same as their web page. They were being rejected, so he added the ability to get alerts and a few other things.
I don't know much about developing web pages or even what "open" web means, so I can't say if a web pages targeted to mobile is just as good as a mobile app or not, but many have said that native apps are much better for mobile and always will be. They site control and response as two issues where native beats web based.
If it's just a content reader, like NYT, I'd do some homework before you dig too deep. I've heard only the large companies have been given exceptions
from Apple to sell subscription without Apple getting a cut.
I think some went the way of a magazine on Apple's bookshelf.
What if you dont want a webpage? I mean people have done worse than putting content into an app.
Your app should benefit from being an app. List what the benefits of having your app be an app rather than a webpage are. If you can't think of any, then you should be making a webpage, not an app.
It's not about the source of the data. It's about the UI and UX. Does the app feel and behave like it has native iOS controls familiar to an iPhone/iPad app user (proper button sizes, multi-touch gesture handling, update notifications, iOS font sizing, voiceover accessibility, and etc.)? The NYT app does some of that. Same data or news source, different experience interacting with the data.
Or is it more like just a web page or Chrome app? If so, just send the user to your web site with Safari. No need to fill up the App store with such.
Facebook's roomful of engineers tried to present a smooth, optimal experience with an HTML5 app, and failed. So they went native. Are your developers better than Facebook's?
Last edited:
You don't have to be better than FB engineers. It all depends on your goals.
Web pages give you more control over distribution as Apple isn't in your way.
Not every app is a beautiful example of delirious UI and UX.
A lot of enterprise apps will be web apps. If your manager says, we paid a million dollars for this system and you WILL use it, then you use it.
Web pages give you more control over distribution as Apple isn't in your way.
Not every app is a beautiful example of delirious UI and UX.
A lot of enterprise apps will be web apps. If your manager says, we paid a million dollars for this system and you WILL use it, then you use it.
I can think of a zillion apps that make sense as web pages and not necessarily as apps. Additionally, facebook works just fine as a webpage so does nyt. They dont a tually NEED to be apps. Performance is a very good reason to have a preference for building an app over a traditional web page. Fb app is very much a replication of what is already in your browser....same with NYT. The bottom line is it seems like Apple is creating barriers to entry that might not be entirely justified which they relax if you are a big enough company.
Why do you think, then, that Facebook went through the effort of migrating from a very much web-based app to one that is native?
That's not what their own customer analytics data says. Given a choice, users mostly prefer the apps. Stay longer. Buy more stuff. With apps. The web platform is getting obsoleted by better faster smooth UI/UX.
Don't need to be apps? Sure, you can browse news on an old teletype or minitel. Not what people want to do anymore.
Ummmm lol! FB's website never stopped working just fine on mobile safari and desktops. The javascript engine that was used for in app web code was slow. FB ported it over to app code. However, that was not the case for using fb right in mobile safari on ipads and phones since safari had the latest benefits from javascript speed improvements.
Im of the opinion native front ends are way better in every case. I cant think of a case where the web makes more sense than the app. Other than search the web doesnt have a significant advantage over an app. I was just pointing out that people realize that apps tailor made for devices is a superior ux when compared with one size fits all....it doesnt even with the web. The web is a great second option imo but only as a fallback and you still have the issues of different browsers doing different things even on the same OS. So id say fragmentation is a significant propblem.
----------
Careful, I used to work for NYT... People like the app but searchability is an issue with apps. As stated twice before, I think ux wins over everything else and for that apps cant be beat by the web. Plus its less resource intensive than a web stack which means cheaper maintenance.
More and more Google and Bing search results seem to be leading to pages which say "Would you like to open this content in our XYZ app?". They wouldn't be doing that unless they were benefiting from a better user experience, better "stickiness", more analytics, lower server costs, and etc., from their app vs. their web site.
So the reason you have a website is to lead people to the app. Apps are stickier.
This may or may not be true, but you should also consider one thing:
The average mobile device has about 100 apps (older stats, might be different now). What's the odds of your app being 1 of those 100 apps?
If you're not 1 of those 100 apps, you get ZERO usage. If you're "on the web" you have a connection to the device/user.
This isn't to say that a great many people "browse" the web on their device more than they use specific apps, because I doubt that's the case.
Point: you really need to make the decision based on what the service/app would be and what you think the customer would want.
You just made the case for both. The problem with the web is copyright issues. If you keep content in the app it's harder to steal but not impossible. I just think the apps are easier on the server and provide a superior UX to the web. Plus the web doesn't deliver on it's promise because it can't deliver on its promise.
Not really.
Why do you think that? Generating JSON or XML for API access to web resources from an app is likely to require just as much server side processing as required to spit out dynamic content for a browser.
I made the case for both, because there IS a case for both...
Notice the part at the end?
If you can do either, then it should be an issue of what the customer would want. If it's just content, you might look into the bookshelf (magazine).
Can you extend it beyond just content delivery?
What would your customers want?
Point: Look at these as tools and decide which tool is best for the job. Focus on what the customer would want, not how to protect the product or content.
If the business model is simply to charge (direct or indirect) for content that could be had otherwise, it's a tough model for the Internet. Example, someone can charge for news, but unless they have an exclusive on that and the demand is high, they won't be able to directly charge for that and they'll have to be based on advertising.
It's hard to control content, look at movies and songs. They've been trying to control that for many years and haven't had a lot of luck. In the example of music content, free personalized streaming is very popular (they are giving the customers what they want).
I am struggling with native vs web app programming.
I don't know how to build a native app from scratch if there is no actually website to base it off. Sorry if I'm derailing I'm trying to build my first social network and most of the flagship features require native/hardware features.
I can't seem to find tutorials on it.
I don't know how to build a native app from scratch if there is no actually website to base it off. Sorry if I'm derailing I'm trying to build my first social network and most of the flagship features require native/hardware features.
I can't seem to find tutorials on it.
Building a social network has come up several times here, the bottom line is that it's a very involved process.
That aside, learning how to program is sometimes a matter of learning the tools (Xcode, iOS, ObjC, APIs,...) then figuring out how to put things together to make the program do what you want.
You might not find a tutorial on social networks, but you should find enough to learn how to do various parts of it, then figure out how to make it from there.
Example: You might learn how to draw a line, circle, square, etc... it's up to you to figure out how to fit the part together to get the desired output.
Learn by building a non-networked native app first. There are tons of tutorials on building simple flashlights, soundboards, tapping bird apps, and etc. Learn how to build some of those, then add a table view and a REST networking thread to some BAAS provider.
In case you couldn't tell, I was agreeing with you. LOL! Your post reads like I was in disagreement when it was quite the contrary. At the time of my post I thought you made some great observations. I haven't come to that conclusion yet. I was questioning. Your post didn't really address any of my gripes.
I wanted to point out that even the web doesn't live up to it's cross platform promise and now you couple that with the added hassle of lousy performance, high cost and lack of security. I was question why release to the web first given this these things. I actually think it should go... apps first web second. One web shouldn't fit all.
----------
and what about the front end aspects... you know like downloading the CSS, HTML, and Javascript for a website over and over and over and caching issues?
Last edited:
Ok, looks like I did mis read that
IMO, the web has a place, but it's a tough spot. "web apps" are supposed to at least answer the question "how to you run cross platform" They do this, but IMO, not too much else.
It's nice to be able to remotely update content/behavior and not wait for approval, but it comes at a price.
Native has many advantages, but lacks in ability to change the behavior and you still have to wait for approval.
IMO, we'll see numerous solutions to this over time, but I don't see either path addressing one very important issue:
Getting stage time. Every app/web page wants you. There are over a million apps and many millions of pages... every one wants you (nice to be so wanted
)Few, very few, will ever get their dream of getting stage time or fame.
It's like the worlds biggest amateur stage with everyone looking for their big break and everyone thinking they have "the right stuff".
Downloading static resources has next to no impact on server side resource usage (except for transfer allowance). Of course this assumes you have configured the server correctly to use a decent static resource HTTP server such as Nginx which is lightning fast for such operations. You could even use a CDN which would speed it up even more.
Caching can be used both for browser clients and with API clients and so it doesn't make much difference one way or another. Remember you are just caching the result of a server side operation in RAM so that the server doesn't have to do the same operation over and over again. It doesn't matter if the result that you are caching is a bunch of HTML or JSON / XML.