Hacker News new | ask | show | jobs
by shinratdr 2989 days ago
From a user perspective, this is why I love iOS.

* Barrier to entry. If your project is more than a hobby, you can jump through a couple hoops to reach the iOS userbase. If the difference between $99 and $25 is make-or-break, you're probably trying to publish a hobby/low quality app anyways. There is a reason the Microsoft Store and Google Play are absolutely filled with trash, and this is part of it.

* Forcing you to use native controls. Thank god. I hate webapps. The only people who like webapps and their encroachment on good, native apps are webapp developers because it allows them to use their skillset to build something they don't know how to build. Everyone else wants native apps back, even if they don't know it. Case and point: the hatred for all the apps moving to Electron and the ridiculous amount of resources they consume. Most people don't know what Electron is, but they can tell you how much they hate the new Skype.

* Requiring a Mac. This is similar to the "barrier to entry" one above, but seriously. I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.

Software development is already very, very easy. The barrier to wide distribution is almost nothing. This is an extremely developer-centric perspective, which is fair, but at the end of the day, your users pay the bills and it's hard to be developer-first without also being user-hostile.

This strikes me as the analysis of a developer I would never support, because they care far more about making everything as easy as possible for them rather than making the experience good for me. It's important to remember that while you are doing some consuming, you aren't the customer in this equation. The users are.

24 comments

>If the difference between $99 and $25 is make-or-break, you're probably trying to publish a hobby/low quality app anyways.

Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.

>The only people who like webapps and their encroachment on good, native apps are webapp developers because it allows them to use their skillset to build something they don't know how to build.

You're excluding people and organizations who want to maintain a single codebase.

>I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.

My takeaway from this is that you've not met a lot of developers outside the U.S. or who have ethical concerns about mandatory hardware / software purchases as prerequisite to market access.

Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.

So they could afford a Mac and internet access, but they couldn't afford the extra $74?

As far as excluding people and organizations that want to use a single codebase - good. If they didn't want to take the time to customize their apps enough to make it work on my platform of choice, it's not an app I wanted anyway.

My takeaway from this is that you've not met a lot of developers outside the U.S. or who have ethical concerns about mandatory hardware / software purchases as prerequisite to market access.

And the market is at work - they chose not to take the time to make an app optimized for my platform of choice, and I'm not stuck with an app that isn't optimized for my platform of choice.

> So they could afford a Mac and internet access, but they couldn't afford the extra $74?

An old mac should be pretty cheap (the latest xcode runs on pre-2010 macs, even more so as they can be upgraded by hand — to a point) and if you're in SEA or eastern europe your internet connection is not $150/mo comcast. For instance in Romania high-speed internet is $15, but the average net income is $650~700 and minimum wage is ~200.

And I'd add that requiring a Mac is another unnecessary barrier to access. Things like Fog Creek's Glitch IDE are making it clear that it's possible to build things from any device with a browser.
And don't forget expo.io build process. I never have to open xcode anymore.
Well that's really cool. How is React Native coming along? I see it's still pre-1.0, but given that they've been going 3 years, I assume there's been a lot of progress.
Consider all *nix tools one uses on a Mac. Consider the hack which git on Windows is.

VS Code is an example of an universal, well-optimized app. Slack on the other hand...

Stuff like this is driven by diluted business decisions. Inferring from it that probably one would not use the app eitherways is borderline Linux-like fanatism fueled by self-delusion.

> You're excluding people and organizations who want to maintain a single codebase.

Not to put too fine a point on it, but some organization's internal engineering goals should not become our UX nightmares.

> You're excluding people and organizations who want to maintain a single codebase.

Isn't one of the long held up tenants of software development that you should "pick the right tool for the job"?

Because if, as a user the choice is between another shitty JS/web-app masquerading as a real app, and an app that's built properly with native API's and native code, I'm 100% going to choose the latter.

I bet you don't even know half the time when you're using a hybrid app.
> You're excluding people and organizations who want to maintain a single codebase.

Not my problem. Don’t shit on my user experience because what YOU want. Remember, I don’t need your product, but you need customers.

As far as ethical concerns about mandatory software purchases as a prerequisite— it’s not mandatory: you don’t have to develop for iOS. Make a website instead.

> Remember, I don’t need your product, but you need customers.

Not all customers are desired. Some are enough of a hassle for support (both in developing for the idiosyncrasies of their platform and potentially dealing with the idiosyncrasies of their personalities) that they represent a cost rather than a profit.

This is why some are perfectly happy that Apple's policies effectively exclude Apple users from some of their output. It effectively means a bunch of self importants, who would complain that the moon is the wrong shade of grey if given it on a stick, are conveniently diverted away from bothering them. Unfortunately while Apple platforms seem to have more than their fair share, such self importants exist everywhere...

