I think a lot of commenters here are missing the point and getting distracted by push notifications (who wants a website spamming them with notifications?) and loading screens (hardly a feature).
Apple supporting PWA (Progressive Web Apps) is hugely important because it enables a future where web apps can natively support browser, Mac/Windows/Linux desktop, and mobile iPhone/Android/Windows native mobile with a single codebase of open technologies.
Why is that important? By fragmenting development effort, the overall product isn't as good on any platform.
There's an app I'm making on the side to keep track of your contacts (like a personal customer management system). This needs to store all your contacts offline, because it'd be too much friction to load everyone you've ever taken notes on over the network every time you open the app.
Right now, the only way for me to accomplish that on iOS is to make a native app. This means I had to learn an entirely new technology stack (React Native and XCode), completely rewrite my views, tie everything into my backend, and go through Apple's Byzantine approval process (which I still haven't done because I can't figure out why my app compiles and runs locally but complains about libraries not being linked when I try to archive it to upload to the app store).
This is unnecessary duplication of work that could've been spent writing new features, makes it harder to add new front-end features in the future (because now they have to be added in two places), and adds a huge lag in the time it takes me to push changes to the iOS client (weeks, vs. the seconds it takes to push a change to the web client).
If apple supported PWA, I would've spent my time making the database keep a local syncing copy on the browser (with minimongo or pouchdb), and then every platform would've benefited from faster page loads and offline syncing.
Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff.
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.
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.
Even if web browsers were on the same page across all platforms and did everything front end dev's dreamed of, web apps are still not going to be as good as native for the fact that they do nothing to leverage what makes any particular platform good, and worse, will be developed around the least capable platform's feature set. In a world where web apps dominate and are the overwhelming majority, why should OS vendors even bother with furthering innovation on the OS level? Nothing would be taking advantage of it. They'd do just as well to boot straight into a generic grey browser environment and call it a day!
As for the web being the de facto solution for light tasks, I'm not sure I agree there either, at least with the web's present resource consumption problems. There's no reason, for instance, for a word processor that barely matches modern WordPad or Word 95 in terms of features to be as heavy as it is (Google Docs).
If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
>web apps are still not going to be as good as native for the fact that they do nothing to leverage what makes any particular platform good, and worse, will be developed around the least capable platform's feature set
We already see this (and solve for this) on desktop and platforms with a lot of variance in capability like Android. Just because people out there run 2.3 Android doesn't mean my 7.1 apps are going to be any less quality, even if they still work on the least-capable platform's featureset.
The obvious solution to this is to exclude or disable features from devices that can't handle them, which is also possible and encouraged on the web (with some decent precision through identification and fingerprinting provided by a myriad of things like service workers). Your banking site probably works in IE8 (barely), but that doesn't mean your up-to-date Chrome/Safari/whatever is going to be a worse experience.
>If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
Web apps are focused on optimizing _different_ resources than native apps, that's all. Google Drive, for example, offers me an experience with no local installation cost in storage, virtually unlimited storage space for files, ancillary services like backups/authentication/sharing/etc handled for "free", native-like responsiveness while working offline, a low barrier-to-entry (unlike downloading/installing an app), a smoother experience across multiple devices, etc etc. These are all qualities that a web experience does better, and I think these are all qualities that people (myself included) value over the separate benefits of traditional native apps.
I've used Electron apps where no such restrictions have been put in place; it has lead me to believe HTML/CSS/JavaScript is nowhere near the best "cross-platform" toolset. It's more accurate to say that it's the lowest common denominator. Electron desktop apps today look and act like Java apps from ten years ago.
I'd say that the onus is on web developers to prove that it is capable of creating cross-platform apps that are even as good as, say, Eclipse, before attempting to call themselves "the best".
> do some light word processing.
Due to how much latency affects typing and interaction with an editor, I absolutely do want a native desktop app - neither Atom nor VSC react quickly enough for my editing uses, and Google docs is aggravating to write more than a page or two in.
>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?
> I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow
That says nothing except the sad state of the other native apps you use in your workflow.
The truth is that yes, indeed, I can find a lot of native apps that are just about as "good" as slacks native Mac (and iOS - it's really bad too) app, and I can also find a lot that are a lot worse. But why compare to them at all? We should be measuring how good an app is by comparing it to, in this case, the best of the best native apps on the particular platform, or across all platforms, if so desired.
Slack for Mac: Want to right-click a word to look it up like nearly every other Mac application? Nope, you don't get to do that. Want to turn off smart quotes or something similar using the standard method of right-clicking the text entry field? Nope.
These things _used_ to work in the Slack app. What happened?
FWIW, I don't have any of those issues in the Linux client. As of right now (in 4 orgs), it's using <10% memory as well, which is a common complaint on other platforms. At least on this platform, I am pleasantly surprised at the quality compared to native apps. I hope it improves on other platforms if there are issues there.
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.
Qt is a nice library, and was almost certainly the right choice for an open-source application like Wireshark that had previously used the execrable GTK lib on non-X11 platforms, but Qt tries really hard to make water not wet in MANY cases.
Just look at what it takes to get a Mac Qt application to work well in full-screen mode on multiple monitors. Or handling keyboard-focus changes when a notification window pops up (especially one for iMessages). Or any number of things where the underlying platform libs on Windows, MacOS, and X11 differ significantly.
People who've only programmed web applications don't understand how weird platform GUI libraries are or how many corner-cases they have, especially when dealing with multi-window applications, keyboard focus changes, and notification & tool windows. Programming an application to this stuff is tricky - wrapping it in a cross-platform lib is nearly impossible!
Qt exactly proves the point that cross-platform libraries will NEVER give you the same high-quality experience that native applications written to the platform libs will.
Three common ways of sucking, I find, about cross-platform apps is that they are often slower, more resource heavy and "a bad citizen" on the platform. Not all cross-platform apps falls under any one or all of those things, but many does, in my experience, and those that don't always suck in another way.
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.
They were happy because 80/100 is better than 0/100.
But how much happier would they be with 100/100. Just because you feed your guests chicken and they like it doesn’t mean that they would not like lobster more.
A good MacOS or Windows Dev can move just as fast as a web developer trying to make fake-native apps.
Yes, but one platform at a time. We served updates to Android and iOS users almost simultaneously. Again, I usually prefer native, non GCed apps. But I also don't try to fix problems where there are none.
If Android and iOS made it easier to share middleware libraries (C++ is a second class citizen for both), I think there would be a smaller incentive for HTML5 apps.
But the fact is that they would probably still be happier if you have served them native apps at the same rate because the native apps probably had been better in some way.
I get that sometimes it's not feasible to built native apps because you have to do the work twice in the same time and so on, but that is completely irrelevant to how good the product is. Is it good enough? That is a different thing entirely.
But to circle back to the original topic - if users would be much happier with 100/100 instead of 80/100, then Apple's refusal to allow developers to achieve 90/100 with the same effort is crippling user happiness.
Are they not allowing it? Do you mean that because you have to use their platform specific tech instead of some cross-platform tech, they are not allowing it? Maybe they don't believe that you can ever reach 100/100 with "webapps", except if you lower the general perception of what 100 is to what is actually 80?
I certainly don't believe so.
I think part of the gap is that some folks believe features are everything, and others believe that features are one thing, and quality, support, accessibility and other stuff is just as important, the stuff that in my mind makes good products in general, both in software and hardware, but also in wood-working and clothing and so on.
If features are everything, I can see why cross-platform is what you want, but that is so far away from anything that is Apple.
It's not even that. I hate it when a website prompts me to install their stupid app for funtionality that could easily fit in a webapp. If this standard means I don't have to install an app for every website I would be very happy.
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.
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:
...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.
> 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.
Maybe because they don't believe it's the best route to go for them and their users? I'm inclined to agree, although I'd like to see the open web succeed, but I will weep if I have to use web apps instead of native apps for anything that couldn't be a website.
> 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.”
Apple supporting PWA (Progressive Web Apps) is hugely important because it enables a future where web apps can natively support browser, Mac/Windows/Linux desktop, and mobile iPhone/Android/Windows native mobile with a single codebase of open technologies.
Why after over 30 years of experiencing cross platform "write once run anywhere* technologies do developers still think that's the best user experience? Yes it makes life easier for the developer but it's rarely best for the user.
I think this is the crux of the matter. Apple supporting PWA means lower quality apps for its users, and Apple has the market share to demand apps be native code.
I'm not trying to argue that it is the BEST user experience. I'm trying to say that it is hurting small dev shops and startups because they are being forced to learn a completely new tech stack in order to play ball. I could have spent that time implementing new features that users would actually use and in turn improve their business, or in this case, reach and help more people with valuable medical advice.
In the end, Apple got what they wanted. I needed a feature that PWA's can give me - but Apple hasn't added support for them in mobile safari, so I paid the $100 to get access to the app store, and was forced to learn a completely different language.
Yes, the end product has an arguably better and 'native-like' experience, but it took me longer to do and it is lacking some of the features that I could have rolled out if I was able to use PWA's. And it would have worked on Android out of the box as well.
I don't regret learning React Native. It was actually really, really fun. The community is great, and being able to write native apps now feels really good.
But its the principal of the matter. Holding back innovation for your company's own selfish reasons is a shitty thing to do.
Yes, the end product has an arguably better and 'native-like' experience, but it took me longer to do and it is lacking some of the features that I could have rolled out if I was able to use PWA's. And it would have worked on Android out of the box as well.
So am I as an end user suppose to be upset that you were forced to make a better product.
Holding back innovation for the company's selfish reasons?
Back in 2008 they said the same thing about Apple not supporting Flash and Java.
If anyone is being selfish to try foist cross platform apps that you admitted weren't as good, it isn't Apple.
I can’t disagree more. I find gmail to be a perfect example of why web apps are playing to the lowest common denominator and result in poor user experiences everywhere. Just my opinion though, I realise most people love it.
I'm on a Mac and mostly come from Mail.app, but many of these things would apply on Windows/Linux as well in slightly different forms.
- Speed. It's sluggish compared to the FastMail web UI, and slow compared to Mail.app on my Mac.
- System provided UI editing controls which would bring richer editing and consistent controls
- Consistent hotkeys - I know Gmail has rich hotkeys, but all my other software uses a fairly consistent set which can also access a wider range of keys than a browser can do.
- Automation - I use automation and tools like Alfred (/Quicksilver/Gnome Do/etc) and these can interface with native apps much more effectively through things like AppleScript.
- Drag and drop (you can drag and drop much more than you might think on a Mac, and I use it extensively)
- Centralised notification control in system preferences
- Better (and faster) layout – you're constrained to a web browser so there's less you can do in terms of good use of screen real-estate.
- Prettier – it might sound superficial, but I enjoy using apps that have a nicer design and Gmail, compared with many native clients, looks pretty terrible.
- Real multi-window support - using new tabs doesn't provide the same interface or interaction patterns.
- Real right-click support, with the options I'd expect for any other system app.
That's most of what I'd like to see. Note that an Electron app like Slack doesn't exhibit many of these.
It's better in that it required no configuration. But from a UI perspective it feels inferior. For example, native clients can just show you a list of all your messages, but GMail still paginates like a late-90s PHP site.
Believe it or not, in my experience, Exchange + Outlook 2016 stomps all over GMail. I find that its faster, searches quicker, and takes up _WAY_ less memory. I don't do any fancy things other than basic email, scheduling meetings, etc so YMMV.
I never quite understood the complaint about having to learn a new tech stack to write native apps. As a native app dev, it feels kind of like getting angry that your skills in motorcycle mechanics don't transfer to building rockets.
And this complaint practically always comes from the front end web crew... every other type of developer I've met has zero issues with learning the technologies relevant to a particular platform.
You can make a a native app, which will always be better than a webapp. As an iOS user, I have no intention of ever using webapps (including things like Cordova apps). If you can’t be bothered to make a iOS-native app with iOS native look, feel and features then just don’t bother.
Then they should use other technologies in the first place because web development ecosystem adds too much fuss to the process.
Also product builders usually want to provide good user experiences. You may be saving yourself from some additional code but delivering battery draining solutions with non-native UI patterns and broken accessibility to your users.
So because you want to provide a better UX for the one time you install the app, you want to sacrifice the UX of every single time you actually use the app. That makes no sense at all.
I'm not sure what you're referring to. Which UX issues are insurmountable in a web app?
Generally speaking, they can all be worked around by a good designer. The inferior install, update, and cross platform experience for native apps can't be worked around.
Are you talking about like realtime video authoring apps or games? I'll admit in those categories the web is often not the best choice.
I can download 95% of apps in under 30 seconds and all of my apps update whilst I am sleeping. And nothing is stopping you downloading new content in a native app which is where the majority of use cases stem from.
No one will demand it. You're just giving your users a worse experience. App store developers are people who have given up on speed. Y'all think a 30 second delay between screens with several pointless clicks is an acceptable user experience. It's sad.
Because some websites like forums, email clients, chats, calendars, stores, etc. are definitely applications, even though they're still websites and not native apps.
> Apple supporting PWA (Progressive Web Apps) is hugely important because it enables a future where web apps can natively support browser, Mac/Windows/Linux desktop, and mobile iPhone/Android/Windows native mobile with a single codebase of open technologies.
If 'a single codebase of open technologies' is so important then the same argument says Apple should abandon their platforms in favor of linux/AOSP. I'm sure a number of people here believe that (and strongly) but ... (1) Apple has a few hundred billion counterarguments sitting in the bank and (2) the entire industry has greatly benefited from Apple's efforts at pushing their closed platforms.
And if 'a single codebase of open technologies' isn't the be all end all then the argument reduces to "Apple should subsidize the technology I'm invested in". I bet turnip farmers think Apple should buy lots of turnips too.
I'm a C and C++ programmer with a background in embedded systems. My idea of a development framework is a Makefile, a bunch of headers and .a files. I've got an investment in a lot of libraries I've already written over the years. I want to develop great web applications. Should I feel frustrated that it's not straightforward to use my preferred toolset to build this web app? Should I blame browsers for not accommodating my development preferences? No! I need to bite the bullet and learn JS and HTML.
You need to pick the appropriate tools for the platform you're targeting, get out of your comfort zone and take the time to learn them.
> Apple supporting PWA is hugely important because it enables a future where web apps can natively support (...)
But it is not in Apple's interest to support these kinds of apps. They make money on the app store, and like to keep developers within the walls of their ecosystem.
You can definitely build that contacts app as a web app on mobile safari. HTML5 appcache lets you take it offline, localstorage gives you 5 mb of storage, web sql or indexeddb gives you 50 mb. You can use something like pouchdb to give you a clean wrapper.
Yes, service workers would be nicer, but you don't have to go native to do an offline app on iOS. I built one years ago, appcache is good enough.
What are you storing in your contacts database that's so huge that it can't be loaded over the network every time?
Are you hand-writing notes and storing the notes as images?
I use Apple/Google's built-in notes fields on the default addressbooks and it works just fine. I can't imagine having huge write-ups on individual contacts unless it was for some business purpose. In that case, I'd move to a dedicated note-taking application anyway.
He is probably concerned about users who cannot use a network all the time or have slow connections. Many phones have LTE but trying to load some modern websites over slower 4G, or even slower 3G, is a nightmare, not just from the size but also if they're not on a proper CDN.
Maybe developers should focus on the subset of platforms that they know they can deliver a first rate experience on, instead of forcing support for every platform imaginable.
It's a sad state of affairs for the web when we see articles claiming that one company's failure to adopt a standard amounts to threatening the web. The open web supports and should encourage competition, not blind homogeny.
I don't think it's misguided for a company to hesitate in supporting a platform which will enable its users to jump ship to another competing company.
> Right now, the only way for me to accomplish that on iOS is to make a native app. This means I had to learn an entirely new technology stack
It's not the only way - you can create a hybrid app with something like Ionic (obviously this is compiled to a native app at build time, but you never touch a line of XCode yourself).
One of the big selling points of hybrid apps is that you can use your existing Javascript/Typescript skills to create apps that look and feel like native apps.
"By fragmenting development effort, the overall product isn't as good on any platform."
At the same time, you're no longer focusing on what makes each platform unique, and just giving them all a lowest common denominator. That's not really good either.
"This means I had to learn an entirely new technology stack"
Learning new things is good.
"Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff."
This is absolutely wrong, and is just an excuse. You can make great stuff, and people can use it. You just need to put in effort.
Those who do not learn the lessons from XML are doomed to repeat XML.
The DOM is simply an in-memory representation of an XML structure, and any attempts to populate a DOM with JSON (or YAML or ProtoBuffers or...) will simply re-create XML. CSS is a language for writing XML transformations (i.e. XSLT).
Of course, we already have JSON versions of schemas, transformations, xpath, namespaces, and incompatible decoders, so perhaps it is already too late for JSON.
Honestly, we could have a cleaner XML. There's plenty of cruft there, the language could be easier to parse and navigate. We could also have a cleaner XSLT while keeping it's completeness.
We could have a better DOM too. It could be more semantic, and more modular. The good thing is that on this one we are moving in the right direction.
CSS would gain by becoming Turing complete. It also could be aware of runtime values.
But yes, JSON, YAML, and ProtoBuffers are all worsened versions of it. The good news is that we abandoned SOAP, but at the cost of abandoning service directories too.
Having developed many websites and many apps, HTML and CSS are really quite terrible when compared to something like iOS' auto-layout system, or even something like a DockPanel in Xaml (WPF on windows)
However, you wouldn't want to layout a document in Xaml or auto-layout either. Different strengths for different original purposes.
Personally I feel like a non-trivial part of why "web apps" (i.e websites pretending to be apps) generally suck comes down to this impedance mismatch
With most "native" platforms you can have a WYSIWYG UI editing (because those markup languages were designed with that in mind). You visually define the layout (with mouse/trackpad), drop components there, and it's all nice and easy to use. Surely, you can code your UI as well, but to best of my knowledge no one in their sane mind does this, unless they have some very good reasons.
With web apps (progressive or not), the usual approach is to code stuff by hand, and see the results in the synchronized preview pane (or nearby browser window), patching the code until it all fits. Even if there's some tool/IDE somewhere that would let me bootstrap a React/React Native/Elm/whatever app with a mouse - by dropping a button on a pane and connecting an event listener with another mouse click (like I had it in Delphi, 15 years ago), I think it would be an exception, not a rule.
Or maybe I'm just unaware about how things are really done and have false beliefs, heh.
Apple supporting PWA (Progressive Web Apps) is hugely important because it enables a future where web apps can natively support browser, Mac/Windows/Linux desktop, and mobile iPhone/Android/Windows native mobile with a single codebase of open technologies.
Why is that important? By fragmenting development effort, the overall product isn't as good on any platform.
There's an app I'm making on the side to keep track of your contacts (like a personal customer management system). This needs to store all your contacts offline, because it'd be too much friction to load everyone you've ever taken notes on over the network every time you open the app.
Right now, the only way for me to accomplish that on iOS is to make a native app. This means I had to learn an entirely new technology stack (React Native and XCode), completely rewrite my views, tie everything into my backend, and go through Apple's Byzantine approval process (which I still haven't done because I can't figure out why my app compiles and runs locally but complains about libraries not being linked when I try to archive it to upload to the app store).
This is unnecessary duplication of work that could've been spent writing new features, makes it harder to add new front-end features in the future (because now they have to be added in two places), and adds a huge lag in the time it takes me to push changes to the iOS client (weeks, vs. the seconds it takes to push a change to the web client).
If apple supported PWA, I would've spent my time making the database keep a local syncing copy on the browser (with minimongo or pouchdb), and then every platform would've benefited from faster page loads and offline syncing.
Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff.