Comment by interpol_p
9 years ago
But as an iOS user I expect you to use the technology stack provided by my preferred operating system. I don't want to use your app if you're targeting a lowest-common-denominator feature set.
When I change my preferred text size through accessibility settings, good native apps respond correctly. If I need voice over support, the operating system knows how to read the view hierarchy to me in a logical way.
When drag-and-drop becomes a thing in iOS 11, native apps will implement that feature well. I think it will take some time for web apps to implement it as nicely (if ever).
There are thousands of tiny details that your web app just won't have. Those details are more important than your familiarity with a tech stack or how long it takes you to deploy something.
You say that:
> By fragmenting development effort, the overall product isn't as good on any platform.
But I would say that:
> By building a web app, the overall product isn't as good on any platform.
I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
>But as an iOS user I expect you to use the technology stack provided by my preferred operating system. I don't want to use your app if you're targeting a lowest-common-denominator feature set.
I would wager that the average quality of an iOS app written by someone like OP that "has a web experience and _has_ to learn iOS just to work on that platform" will probably be lower than if that person (with web experience) could just extend their web app natively with PWA.
I completely agree with you that the app should feel native to the platform (I actually quit a job a while back because they wanted me to theme our web Android experience as iOS for "consistency across all devices" instead of matching the user's device's design patterns), but there is huge value in giving the devs the tools they need to write the best product they can, and splitting codebases and requiring more work/knowledge/moving parts is actively detrimental to a quality end-product for everyone, unfortunately.
> iOS app written by someone like OP
That's a business choice that they made, and will suffer for. If a developer and business choose to half-ass the native iOS application, there's no reason to believe it would behave any better on iOS when written as a webapp.
> the tools they need to write the best product they can
The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs. There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
"The best product that can be made will never be made with cross-platform tooling."
You're making a circular argument to the original point. If you pointlessly cripple the best "cross-platform toolset" (the web) then of course the products made with it won't be as good.
Native mobile apps belong in the same category as desktop apps - they are good when you need close-to-the-metal graphics but there's no reason you should have to open up a desktop app to read the news or even do some light word processing.
5 replies →
>The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs.
This is hard to argue for/against, because having one (native or cross-platform) generally precludes you from simultaneously having both (necessary for a proper comparison).
Of note: I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow. There are also benefits I know exist (as a dev) that I don't see (as a user) like shared code that shouldn't be discounted just because the end-user can't see them -- they indirectly result in a better product for the end-user by making it easier to add new features and maintain existing code.
Also: I've never had any issues with Minecraft's cross-platform java client either. Would it be any better as separate native apps targeted at each platform?
3 replies →
The general problem is that there are some APIs which work differently enough between platforms that they leak sufficiently that it makes a difference above the stuff they're supposed to abstract. The browser is [sadly] as close as we've been in recent history to having APIs which mostly work across platforms by leveraging the browser (which is consequently made by the OS developers on mobile OSes) for abstraction over OS stuff. Combined with how "everything is in the cloud" and the decline of the importance of stuff like local file management for average users (now you can lose all your stuff in GDrive just as easily), it's becoming a good-enough choice for making software that works on whatever thing people try to run it on.
Java on a phone is nothing new, but the Java for Symbian you'd write probably wouldn't work very well on a desktop. VC++ for Windows Mobile apps wouldn't work well on a desktop either. The web is the lowest common target, even though it's quite a high level to target. We still run into plenty of HCI issues (why is there a big fat + button in the lower-right on my laptop in GDocs instead of "New" or File -> New action? Because Material is mobile-first and applied thoughtlessly to non-touch experiences), but if you play your cards right, it's now possible to have a codebase, and truly the same app, running on whatever OS and architecture the user has, without specifically building and packaging for 30 different target combinations.
There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
I feel the same way about Jupyter. Sure it's very clever to run it in a browser but it is clunky as hell compared to native RStudio (free) or MathCAD (commercial).
> The best product that can be made will never be made with cross-platform tooling.
Never is a pretty strong word. Have you tried some of the apps on the site pwa.rocks? Flipboard and AliExpress are non-trivial examples of PWAs that do a good job. Who knows what app development will be like in 5-10 years?
As a developer I would much prefer a cross-platform way to write apps.
Have you looked into the web components spec yet? I think a combination of PWAs + Polymer (or React with web components) has a pretty good shot at easing cross platform development. It already has the support of most browser vendors and is relatively easy to pick up.
> My proof for this? Java programs. TCL programs. Electron programs.
Do you feel the same way with QT?
There's a reason all of those you cited failed. That reason is not "a cross platform environment can not be good".
5 replies →
The best I've worked with has been platform independent business logic in C++, with a thin platform-dependent UI layer. This works across mobile and desktop. C++ has the benefit of being callable on all major mobile and desktop platforms.
That way, the bulk of your team maintains the business logic, and you can get away with much smaller teams for the platform-specific bits.
> The best product that can be made will never be made with cross-platform tooling
True or not, this is only relevant if it's indubitable that every app has to be 'the best product that can be made' in terms of platform-centric gold-plated polish. But it's not. Values often clash and tradeoffs are made. For some apps I would prioritise cross-platform availability far above platform polish. For others the converse is true. Some products don't merit the effort or expense of being 'the best product that can be made'. Others do.
>I don't want to use your app if you're targeting a lowest-common-denominator feature set.
You might even use a hybrid app without it knowing. Many apps just need to show some buttons, input fields, images or a map and hit a web service. Brushing ALL hybrid apps off as useless is in my eyes just ignorant.
It's possible. I still use web apps (e.g., Slack client on macOS). But I dislike them compared to good native apps, mostly due to their lack of consistency with the platform and general sluggishness.
If I'm using a web app and not realising it, then I would happily keep using that app. I do not think I am, though.
Also, there are plenty of native apps which are terrible and not consistent with the platform. I do not like to use those either.
I get your point and do have a strong preference towards native apps too.
But there are other important factors to consider. I was working on a B2B app where users could see graphs and maps of a construction site in real time. The users were extremely happy how fast we could implement and release change requests and bug fixes. It was an ionic app. As far as I know, performance or lack of OS integration was never a problem. At the end of the day it's about choosing the right tool for the task.
6 replies →
This hits the nail right on he head. I can see developers wanting to have one codebase, but as a user I want apps that can take advantage of everything iOS offers. There is no Picture-in-picture or metal in PWA.
> I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
I wonder how much of that is an intrinsic problem with web apps conceptually, or a result of the various limitations and design fuck-ups of the browser vendors.
The fuck-ups aren't just on the browser vendor site.
The entire front-end ecosystem is currently worse than enterprise Java at its peak and the quality issues stem from all sides.
The best web app I use daily is Slack (wrapped in its native app "shell" on macOS). But it still feels pretty poor.
On iPad it's worse. On iPhone strangely, it's not too bad.
If slack is the best, it really goes to show why nobody should be making non-native apps. Slacks Mac client (and their iOS client) is really, really bad.
> There are thousands of tiny details that your web app just won't have. Those details are more important than your familiarity with a tech stack or how long it takes you to deploy something.
How many details does an app that doesn't get written have compared to a website?
> I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
There are a lot of websites I like using. There are very few apps I like using so much I want to install.
You can't get pixel-perfect (including android) between all devices, but to the extent that a manufacturer enables a "better" experience, it gets much closer and more consistent behaviour compared to native apps:
https://webkit.org/blog/3709/using-the-system-font-in-web-co...
...and even if you get pixel-perfect between android and ios, you sacrifice "cultural-correctness" (ie: floating buttons v. top bar v. bottom bar, etc.).
Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself.
Making a PWA which gets 90% of the way there, and integrates as well as possible with the system (ie: fonts, location, notifications, accelerometer, etc.) is generally _less_ expensive than doing a single native app well, and has the chance to get you 90% of the way there on desktop and your "alternate" mobile platform.
PWA can be incredibly powerful (along w/ manifest.json-style support as android has), and I'm waiting for the day apple catches up to android on this one.
"and even if you get pixel-perfect between android and ios"
Nobody but designers who think too highly of themselves wants this. Everyone else wants the app to fit in with the platforms toolkit. This requires the designs to be different.
"Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself."
Which is why I don't do it the way you described. I embrace what makes each platform unique.
I think PWAs are fine. I just wouldn't encourage them to be used side-by-side with native apps (e.g., deploying them to the home screen). It creates the expectation that they should culturally fit in with native apps, and they won't.
I'm okay with them living in the browser and gaining the performance advantages, offline support and push notifications.
Theres something about this comment that winds me up but I don't have the time to unravel.
> When I change my preferred text size through accessibility settings, good native apps respond correctly. If I need voice over support, the operating system knows how to read the view hierarchy to me in a logical way.
> When drag-and-drop becomes a thing in iOS 11, native apps will implement that feature well. I think it will take some time for web apps to implement it as nicely (if ever).
All these things the browser should be able to do well, if they wanted.
Given that web apps still fail to do drag-and-drop (and copy and paste) as nicely as native apps — and these things have been a staple of Mac interaction since forever — I do not hold out much hope.
Well yeah, it's "if they wanted". Apple has the same incentive to not turn Safari into a viable app platform that Microsoft had with IE in the 90's.
1 reply →
But they don’t.
> But as an iOS user I expect you to use the technology stack provided by my preferred operating system.
As an iOS user I don't expect Apple to mandate your preferences for me
> There are thousands of tiny details that your web app just won't have. Those details are more important than your familiarity with a tech stack or how long it takes you to deploy something.
They are more important to you. They may not be to me if they prevent an app I need being made, or being available cross-platform (much more important to me than it being perfect on any one), or being affordable (to me).
The notion that every app must be the perfect gold-plated 'delightful' experience is corporate marketing drivel. It is relevant to some (people and apps), but not others. We don't need the personal tastes of some precious souls to be mandated for all of us by the platforms we happen to use (today).
I disagree that it's marketing drivel. Wanting everything to be consistent is the entire reason I was driven to the Mac as a platform in the first place many years ago.
Being on a platform where users and developers care about exactly what shade of grey their menu bar icon was, or matching the platform characteristics, adopting system-wide services, making apps accessible, is very important to me.
You may not care, but that's how I choose a platform. It's not marketing, it's personal preference.
I'm going to push for iOS and macOS to develop in this direction by supporting developers who try their very best to make thoughtful and consistent software.
Your argument works against yourself: "cheap cross-platform apps are relevant to some, but we don't need the personal tastes of some precious souls to be mandated for all of us." (I'm not making this argument against you, but try to see how cross-platform is your own personal preference that you are trying to push onto others. In my opinion it degrades a platform even if you don't use any cross-platform apps.)
Could not agree more. How does a PWA use ARKit? How does a PWA integrate with the camera? How about the accelerometer? What about iCloud, Handoff, or any number of iOS technologies? Perhaps Metal or other iOS graphics technology? What about TouchId? Bluetooth?
I also find the comment about needing to learn a new stack “React Native and Xcode” to be ridiculous– no, what needs to be learned is Swift and Xcode.
Far too many “web” developers consider native mobile to be some kind of subset of web development and thus expect to use the same tools as they use for web.
Web is a different medium! If you want to program embedded systems, then the first question isn’t “how can I do this with JavaScript?” They would learn the correct language for the platform, perhaps embedded C. You don’t launch a Linux server and then ask “how can I make this server run Windows? I guess I should write a JavaScript library for that!” It’s ludicrous.
With iOS, developers often just think of it as a “native” website rather than an actual application. It seems like some developers will do everything possible to avoid simply learning Swift and making actual apps that fully exploit the power of the device.
React Native – if that is considered “good” then we have major problems. Facebook applications are horrible at power management; they suck power at phenomenal rates compared to other applications. The smoothness of the UI isn’t as “native” as actual Swift apps coded correctly. There always seem to be a slight amount of glitch in the experience. Facebook has famously avoid actually coding real native apps – from the beginning of their mobile experience they have seemingly embraced doing everything except writing actual Swift or Objective C. It is almost a religious opposition to it – and despite being a multi-billion dollar company, some tiny app studio in Poland could write higher quality apps. It should be an embarrassment, but they’re Facebook so everyone just accepts the status quo of less than perfect. No person here can say that the Facebook apps are perfect. But they should be. They have a gazillion dollars and can hire almost anyone they want, so they have no excuse for anything less than perfection. At the very least get power management right!
There’s always this argument that x-Native is “good enough” – if, as a company you want “good enough,” then keep making apps that conform to the lowest common denominator. If you want to make extraordinary applications that move the needle of quality, then use Swift and build it correctly.
This will likely get downvoted into oblivion because the HN crowd seems to be exhaustingly enamored with React Native, however, regardless of how it’s framed, writing PWAs or using some cross-platform “solution” is a cop-out. It’s lazy and it provides users with an experience that is worse than they deserve.
iOS is better than Android in so many ways, yet developers insist on making iOS apps that are really just cross-platform compromises.
My tiny bootstrapped company is working to release our iOS app, with Android soon to follow – if we can do it, there seems little excuse for actual funded companies to skimp on providing the best experience for users. Those arguing that PWA or x-Native cross platform systems are just as good as actual native, well there is no amount of argument that will change your minds. Which is sad. Rather than trying to make React Native, etc. “better” why not just use what is already better? Why not let users enjoy the full power of their devices instead of writing these average “good enough” compromises. It’s like this ridiculous trend of using Electron or, in the past Adobe Air. Nowhere near the quality of writing an actual native app. Looking at you Slack. Slack is even proud to have made a “native app with web technologies.” WHY? Damnit make a native app with native technologies! Can you not hire two actual MacOS developers? Why should making Electron apps be celebrated? It’s sloppy. It’s lazy. It’s a disservice to users. Why use some Electron-wrapped webpage and just not the webpage?
Every day it seems on HN people are posting about <some language> but very few posts about Swift. Is there some opposition that I am missing? Why must JavaScript be the language of everything? what ever happened to picking the right language for the job rather than trying to force a web peg into a native hole.
By the way, my exact arguments could be made for Android development as well. Android users are also being short-changed by these pseudo-native cross platform “solutions.”
Yep. There are also, as I'm sure you're aware but for the benefit of the less-familiar, plenty of "hybrid" ways to build "native" apps for mobile: https://github.com/auth0/blog/blob/master/_posts/2017-01-11-...