Similar arguments can be made for not supporting IE, particularly legacy IE: unless you are targeting certain industries (investment banks: I'm looking at you!) supporting users stuck on old browsers can be more time+hassle cost then they are worth.

Is the person's app going to automatically end up on your device or did I miss something here?

If Apple's review board feels the app is trash, it will be rejected as such. And the original poster wanted to just do a website instead, but they also wanted audio to be playable in the background (which makes sense when you're making a for all intents and purposes radio app).

> If Apple's review board feels the app is trash, it will be rejected as such

Apple is not as strict here as you're supposing. While Apple's review guidelines do say that they reserve the right to reject apps during the review process if they're ugly or don't work well, in reality this is almost never the case.

> Remember, I don’t need your product, but you need customers.

This becomes much less compelling with apps built to be used within a large enterprise. At this point cost of development and maintenance become much more important, because you can always train your workforce to fudge their way around the suckass user-experience.

(Although, in principle, I agree with you and am generally not a fan of systems and products that sacrifice UX for developer expediency.)

Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.

Like what situation? To build an app at all he requires at least one computer, which is guaranteed to cost more than $99. He didn't blink at paying $25 to access MacInCloud.

The $99 fee is hardly a big deal. It's quite clearly there to encourage people to report charges on stolen credit cards, i.e. to make credit cards usable as a form of ID verification.

You're excluding people and organizations who want to maintain a single codebase.

There are ways to do that which don't require the web.

> Like what situation? To build an app at all he requires at least one computer, which is guaranteed to cost more than $99. He didn't blink at paying $25 to access MacInCloud.

You're from eastern europe, south america or SEA, and $99 is a serious chunk of money.

The latest Xcode requires sierra which runs on a late 2009 macbook (or even older using sierra patcher), and you can use that for other things than just publishing your application.

Like anybody was forced to write iOS apps... I'm an undergrad from Turkey and buying Apple hardware is impossible for me (and not really desirable ATM, but that's not the topic). But I don't feel I'm barred entry to the app-making business, I can start with a desktop app, a web business, or a even a Flutter app on Android and later port to iOS when it's financially feasible. iOS crowd is a bunch that wants quality software and is willing to pay for it, and that the entry to the market is not free is completely understandable. Otherwise it's like wanting to run a caf but not wanting to pay rent or resources. They don't owe you nothing.
Latest Xcode needs High Sierra, not Sierra.
There are ways to make Xcode 9.3 run on macOS Sierra, but I wouldn't recommend using them if you can avoid it.
> To build an app at all he requires at least one computer, which is guaranteed to cost more than $99.

Well, the question is who does it cost? The original purchaser, or the person that was gifted it or got it for free because it didn't work and put the time in to fix it?

Plenty of people get computing hardware for free or close to it.

> To build an app at all he requires at least one computer

It does not just require a computer, they require an Apple computer, big difference.

> There is a reason the Microsoft Store and Google Play are absolutely filled with trash, and this is part of it.

It's kind of ridiculous to pretend that the App Store isn't also filled with trash.

There are some excellent things (especially in security and privacy) you can depend on Apple's review either catching or warding off, but poor app quality is definitely not on that list.

(and as others have noted, far more apps are built with web views than you apparently realize)

I love electron and I've never built one and don't have any immediate plans to do so. I'm a Linux user and because of how easy electron has made cross platform, I am enjoying far more applications that support Linux because barrier is so incredibly low.

Are they resource hungry? Yes. Are they as smooth as a well polished native app? No. But, for many of these apps, the alternative is having nothing at all.

"Requiring a Mac." This most often bites me for testing Apple Pay. This assumes that writing an iOS is my primary responsibility. For some folks, that's not the case. This isn't a huge deal because I can just use a test device, but it is annoying.

This is a really interesting point I haven't heard before: that the silver lining of everyone making electron apps is better Linux support!
The silver is somewhat dulled by the fact that an Electron application is barely better than no application at all, only slightly less heavy than running VirtualBox in seamless mode, and has about the same level of native integration.
> slightly

Dude what are you on about? VirtualBox is 1GB minimum, better 2 and has to virtualize gfx card, meanwhile electron is talking to gfx drivers directly and takes 100-200 MB if used correctly.

I don't care about the $99, I absolutely loathe native apps (because I don't have nor want a smartphone) and there is no way I'll ever buy a Mac to do iOS development. I do have some Apple hardware here but it runs Linux.

Developers should be free to make their choices without being forced into some kind of eco-system, especially not with Apple itself focusing more on their gadgets and fashion items revenue streams than on making actual computers.

Does your distaste for native apps extend to the desktop computer? Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated. On my computer, native apps are much nicer, and feel like they fit in much better with the desktop environment.

If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.

VSCode, as far as I'm aware, uses Electron and is great.

Twitter's React web application was so good on performance and hitting all of the marks I used the mobile native application for that I was able to delete the native application saving space, and "adding to homescreen" for like, what, a few bytes of storage?

Facebook I just use the mobile web app inside of Safari proper instead of installing the native app. It's a pain that I have to wait until I'm on my iPad or PC to use messages (I don't install Messenger because I don't want a separate application just for a small feature of Facebook proper), but it's serviceable enough. Would be nice if Facebook would follow Twitter's lead and build a native-like web experience, but I guess they don't feel it adds the value and that's their right.

I'm completely game for people using these things and doing it right and if done so, yeah, I think it is better than or at least equivalent to native (PWAs != Electron apps, but can be served in them). It is also crazy to compare a 32GB-128GB device vs my PC with storage measured in TBs. I can afford bloat on my PC that I would prefer to keep away from my phone.

A native app to me is something that works independent of a network connection (with the exception of browsers and an email client, those are obviously pretty useless without and a browser is the 'gateway' to the online world), and without an interpreter. Most mobile phone apps aren't native by that definition, but let's stretch the definition and include binaries targeted at virtual machines.

So native apps that I'm happy to use: compiler, editor, whatever stuff I've written myself, cli tools, bash, ssh, openoffice, okular, Firefox and Thunderbird.

Your typical mobile app is just an extension of someone else's server. As such it should be a web app rather than a native app.

That's a strange definition. Native usually means that the application uses the platform's native APIs. The application could require a network, or not. I grant you that an app that should not need the network fails to work without a network connection probably means it's not a native app, and instead it's trying to execute on some server somewhere else (like a classic web page for instance).
> Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated.

How much of this is the fault of the Electron runtime and how much is fault of the developers?

When one looks at the sheer amount of code that popular frameworks (or, as I call them, crapworks) like Angular require the browser to load, compile and run, plus the resources that these apps end up gulping down... it's madness, compared to how far plain old jQuery will get you while running at a quarter of consumed resources.

Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.

How much of this is the fault of the Electron runtime and how much is fault of the developers?

It's completely the fault of the developer for choosing Electron when there are better tools available.

What would you use? (honest question)
If you want a native app, use native tools for each platform to create the best user experience.
Qt?
ever used VS Code?
Yes. I went back to Visual Studio. If I were using a Mac, I would buy Rider in a heartbeat.
Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.

It’s really, really not. You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.

> You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.

The usage difference in RAM and CPU usage will always be massive, because with jQuery (or if you're in for really high performance code, plain JS) you cut all the framework cruft and black magic away.

In addition, I would not be so sure about the development impact. JS frameworks come up every two or three years and vanish in about the same timeframe, yet the good old KISS-based dog jQuery happily barks along. jQuery devs are a dime a dozen, good luck finding someone today who does emberjs (if you want to maintain a legacy project) or knows the innards of the latest compatibility-breaking version of Webpack (if you ditch your legacy project and "relaunch" it).

I just don’t agree with this from any perspective.

First, the impact is minimal. React or a similar framework is not that big. In fact, React + ReactDOM is roughly the same code size as jQuery - 100k vs 85k minified.

Second, your custom DOM manipulation code is probably going to be a bit less optimised than a widely used library.

Third, you are overstating the difficulty. I would expect any competent front-end engineer to be able to pick up whichever of these frameworks is required. The different skills are a matter of a little on boarding and studying. Of course, there are many unskilled JS developers out there, but I don’t think that’s an excuse.

If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.

That doesn't necessarily follow. The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.

> The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.

Unfortunately, it has been shown time and time again that this isn't the case. Somehow, it seems that web apps just never get the performance that native apps do.

Unfortunately, it has been shown time and time again that this isn't the case.

Has it? Web apps might be positively correlated with poor performance, but I don't see any causal relationship there for the kind of apps we're talking about here.

From direct personal experience, some of the UIs I've worked on have been relatively complicated by web app standards, yet typically there's been no perceptible lag in any rendering or interactions. We could achieve that kind of responsiveness at least a decade ago, on much less powerful hardware than sits in your pocket today. Obviously there is an inherent delay in any communication required with the server, which is one of the main areas where PWAs and some of the other modern APIs can help to minimise the effect. Other than that, modern JS runtime environments running on just about any smartphone, tablet or laptop from the past few years are plenty fast enough for the kinds of software most of us are trying to run within them.

Of course, that's not to say there aren't many poorly performing web apps out there. It's just that I've yet to see one where the poor performance was demonstrably attributable to the fundamental web technologies involved, as opposed to simpler explanations like developers who had no idea what they were doing and relied on inefficient designs, bloated frameworks, and so on. You get that with native desktop software as well, but no-one's saying a modern PC can't do things quickly just because someone managed to write yet another text editor that had a noticeable delay just opening a file with a few thousand lines in it.

> I absolutely loathe native apps (because I don't have nor want a smartphone)

Why does not having a smartphone make you loathe native apps?

I'm guessing that the OP is an advocate of open software and user freedom. Native apps are generally locked to a specific proprietary platform: Windows, macOS, Android, iOS.

As somebody in support of free software and individual control over our computers, I think web apps are the best class of apps we've seen yet. Thanks to the proliferation of web apps, desktop Linux is finally a viable platform.

Of course, I'd personally love to see the bloat of the browser disappear. In my dreams, we'd be able to run React Native applications on desktop. This is already possible with react-native-windows, but we still are waiting for stable support on macOS and Linux.

They excluded themselves from a market and as a result, feel like the market is excluding them.
How are developers not free to make their choices? Who is forcing them into what eco-system?
Developers are most definitely free to make their choices.

Look at Windows Mobile.

-Having a barrier to entry is good useful only if your App-store search is crap. Also, the $99 is every year. Developing on iOS has cost me $900 in certificates, compared to $25 with Google.

-That's obviously wrong, see 100% of the top selling games.

-The top developers have to make clusters of freaking mac minis just to run their continuous integration tests. Do you think they are happy about that?

> -The top developers have to make clusters of freaking mac minis just to run their continuous integration tests. Do you think they are happy about that?

Top app developers should already be on hosted/SaaS CI services that offer Mac servers like Travis or CircleCI.

I wouldn’t consider myself a “Top Developer” but in that situation even I would run a single Mac with multiple OSX virtual machines.
> Forcing you to use native controls.

This is wrong. Cordova has been around for years.

Furthermore, it’s detached from reality. I released an app made with Ionic. It’s an app for average joe, not for devs or designers. Out of 20,000 downloads, I received exactly 0 complaints about performance or UI. Most users don’t care and don’t notice anyways.

And it’s pretty much the only way how I can maintain an app for both platforms as a solo dev.

> I released an app made with Ionic. It’s an app for average joe, not for devs or designers. Out of 20,000 downloads, I received exactly 0 complaints about performance or UI. Most users don’t care and don’t notice anyways.

Personal anecdote: I wrote an app to replace one that was written using Ionic because the experience was so poor. None of the complaints for that app were about the UI, because I assume most users, not being developers or designers, couldn't put their finger on what was wrong with it. However, once I released my app most my of reviews ended up being about how it was much better designed.

Average rating on iOS is 4.4 for my Ionic App.

Average rating on Android is 4.1

Especially the iOS app is almost indistinguishable from a native iOS app. Ionic is very well designed to mimic native UI controls.

In the end, it doesn’t really matter if your native UI lot runs some sliding animation in 60fps or if the very same animation is done in JS and runs with 60fps.

Did you re-design the UI, or just re-implement the same UI as native widgets?
How accessible is your app? Have you tried it with VoiceOver? How does it do with battery and memory vs another comparable native app? When there's an OS upgrade, does your app automatically adjust to new resolutions and device classes?
> When there's an OS upgrade, does your app automatically adjust to new resolutions and device classes?

HTML and CSS are far more proven at adjusting to arbitrary resolutions and device classes than the vast majority of "native" UI frameworks, specifically because nearly every device class needs to support HTML+CSS, but "native" frameworks don't have to support every device class.

Yes, it is neat that specifically, iOS is playing from some interesting fun toys like Cassowary solvers to support some pretty advanced stuff. From a pragmatic standpoint as a cross-platform dev I'd rather just let HTML+CSS do the work, because that can be used everywhere.

(Similarly, Browsers in general are pretty strongly accessible and HTML can be written very accessibly. Again, pragmatically cross-platform it's the easiest accessibility solution available.)

(Memory and Battery are somewhat fair questions. Given how much time people will spend in a Browser, though, I think the turnabout is better fair play: if there is such a noticeable battery/memory difference between native apps on your platform and websites/webapps, but you spend the majority of your time in websites/webapps, then what is your platform doing wrong?)

I haven’t tested accessibility.

Battery and memory: no big difference. And JS doesn’t run in the background.

Download size: 5MB

Upgrades: I had a native iOS app back in 2011 and this app required quite a few UI adjustments over the years to work properly on the latest iOS version and hardware.

Can’t tell yet for the Cordova app, but it works out of the box for all iPhones and many Android phones without writing a single line of additional CSS.

For sure, there are downsides to Ionic, but I’d strongly consider it. The single code base has so many advantages and cuts development costs with almost no downside for the customers.

It doesn't matter. Literally doesn't matter. Making apps work correctly is a lot of effort for zero gain.
I’ve been getting tired of seeing accessibility, accessibility, accessibility in every front end web/iOS/etc conference. Like we get it, everyone’s got it...

No longer tired of it, thanks.

I'm sure you didn't mean that to read that way.
Controls: It doesn't force me to use native controls. :-) My web app today is still using the free and opened web, and all the goodness that comes with that, for UI and code.

Requiring a Mac: Now you've met one. I built a halfway decent iOS app, and I don't want to spend $7000 on a Mac and its crappy dev tools and frameworks.

I've poured nearly 7 years of work into user experience. I don't need to redo all that for Apple's closed, proprietary platform.

$7000? Your bias is showing. You can buy a Mac for <$1000 and it's perfectly capable of developing most apps.
While possible, it's far from ideal. I had this experience, using an old MacBook to build an iPhone app. It repeatedly crashed because I had Atom and XCode open at the same time.
<$1000 mac for even moderate development use cases? your bias is showing now.
The $500 Mac mini can handle Xcode just fine, and that is a many year old machine that hasn't been updated. Maybe not if you've been spoiled on better hardware, but it performs adequately.
I used my personal $500 mac mini for full-time desktop and webapp development when employed at Citrix. This excludes the cost of peripherals, of course.
MacBook Air and Mini should be fine for most stuff, certainly for glorified web apps.
Exactly. I write the main code on my Linux machine, then switch to the MacMini for testing and UI finalization.
We're talking about a Cordova-wrapped SPA. You can develop those on Raspberry Pis if you had to. A 9 year old $250 MBP off ebay will absolutely suffice.
Yes, even for moderate development use cases. I've never had any problems.
I bought a 2013 Macbook Pro for $700. Retina Display. Where there's a will, there's a way.
Yes, I'm using hyperbole. :-) Even $1000 to build a free app is too much. (That said, going to Apple.com and clicking Mac shows me the base model for $4999.00 [0])

What happened to cross-platform apps? Why is it that Google and Microsoft are champions of the free and opened web, and even cross-platform dev tools for web development, while Apple is holding back progress?

I think the reason is their business is jeopardized by the free and open web, just as Microsoft was in the late 1990s.

[0}: https://www.apple.com/shop/buy-mac/imac-pro

"Clicking Macbook shows me an iMac Pro"

Yeah, no, it actually literally doesn't. There's no "Macbook" button on Apple's site. There's a Mac button. The Mac page then shows you a range of Macs, from the Macbook to the Mac mini, at the top of the screen. they are showing you the iMac Pro--their halo-effect product and newest release--on the Mac landing page; that's not the same thing and it is dishonest to assert that it is.

Open standards are good. (The open web, whatever. I use React Native, because I like writing applications that feel responsive.) Open standard thumping as a proxy for weird platform fandoms is really not. Stop.

Mac button, not Macbook, but you already knew that.

Open standards are good. And we should want them to win, because it provides a safe haven from the abuses of big corporations. And I think right now, Apple is stepping into those waters: they are holding back web standards in order to keep promoting their business, which is reliant on native apps.

Open standards aren't "good" if they provide an inferior user experience.
To be fair, judah said "going to Apple.com and clicking Mac shows me the base model for $4999.00"

Doing what he said takes me to:

  https://www.apple.com/shop/buy-mac/imac-pro
On which the only computer I see without scrolling is the Mac Pro. My UI design friends constantly tell me anything "below the fold" may as well be invisible.

Clicking the "Buy >" button takes me to

  27-inch Retina 5K 5120-by-2880 P3 display
$4,999.00

I know there are other options, but that's the default path for a naive user wanting to buy a mac from apple.com.

I hope casual users don't end up following that path often!

First you said "$7000 on a Mac", then I said "You can buy a Mac for <$1000", then you said "Macbook shows me the base model for $4999.00" and you linked to an iMac Pro.
You linked to an iMac Pro, a high-end desktop, not a MacBook. Entry level MacBook is 1299
You can buy a completely dev-usable Mac for under $1000. (My CI machine is a Mac mini I bought used for $350 and dropped an SSD and an extra stick of RAM into.) Its "crappy dev tools" are free.

This is some silly stuff right here.

How reliable is your CI machine? I don't have the log entries anymore but in the past I've seen Mac Minis that were set up as Jenkins nodes throttle hard, leading to variable job results. The Minis were running VirtualBox VMs which would arbitrarily report long running test failures. I remember thinking perhaps it was VirtualBox specific behaviour until I search for "mac mini cpu throttle" and found similar results.
For my purposes? Very reliably. But my use cases are very sporadic; I'm just exposing a webhook for my VCS and running when one of a small set of my personal projects are updated.

(It also runs a couple other small things for the house.)

> My CI machine is a Mac mini I bought used for $350 and dropped an SSD and an extra stick of RAM into

All but the vintage 2012 desktop Mac minis have been nuetered in the sense they are not upgradable.

"Neutered" is a weird term. The line is due for a refresh, I think it's got an i7-4578U Haswell in its top-end machine, but that's not "neutered". Yeah, they want you to pay for upgrades themselves and that sucks, but, whatever--my 2012 one has an Ivy Bridge i7 in it and it is still plenty fast for build tasks in my (fairly price-conscious) environment.

If I needed a beefier machine, I would be making much more money and justifying its purchase.

my 2012 one has an Ivy Bridge i7 in it and it is still plenty fast for build tasks in my (fairly price-conscious) environment.

That's the point: the current mini is worse than what you could get in 2012, due to removing the quad core option and upgradeable memory.

OK, so buy one used. It's just not a big deal for a home developer.
I'm guessing they mean the lack of memory slots in the current model.
You've poured nearly 7 years of work into user experience, and you don't appreciate the benefits of native UX, especially on iOS?

My company builds our app in React, with the performance and UI critical functions in Java (Android) and Swift (iOS). I've spent my career learning and applying one key rule about UX, little things can make huge differences in how enjoyable and productive the user experience is.

> I've poured nearly 7 years of work into user experience. I don't need to redo all that for Apple's closed, proprietary platform.

So don’t. I also don’t have to use your app.

Barrier to entry. If your project is more than a hobby, you can jump through a couple hoops to reach the iOS userbase.

Sure, I can do that. But I won't. If you buy an iPhone, I'm afraid you will just get an inferior version of my service, or you won't find it at all, because you bought into a platform that is developer-hostile.

In the meantime, all of my other customers, who are happy to visit my web sites directly or find them via more developer-friendly channels, will be benefitting from improved features or extra content or lower prices that we could offer because we didn't waste time jumping through Apple's hoops.

This is very much about barriers to entry, because every barrier cleared represents an opportunity cost. Nothing about jumping through Apple's hoops makes my service better for my customers, and all of it makes life harder for us.

Your whole argument about being developer-first also being user-hostile seems like one big false dichotomy to me. It is precisely because I have limited time and resources and I want to spend them making things better for my users and thus ultimately being more successful as a business that I won't play these games.

Fair enough, you'll miss out on a lucrative user base.
So people keep saying around these discussions, but I've yet to see any hard data to support it, either published by others or from our own market research.
You AREN’T making things better for your users — you aren’t making things better for you.
Your comment doesn't make sense, but even if it did, you don't have enough information about what we do to make any intelligent judgement and you're just being unnecessarily aggressive and hostile. Please stop doing that.
> Your comment doesn't make sense

Really? Does the argument that you're saving on development time by not writing a native app for your users, which gives them a subpar experience, not "make sense"?

> you don't have enough information about what we do to make any intelligent judgement

You're coming off as "you don't know me, don't judge". If this is how you feel, maybe you could share more information about what you do rather than trying to shut down the discussion?

I suspect that the comment he replied to had some typos. It basically says "You aren't making it better for the users, you aren't making it better for you". Taken at face value, it doesn't make much sense.
From a user perspective, I want PWA. I would rather PWAs (or something similar) to get first rate apps/aupport, so then it would be trivial to move off the iOS/Android OS. I want to have a smartphone I control. For iOS, I just don't control the phone. So far Apple has been reasonably good with privacy, and Android is almost by design user hostile for user privacy. If a third OS comes out (think Librem 5, PostmarketOS) with PWA support and there are already apps out there, it makes the switch much easier.
> Everyone else wants native apps back, even if they don't know it. Case and point: the hatred for all the apps moving to Electron and the ridiculous amount of resources they consume.

The main complain people have with electron, is its heaviness. You ship a whole browser just for your tiny app. If every electron instance was using the same library & the same process (esp. the same JavaScript VM), most of the trouble would go away.

> Most people don't know what Electron is, but they can tell you how much they hate the new Skype.

Most people hate UI changes, and the new skype brings a lot of it! On a technical point of view, the new Skype is quite ok, it's not like the old ones were especially good either …

Most people have been hating the new Skype long before they converted it to Electron.
> The main complain people have with electron, is its heaviness. You ship a whole browser just for your tiny app. If every electron instance was using the same library & the same process (esp. the same JavaScript VM), most of the trouble would go away.

Among other things, such as lack of accessibility, a UI that looks out-of-place on the platform, and general lack of refinement.

> Most people hate UI changes, and the new skype brings a lot of it! On a technical point of view, the new Skype is quite ok, it's not like the old ones were especially good either …

I'm still running Skype 7.59 because it's not a RAM hog and looks a lot nicer than Skype 8. The new Skype is significantly worse.

> This is similar to the "barrier to entry" one above, but seriously. I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.

That quote could be in Wikipedia article about survivor bias as an illustration. Of course you haven't heard it - anybody for whom it is a problem is not developing iOS apps and probably doesn't talk to you about it. I am in software industry for decades now, and I have developed software for dozens of systems, but I wouldn't waste my time at trying my hand at iOS development anytime soon - one reason being because there are too many hoops to jump over. And I already own a Mac. Imagine same position where you may need to buy one.

As someone who is both, there are times where you'd like to create a quick web application to do a task that is either very specific to one's needs or only needed for a brief period of time rather than going wholesale application development.

In this particular user's case, they just need some API features accessible to web and they'd be golden. As a user, if I have the ability to approve and later revoke the permissions (in the event WebAppX is a bit malicious in its permissions usage), I'm game. That's value added.

> they just need some API features accessible to web and they'd be golden

But now you have every single website asking for permission to use the microphone and camera and accelerometer or battery sensor. Every time some sort of device hardware is exposed to web applications, it needs to be rolled back in some way or the other because someone's found a way to use for fingerprinting.

> Every time some sort of device hardware is exposed to web applications, it needs to be rolled back in some way or the other because someone's found a way to use for fingerprinting.

This is odd to me. Do you think it's harder for a native app to fingerprint you? At least on the web I can block specific domains or scripting in general.

A native app will always be a net loss for privacy and sandboxing.

No, of course it's a lot easier for a native app can fingerprint you. The difference is that with native apps, I can trust that someone has already looked at this app to ensure that it's not doing anything malicious. Plus, I, myself, have to install the app, which shows that I put my trust in it.
I used to have this perspective, but recently I've started to find it problematic.

Curation, while effective, is always a monkey patch on top of security. Ideally, I want to sandbox code. I don't want to have to trust it. I think it's unnecessarily limiting to assume that users should only ever run code that they trust.

In fact even native apps already try to do some sandboxing through a permission model. It's just that their permission model is less effective than the web, gives users less control, and leaks more information.

I'm also not sure that this matches my real world experience. I might use Facebook messenger or Twitter on my phone's browser. Installing something like Matrix makes me feel even better about that. I would never install their native app.

In theory I trust apps more than websites, but in practice I find that I usually view the app store with just as much suspicion as I do a random website.

>requiring a Mac

No kidding. If you hope to develop apps for iOS, you better have a machine with the corresponding build tools.

I make a number of Cordova plugins. Many devs without a Mac often use PhoneGap Build as their dev build service. The turn-around to make a code-change and see the result must be about 60s.

But apple could provide an ios sdk for linux or windows.
Not going to happen
maybe they'll change their mind when their market share goes back to what it was 20 years ago (that's me being hopeful, it probably will never happen)
Most of your arguments are subjective and anecdotal. It’s also “case in point.”
> I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.

This is essentially begging the question, isn't it?

If the developer wasn't required to use a specific development environment, might they be able to produce a higher-quality app?

totally agree, Apple want quality not quantity, and to protect their users (so they are happy to pay a premium)
You might be applying your anti-Electron arguments a bit too broadly. PWA is not that easy, but the UX friction involved with downloading and installing native mobile apps is abysmal. Electron is (arguably) a shortcut for desktop apps, putting webdev convenience above UX. Whereas PWA is all about improving UX, and is also typically (in practice) more relevant to mobile than desktop.
> the UX friction involved with downloading and installing native mobile apps is abysmal

Where were you ten years ago? Remember installing software on Windows?

> Whereas PWA is all about improving UX

But it doesn't improve UX.

> the UX friction involved with downloading and installing native mobile apps is abysmal

Wouldn't PWA be the same too? In fact, I think having to figure out the web address and type it in, and then add it to the home screen is much more tedious.

> PWA is not that easy, but the UX friction involved with downloading and installing native mobile apps is abysmal.

Searching on the app store and hitting "install" is an abysmal amount of friction?

Yes.

Compared to links, anyway.

Well....OK, yes, not installing something is less work than installing something. I think that saying "abysmal" is being overly dramatic, though.
For me the great advantage of web apps is that you build a single code base for that can run on any platform (browser). That make it so much easier to maintain so you can focus more on features. If you build a native app for iOS you'll have to build another for Android and so it could be harder to maintain.
I think you've discovered his point. The advantage that you describe makes the developer's job easier, not the user's.

If you're an iOS user, where the monetary incentive is there for developers to invest the time to build you a native app, you don't care whether that imposes a greater hardship on the developer, because you're not the one affected. You've become accustomed to developers building something specifically for you and you're not willing to throw that away for what is a somewhat compromised experience that makes the developer's life easier.

As a user, I appreciate web apps because:

1. Web apps typically work everywhere, including on my Android phone, on my Windows machine, on my mom's Mac, and on Linux when I used to use it as my primary desktop platform. I know this without having to look up a compatibility table because I opened it in my browser, and other than mobile-version/desktop-version, web apps work the same way everywhere. Native apps are often platform exclusives, and even if they do work on multiple platforms, they work differently on different ones. Try asking someone who owns a Mac how to use MS Office when you're on Windows.

2. I know how to share web apps with my mom by texting her a link. Even if your native app has a share button, it's in a different place in different apps instead of just "click the address bar and hit Ctrl-C".

3. Web apps almost always work with my browser's password manager, ad blocker, and stuff. Native apps are more of a crapshoot there.

4. Web apps are limited by the browser's sandbox (this is not applicable to native apps on Android or iOS, since they're sandboxed pretty much the same way as web apps, but Windows and Mac are both still playing catch-up).

5. If Linux users didn't have web apps, they'd have no apps at all.

> I know how to share web apps with my mom by texting her a link. Even if your native app has a share button, it's in a different place in different apps instead of just "click the address bar and hit Ctrl-C".

On macOS and iOS you iMessage her the App Store link.

> Web apps almost always work with my browser's password manager, ad blocker, and stuff. Native apps are more of a crapshoot there.

And they do this on iOS as well, as long as you use Apple's password manager and ad blocker.

> 5. If Linux users didn't have web apps, they'd have no apps at all.

Well, I mean, besides the 10s of thousands in the software repos, sure. The amount of time I spend in web apps on Linux is minuscule.

Also, all Android apps are Linux apps (when we want to avoocate Linux as having lots of apps) and none of them are really Linux apps (when we want to advocate freedom).
Android apps aren't inherently closed; I use a handful from F-Droid, for example. I'd love it if a more open collection of apps could make the Android/Linux experience on my phone as good as GNU/Linux on my PCs (but tailored to the workload that I use my phone for, of course).
> Try asking someone who owns a Mac how to use MS Office when you're on Windows.

Try asking someone who uses native MS Office to use the equivalent web app.

Agreed. As a non-profit, there is no way I'm building separate codebases for each platform. I simply don't have the time or money to do that.

In this sense, the web has already won here: I'm able to take a single codebase (HTML, JS, CSS) and generate apps for 3 major app stores.

Why are you generating apps? Sounds like you need a website. Do your apps use the camera, accelerometer, AR, ML GPS or any other parts of a device? Or is it just a website with the cachet of being “an app.”

Most people releasing apps shouldn’t.

You are technically correct.

However:

> You might wonder, “Why even put your app in the app stores? Just live on the opened web!”

> The answer, in a nutshell, is because that’s where the users are. We’ve trained a generation of users to find apps in proprietary app stores, not on the free and open web.

however in that case there is no "free and open web." It is google's walled garden.
Also from a user's perspective, I'd prefer everything that doesn't need to be a native app to be a pwa. They are much more lightweight and more limited in permissions. Probably those apps don't need to be submitted to the store either, except for discoverability (users are now used to search for apps on the store)
> There is a reason the Microsoft Store and Google Play are absolutely filled with trash

So is the iOS App Store. If you dig past the first few search results you find tons of trash. But I'm not sure it matters how many low quality apps there are overall, as long as the store does its job of showing me the good ones first.

Yet most of the apps in the AppStore are absolute crap. Add to that the useless search. OTOH, many students or open source developers may want to try offering free or cheap apps of ok quality, but they are disincentivized by the cost.
The reason you don't like app's developed in a certain technology is because you are a developer. Normal users can't tell the difference, or don't care.
Exactly. If you are a Consumer, or want to sell to Consumers, then Apple is where it's at.
Gosh darn the cognitive dissonance!! The free market and users are completely capable of choosing quality apps, iOS/Apple needn't babysit, nay play brainwashing big-brother-evil-megacorp strangling competition/dissent, them in the process.

"If your project is more than a hobby, you ...."

Yes yes - if you're serious about your project, you'll willfully submit yourself to anal-probes by monopolistic mega-corporation that has inserted itself as the gatekeeper to running software on one's own legally owned hardware - which, in the history of computing, is a first.

When was the last time you let your refrigerator manufacturer tell you what items are allowed in your OWN FUCKING refrigerator? Why is different for iOS/Apple?

> When was the last time you let your refrigerator manufacturer tell you what items are allowed in your OWN FUCKING refrigerator? Why is different for iOS/Apple?

Well, if the things I put in my refrigerator started acting like malware, I think manufacturers might start taking a different approach...

But 99.9999% of app store rejections aren't malware related. It's a scapegoat reason of convenience, but not the real reason, v.i.z. Apple's insatiable monopolistic ambition of totalitarianism, of cock-blocking freedom on their devices.
Source please?

If your vitriolic rant has any substance, please present it. Otherwise you just come off as a cock-sure, know nothing asshole.

Ironic that you accuse someone of being a cock-sure know nothing asshole without a shred of evidence that app store rejections are somehow malware-deterrence driven.

Unless your vitriolic rant arises from some jingoistic fervor for Apple, and it bat-blinds you to Apple's totalitarian rules of engagement, the evidence is really, really apparent!!

Or maybe you really enjoy the Stockholm syndrome of Apple telling you want apps you can and cannot run on your iPhone. And you really crave for your Mac to get locked down in a similar fashion, in some sadomasochistic homage to your tormentor. But hey, whatever floats your boat.

Cheers

> if the things I put in my refrigerator started acting like malware

Sure, like if the supermarket sold something that spread mold spores to other food.

Yes, the users in the free market are capable of choosing quality apps. They do that by outsourcing the filtering to Apple.

Why fridge? That's basically what the supermarket does for me. They sift through a sea of garbage and show me a selection.

Apple just happens to be both the fridge manufacturer and supermarket.

If my supermarket released a fridge I might consider it.

> The free market and users are completely capable of choosing quality apps

You should get your ideology out of the way. Apple's customers generally expect Apple to curate its App Store and expect Apple to not allow malware in its App Store. This is true for Google Play and the MS Store, except that they are in a poorer position to demand greater scrutiny for its developers, and are lousier app stores for it.

TL;DR: an app store is not a government, it is more like a mall: its patrons expect it to exercise some oversight ensuring that its vendors don't sell lemons.

"You should get your ideology out of the way."

I suggest you get your ideology of rinsing and taking deep enemas in Apple's P.R. out of the way.

There's ample evidence against your fictitious arguments - if indeed Apple users LOVED the app store, the Mac app-store would drastically eclipse the traction of non-app-store-ed apps. Which clearly isn't the case. Q.E.D