514 comments

[ 3.8 ms ] story [ 270 ms ] thread
Why is this an issue? Apps built with the old SDK will still work on iOS 14, and you can continue to submit apps built with the old SDK for a while. Nothing says your app _has_ to be built with the new SDK on day 1.
Some apps (Pokemon Go) just crash on launch on 14 without updates.
Surely the developers had the 3 month beta period to identify these issues, and ship fixes, right? As far as I understand it, it's possible to ship fixes for a new iOS version before that iOS version actually launches, and indeed that's the idea of the beta period.
The new OS version is a moving target, and it only really settles down with the final release candidate - which can still be changing a couple of weeks before the actual release.

So yes, it's possible to write to the beta, but no, it's not possible to guarantee there will be no last minute breaking changes.

> it's possible to ship fixes for a new iOS version before that iOS version actually launches

No it isn't. Apple doesn't permit code linking against the latest SDK to be submitted until the SDK goes "GM". That happened today.

To expand on this, if your app is "broken" because of changes made that require new OS features in order to "fix" them (such as the new limited permissions for photos, contacts, and location), you were completely unable to issue a new update to fix them until the end of the event. That gives you ≈24 hours to get the new GM, create a build (including setting up your CI system with the new GM, if applicable), make sure no new bugs have been introduced, submit to and get approved by App Review, and launch the update. If you couldn't get all that done in that time, you're probably going to have at least a few negative app reviews from early adopters.
And even then, who is to say that users are going to instantaneously download your update before/during their upgrade to iOS 14 (even if they have automatic app upgrades turned on, which they might not).
Being able to point your users to an update to fix their problems when they come to you for support, or when they go to write an angry review that their app is crashing but they see “iOS 14 support” at the top of the app’s page, is likely to help there. Especially since the earliest adopters are frequently technically competent enough to do that but also frequently demanding enough that their apps work on day one.
So, maybe you can get to it in a couple of days. Fix what you can using the old SDK before GM build becomes available. Then you have a small amount of updates once apps using the new SDK can be submitted. The app will be temporarily broken for a few days on a brand new OS until the update goes live. Is that really a big deal? The world doesn't come to an end if you get a few bad reviews from impatient users. I remember being in the mobile app development rat race and am so glad I left that world behind. Too much daily panic about things that really don't matter much.
Ok, but surely you can understand why people would be upset with Apple for doing this when they had no reason to do so?
The new location precision user auth seems to have been done in a backwards compatible way, at least in my testing:

- app with existing location permission in iOS 13 gets precise location.

- when the user prompt appears, it looks like precise location is the default in the UI.

(This is with an app build against iOS 13 SDK -- not sure yet if the iOS 14 SDK changes things.)

I think Apple will likely change this in the future, but right now devs are getting the time they need to adjust.

(As is, this new permission does almost nothing since 99% users will accept the defaults. I think they'll probably require more explicit action on the user's part to get precise location in the future.)

That isn't strictly true, several apps have launched their iOS14 ready versions ahead of the public release. All they can't do is use new SDK features.
You can't link against the new SDK, but you can link against an old SDK, but fix the bugs which are associated with iOS 14.

~All of the bugs I've ever seen on a new iOS release are just where they've tightened up some behaviour.

You say "tightened up" and perhaps that's what they meant internally, but as it stands my (simple) app's behavior when using the search bar is different and broken on the new update even though I'm using the API in a supported way. So it's really a bug.
But they only released the XCode GM today.
I have applications and games from the 90s that still work in Windows 10. The idea that developers have have to constantly push updates is unproductive in my opinion.
That's a decision made by Microsoft which has pros and cons. There's significant overhead in maintaining this backwards compatibility. For an OS used by corporations all over the world, its worth it. For a mobile OS it will likely reduce their ability to deliver changes.
I agree, I think a lot of what holds Windows back is the baggage from the past. Ideally OSes would live somewhere in a healthy middle, where we can’t expect 10 year old software to run on the current version of an OS. On the other hand we should expect 1 month old software to run on after an OS update.
Apple used to give a shit there. They did a bunch of extra work so you could run OS9 apps under OSX for a few years, and they did an amazing job of making 68000 code run on PowerPC...
A ton of software from that era stopped working when XP was released. For instance storing settings in an application's installation folder was common until Microsoft stopped it. Anything that ran as a service but interacted with the desktop was out of luck. This idea that everything from that period continues to run is a myth.
I never said everything. But a lot of the software still works. Some work with minor workarounds. Of course some programs will break with an update. But in my opinion creating a culture where an update is expected for software that is a couple of months old at best is really unhealthy.
no? all these things are just a couple configuration away from working.

the real things that were dropped since then were 32 bit protected mode apps, and for such you have plenty options for both virtualizing and paravirtualizing.

I can boot basically any other version of Windows under my windows system using Microsoft provided software.

I can even just go boot up older version of Windows on current hardware if needed be, up to a point.

almost everything from eighties to today I am able to run one way another, nothing "stopped" working.

Apple physically removes old software from their delivery platform or signing servers and if you lose your devices it's lost forever

how does it even compare?

Until you read Raymond Chen’s blog about all of the hacks that have been built up for the sake of backwards compatibility or try to run Windows on a low resource computer like the low end Surface computers and can’t because of code bloat.
I have been developing an app using the new SwiftUI 2.0 for iOS 14 during this beta. My builds have been breaking constantly between beta seeds, due to symbol name changes etc. And Apple have never allowed you to upload a binary linked with a pre GM SDK for release.
IOS 14 for developers was available for a long time. Also this is a norm with all SDKs, engines, tools etc - new versions always have new bugs that will be fixed in updates.

Especially considering that only a small percent usually updates to new version of OS in first few days.

Uptake is very rapid, and new bugs can show up between a beta and a GM release of iOS. It's not enough baking time to test against a GM version of iOS and successfully submit an update to the app store that is accepted and reviewed that is the issue here.

Imagine if your app crashes on launch with iOS 14 GM and does not on the latest beta, your business has been materially effected as a result.

If you’re not seeing how, one sentence: angry users leave reviews.
I agree, but the amount of apps that crashes is not that big. Also, this is only for a few days, until the developer fixes it.

Sure it would be nice to have a few days of extra preparation. But the post is obviously a result of pure frustration by developer and is exaggerated.

If you call everyone assholes because of such things then all software industry are assholes.

I am already hearing screams of "This worked under iOS14beta6 from last week!!! Now it crashes on launch!!!"

(From firends/contacts, none of the apps I have to deal with, at least not so far...)

If previous years are any indication, approximately 30% of users will update on the first day.
This isn't an sdk issue, it's a purposeful decision by Niantic to not support beta OSes to avoid potential exploits. Fwiw it finally works now with the 14 GM that went out :)
It didn't work with the GM, they pushed a Pogo release today which addressed compatibility.
Pokemon Go released a fix today and it's already working ahead of iOS 14 being made generally available.
A ton of apps released updates today, I feel like these are the companies that are more tight with Apple, getting their app updates in quickly.
Some apps look broken or are actually broken on iOS14.
I’m starting to see a pattern where it’s always the same apps that are broken on each major release. I suspect the developers of those apps are simply incompetent.
You seem like a really nice person.
Perhaps, but updating their apps on a dime is simply unreasonable regardless.
We only got the GM last night? how can anyone 100% know for sure their app is not going to break in some unexpected way between then and now? Thats the point of the grace period and the whole article / discussion here.
I’m talking about apps that have been broken since the first betas.
Those aren't the ones we're discussing here.
Or they're always on the bleeding edge using the latest features.
But it's not necessarily because they use the old SDK that they are broken. And there have been betas available for some time
Betas being available doesn’t solve the problem because you can’t submit updates compiled using beta versions.
Right, but the point is you can use the beta to validate that your app, compiled with the old SDK, still functions normally on the new OS
There are changes between each beta. There are also changes between the beta and GM.
Sure, but do those changes actually cause any apps compiled with the iOS 13 SDK to look or behave significantly differently on the beta vs the GM?
What Jamil7 commented..

I stopped/dropped my iOS dev efforts. I had an app on Apple Store, and eventually pulled it because of the constant updates demanded by Xcode. Yes things were still working, but unless someone is willing to dedicate 'many' days every 3-6-9-12 months to catch-up on new requirements, it's just not worth it. For someone who does dev for a living, it's game on, for others who may want this as a side hustle, it can be overwhelming (keeping up with Apple). I don't blame them, this cat&mouse just didn't work for me. It could as well work just fine for the other part-time/hobby devs.

Same here, iOS was never my main thing, but I did write a couple of apps for it. I can't remember the specifics, but it seems way too common for them to change an API that ought to be already settled, for lack of a better term.

This just means that every time they change something, the devs have to rebuild, with an unknown amount of time spent. It might be as easy as just changing a couple of lines, or they changed the API so much you have to rethink your code.

And this is for apps that aren't using anything new, it's the old APIs that are changing under them.

What constant updates demanded?

I recently pulled it but I had a ios app since 2010, nothing advanced and was only updated every couple of years.

There was only twice I had to do a update because of iOS updates. Once a crashing bug and once to look nice on large screen devices.

You are "lucky" that your code was not affected/impacted from the changes throughout the decade. I have written my first app in the winter of 2017, and because of the functionality/libraries/code I used, every update has been a pain in the butt. Not impossible, but I did it as a hobby, not as a profession/income.

I understand the need to progress and develop/create/evolve the programming languages, techniques, environments, it's just not fit for a hobby (in my case)(YMMV).

What has forced you to update? iOS has not changed how core APIs work in a decade.
I have Apps from 2013 and 2014 that have never needed updates. What has forced you to do them?
But who will suffer from poor app ratings and support requests if something doesn't work correctly? Not Apple.
Honestly, this is why we need the Web. But Apple even blocks that since they don’t allow any browser engine apart from Safari, meaning that there is no

- Add to homescreen dialog - Background sync - Proper push notifications - Proper WASM support (a lot of features are missing)

Honestly, at this point, the government should step in, like they did at the end of the last century with Microsoft. Walled gardens hurt innovation a lot, and the App Store in combination with the restricted web on iOS are the ultimate expression of the former.

Why wouldn't you use Android then?

I would personally like to continue paying higher prices to protect myself from low-quality background-syncing byte-code-obfuscated web-pages with push notifications, please.

This doesnt happen though. Look at the state of web apps accessed through your computers browser - there is no issues with quality if you want a customer base.
My computer browser is indeed fine, but my mother's -- is an entirely different story. I am really happy I can still get her an iPad these days.
My mother buys books when she wants to read

My mother uses her phone to actually call people

There's no risk she's gonna use apps that she doesn't know

My mother is not stupid, for sure she' s not more stupid than me.

I'm growing tired of this false and ageist retohric

Denying the existence of someone's mother is quite rude.
My mom exists, she's 74, she never had a malware problem in her life.

Maybe she's smarter than us all...

"Don't feed egregious comments by replying; flag them instead."

https://news.ycombinator.com/newsguidelines.html

(comment deleted)
Can I ask what's "egregious" about my comment?

an I not say that my mom, albeit being older than me, does not need her son's protection from malware and certainly does not need Apple to tell her what's right, just because she's older?

Is ageism permitted on HN?

Something can be said for both. I have built a couple of 15 year old websites with passionate users who have been begging me for an app. Not to replicate the website, which works perfectly on mobile and is very up to date with best practices. They just want it for push notifications. I can switch to Android, yes. But my users won't switch phones for just my website. And I can recommend something like Pushover, but that's too complicated for most users.

Just enable the API Apple, I bet you already have it hidden behind some flags.

Why wouldn't you just do exactly what your users passionately want, and make a small app just for notifications? You may even make it paid, so that your efforts are compensated -- I am sure, the users will be happy to support you.
I am working on it. But as a web developer this "small app" and everything that comes with it is easily hundreds of hours of work, just to clumsily recreate functionality that's already working in other browsers.
Email them? SMS Them? Its not pure notifications, but its far easier to implement.
Email would get drowned with all the other apps with the same idea, which is exactly why Apple shouldn’t allow it.
Why Apple shouldn't allow websites to email you instead of causing those websites to create iOS apps?
No, it's why apple shouldn't allow notifications from the web. People are already drowning in notification spam from native apps. To the point where Apple has added three different ways the OS prompts you to disable notifications.

People just allow everything and then get overloaded by all the worthless interruptions.

If Apple would make it so that websites can’t request to enable notifications, but only via manual user action, I’d still prefer that to developing an entire app to fit that goal.
You’re very much making this out to be more difficult than it actually is. If you’re a webdev throw a web browser frame in, or use react native, or just spend the few hours it takes to learn how to setup and app and push notifications and add a bullet point to your resume.
Not sure what I need a resume for. I'll probably never work for an employer and I think I'm a better farmer than a webdev.

I know how to design and build things with my hands. I also know how to design logos, websites and other things. I can code and enjoy building and maintaining the network of websites I built in the past 15 years.

But I feel I'm spreading myself too thin when I'm also learning to code in React or Dart (Flutter) for a single one-off project. I fear I won't be able to put in the hours required to become adequately proficient in another field that's constantly changing.

No you are not spreading yourself too thin. Each new language or framework you learn will teach you something you’ll use for the rest of your time programming. You may not remember everything you learn exactly, but it will help you carry conversations or know where to start should you be tasked to need those skills in the future. Also Google is your friend, you’re never going to know some language or framework so completely that you can verbatim spit out it’s docs and signatures without some reference.

The rest of what you said sounds pretty on par with the rest of the self taught programmers I’ve met (me being one of them).

I have e-mail notifications, yes. But a growing amount of people don’t check their email regularly and it gets drowned out.
I feel your pain, for me as a strictly back-end developer it is the same when I have to make front end.

May I suggest trying to outsource this small app to a freelancer? It could be a quite time- and cost-effective small project for someone who already has extensive experience with iOS.

But that's exactly what Apple wants. They want you to invest your time in their ecosystem because that prevents you from spending time in other ecosystems. Every thing they do that makes it more work for you to make an iOS or MacOS app is time you won't be spending making things for other platforms including the web.

plus, they get the added bonus that they can demand you pay 30% of various transitions that they couldn't demand if you just left it a website that happened to be PWA

Their incentives are entirely aligned not to support the latest web standards and not allow any other browsers on iOS to add them

How many apps that are just an interface to a website and could be viable as a website if only iOS Safari had push notifications would actually bring in any significant amount of revenue?

Besides that, according to the latest App Store rules, apps that just surface cross platform services aren’t required to have in app purchases.

A large amount of apps could just be a website if Apple supported more API’s. It would also bring bigger budgets to webdev teams and improve the quality of their webapps.
Care to name some web apps that are successful on Android but are required to be apps on iOS?
You've got it wrong, because Android has much looser review policies so these apps don't have to be web pages on that platform. People (including Apple!) push web apps on iOS to not be subject to App Store review.
It doesn’t matter. If PWAs were good enough on Android, and seeing that you would probably need to build a web app anyway. Why not just build a web app + iOS app and not build an Android app at all?
Why rephrase the question? Lots of apps could have been just a webapp. It doesn’t have to be popular or succesful to prove that point, because it’s the smaller apps / teams like my one man company that would profit the most. Let larger companies spend their money on squeezing out maximum performance via native code. And let me use the browser for the 10k users of my app.
If the argument is that Apple is holding back PWAs, then there should be a lot of corresponding web only apps on Android that are forced to be native on iOS. The developers would have a web app anyway for the desktop so you should see a lot of apps that are PWA apps with iOS apps.
Why should there be? There are thousands of webdevs who weren't 'forced' to be native on iOS, because they don't have knowledge and budget to be native.

You're asking the wrong question.

Whether there should be or not. The question isn’t why doesn’t every website have a native app. The question is if PWAs are good enough for Android because of its great support and not good enough for iOS. You should see a lot of companies doing iOS + Web instead of iOS + Android + Web. But that’s not the case. Companies have spoken with their budgets. They decided that it was worth the money to have native Android apps.

Could it possibly be that HN posters are wrong and PWAs aren’t good enough on Android either?

Almost all smaller e-commerce websites don't have an app. They rely on their website + e-mail notifications.

Would they enable web notifications if it was universally available? Yes. Would they enable it just for Android users? Some do. Does this say something about the quality of PWA's? You tell me. You seem to be adamant that the web sucks, yet literally millions of companies are succesful on the web without accompanying apps.

I never said the web sucks. The thesis was that Apple was holding PWAs back and given a choice, app developers wouldn’t create native iOS apps and just create web apps. If Apple’s lack of support for the necessary APIs was the deciding factor, the same developers who make native iOS apps wouldn’t go through the trouble of making native Android apps - yet they do.
No the thesis is that Apple is holding the web a a whole back. I’m not the one that says Apps like Youtube are better off or even good enough as a PWA. I’m arguing that if Apple enabled the notification API, a lot of websites and apps can save money by not replicating simple functionality in a native app. Your arguments don’t refute that at all.
If the lack of push notifications on iOS were the only thing forcing developers to create iOS apps, those same developers wouldn’t overwhelmingly be creating Android apps.

Where are all the developers who are being forced to create iOS apps but are “saving money” by not creating Android apps because PWA support is so good?

Most skip making apps all together because they rely on email notifications.
I agree. But if PWAs were good enough on Android, you should see, depending on your budget from largest to smallest:

1. Web, iOS, Android

2. Web, iOS - since PWAs are suppose to be “good enough for Android”.

3. Web

But you hardly ever see #2. Why is that?

Doesn’t matter. My point still stands. You keep repeating yours, while failing to see mine.
You’ve made a point without any evidence. If your point is that PWA’s could save developers money, rationally you should see developers saving money by only creating iOS apps and PWAs. Developers with real money on the line haven’t made that choice.
Breaking up your question into two pieces:

> How many apps [could] be viable as a website if only iOS Safari had push notifications[?]

I’d say a lot.

> [How many of them] would actually bring in any significant amount of revenue?

Adding this caveat doesn’t change my answer—but I really don’t like what it's implying. Software is not suddenly without value just because it doesn’t make money.

> I’d say a lot

Yet you didn’t name any. If that were the case, you should be able to name the equivalent web apps on Android that must be apps on iOS.

> Software is not suddenly without value just because it doesn’t make money.

So where are those “valuable” web apps on Android? Also revenue is the most objective way to measure value.

> Yet you didn’t name any.

Reddit, Trello, Twitter. Probably Discord and Slack too.

I haven't used Android in years but I certainly don't see why these wouldn't work as web apps if you had push notifications. All the functionality is there.

And none of those companies thought the web app was good enough to eschew native apps on Android. Why is that?
Because they have the budgets to do both.

That's why you're asking the wrong question.

Companies don’t just spend money because they “have the budget”.
No but that doesn't refute my point, does it.
What is your point? If the vast amount of the industry thought PWAs were good enough, they wouldn’t create Android apps when a web app would do.. Companies don’t just spend money needlessly.

You should see a proliferation of cases where companies create an iOS app and a web app for everyone else.

> Also revenue is the most objective way to measure value.

Nonsense. Wikipedia must be worthless for you? What about air? Do you feel you'd breathe with more satisfaction if someone was profiting from the air you breathe?

On the other hand, there's plenty of immensely profitable things that have negative value. Cigarettes? Oil? Weapons? Opioids? I could go on and on.

And you still haven’t come up with a situation where a major developer was forced to make an iOS app and decided to be content with a PWA for Android customers.

“Value” has a definite meaning in economics. If someone is willing to pay for something, it has value to them.

(comment deleted)
I don't even care about iOS. I just despise your definition of value, since it's simply wrong and dangerous.
Whether you despise it or not. It’s the only objective measure that we have to ascertain the value that a population puts on an item.
How can it be objective when every single individual would bid a different price for the same product, if asked without being shown the market price beforehand? It's all about perception and -my friend, I have bad news for you- perception is all but objective. Yes, perception of value can be manipulated through tools like marketing. That doesn't make the product itself anymore (or less) valuable than it actually is.
That’s the issue. Anyone could respond that they have an app that valuable to only them and their best friend.

What better choice do we have than to measure value across a population? How much value a population places on something based on how much they are willing to pay is objective. Whether that value is utilitarian or based on other factors is subjective.

Are we really arguing about basic supply and demand? Yes suppliers have methods to drive demand.

I am 100% convinced that mobile Safari is worse for the future of the web than IE6 ever was. And it’s 100% intentional.
Can you elaborate on what you foresee happening, and why?
On top of the now years old and still not implemented notification API, Apple recently declined to implement 16 other PWA API's, citing privacy concerns.

They could make every API opt-in or propose improvements, but they won't.

With IE6, people were at least allowed to install more capable browsers. With iOS there are no other browsers. Only user interfaces around Safari webviews.

This is an unnecessarily pessimistic view.

Yes, Apple wants us to spend all of our time interacting with / committed to their users. No, that aren’t maliciously trying to steal our time from other platforms. The thought chain ends with their platform, never considering that we even have other platforms to support.

A self-obsessed outlook is different from a deliberately sabotaging business plan, even when they present the same outward behaviors. Occam’s razor.

(comment deleted)
> to protect myself from low-quality background-syncing byte-code-obfuscated web-pages

I am not sure why other people being allowed to install other browsers on their phone would force you to do anything.

Because app developers will use other browser engines allowing them to ignore any of the privacy constraints in place at the moment.
That's already possible, and an app has far more access to your device and data anyway.
Apps cannot currently use other browser engines on iOS
Most of the web privacy settings are specific to Safari, not the Webkit browser engine.

Also an app can access and send more data than a browser window. Anything the webview can block can just get transmitted by the app itself separately. So there's no reason to block 3rd-party browser engines as the GP post says.

safari is enough and has enough bugs to be a totally good vector for malware

The real security issue is: if a bug in Safari is found (it happens quite often) users cannot use another browser in the meantime.

(comment deleted)
> has enough bugs to be a totally good vector for malware

Not for most people.

It's the main vector for malware on Apple phones (and mac laptops)
Most malware is installed consensually, not as the result of bugs.
So the only solution is to remove the computation from computation devices.
> Because app developers will use other browser engines

That still does not force you to install those browser engines.

If you want the apple approved apps, in the apple approve app store, that fine. But me using different settings does not force you to not use those approved apps.

Even if they switched to Android, they'd still have to ensure iOS compatibility since Apple has ~60% of the smartphone market in the US. Any abusive behaviour from Apple at this monopolistic stage is just asking for an antitrust case & resolution.
That's a misuse of "monopolistic" - 60% is not a majority to the point of no competition. Any developer could write an Android-only app if they wanted, they just don't do it.
Most consumers only handle one phone.
So? Apple has a monopoly on Apple products? Big deal. Ford has a monopoly on Ford trucks, Sony has a monopoly on playstations.
Apple has never had even 50% of the US smartphone market.

https://www.counterpointresearch.com/us-market-smartphone-sh...

iOS is 60% of the mobile (phone+tablet) market

https://gs.statcounter.com/os-market-share/mobile/united-sta...

>Statcounter is a web analytics service. Our tracking code is installed on more than 2 million sites globally.

Sorry but this is not an effective way to gauge market share of a browser or a platform. That 60% figure you're throwing around is not an absolute metric. It's based only on visitors to websites that use the "Statcounter" tracking code. There definitely is a large margin of error using this to gather statistics about market share.

In comparison, the other commenter's link is actually more accurate because:

>This report is one of the series of reports which tracks mobile handset: Smartphone and Feature Phone shipments every quarter for more than 140 brands covering more than 95% of the total device shipments in the industry.

Tracking site visitors based on sporadic implementation of a tracker, vs getting actual numbers of units shipped/sold. I'm going with the actual numbers, not the sort-of-guessing of Statcounter.

If you track shipments, how do you handle iPhones generally staying in use longer than Android phones?

(Disclosure: I work for Google)

Neither one is a great way to measure market share. Using tracking pixels is notoriously bad though, because it tends to lead to an echo-chamber like effect. Not everyone with a device will visit a site with the specific browser tracking code, and many people will visit those sites many times from different IP addresses, and even different browsers installed on their device. There are many ways tracking code can lead to false statistics.

Units shipped doesn't tell the whole story either, but it is a specific metric that doesn't suffer from bots gaming things or any of the other problems that using stats based on tracking code can lead to.

Studies have shown that individual iPads and iPhones are used for web browsing much more than Android devices, just as their users spend more on apps.

So Web Browsing is a very imperfect measure of installed base. Worldwide estimates are that that less than 20% of mobile devices sold are iOS, roughly 15% iirc. It’s almost certain US sales percentages for iOS are much higher, but no where near 60%.

> I would personally like to continue paying higher prices to protect myself from low-quality background-syncing byte-code-obfuscated web-pages with push notifications

are you really saying you would pay higher prices because you can' t press the "no" button and never visit the same website again?

Along with every time I have to press OK to the “we used cookies” dialog, using the web is already like a “punch the monkey” game.
These modern web APIs have a massive user experience problem, and if we want the web to be truly competitive with native, we'd be foolish to ignore that.

Beyond the "punch the monkey" game you mention, another massive problem is that web push notifications have just become another vector to deliver spam to users. If you look at devices belonging to "normal" users, you'll often see dozens of spammy web notifications (pornographic content, "30% off, BUY NOW", etc...). And because these are average users, they don't necessarily understand how to configure their devices to reduce or eliminate the spam.

Web push notifications needs a way to proactively filter out those that abuse the API, otherwise its doomed to become just another vector for spam that pisses off end users.

I'm angry at Firefox because it was the only browser that I trust that allowed me to have extensions to solve my problems with bad websites on mobile and they removed them.

But bad websites are not something we are going to get rid of using only iPhones...

The difference is that notification spam on the web is allowed to escape the sandbox. Because of the punch the monkey nature of the web, I inadvertently clicked “allow notifications” on both PCWorld and Tom’s Hardware on different occasions - they both spammed me at least once a day. But not enough to figure out how to disable it.

To get rid of the cookie notifications, I can at least set web pages I go to default to reader view.

I never accept web notifications, not even on slack.

The problem is that if Apple singlehandedly decide what's right and what isn't we are back to IE.

There is a middle ground I would be okay with. A website is only allowed to ask you if want notifications if you added it to your home screen. If you delete the web page from your home screen, it automatically disabled the notification. It falls within the same paradigm that people are accustomed to.
AFAIK this is not the way Safari works and it's not the main motivation for Apple

They just don't want web apps to rival with the native ones skipping the whole store experience and fee

But that's just speculation on my side, I have no data to back it up

This makes no sense. As I said in another reply. If PWAs are so great, why aren’t companies bypassing creating Android apps and just telling Android users to use web apps?

On top of that, how many apps are really just surfacing server hosted services where there are no in app purchases?

According to the data I found, PWAs make 50% of the Android market.

Among the most popular there are

- Uber

- Pinterest

- Telegram

- Trivago

- Tinder

- Google maps Go

- AliExpress

Yet most of those companies decided to make native apps. If PWA’s were good enough, why bother writing native apps for Android?

Do you have a citation?

> PWA’s were good enough, why bother writing native apps for Android?

same reason people write native apps on iOS

It's easier to track users, especially those users rich enough to buy high end phones and that will probably spend more money and the ROI is higher.

They also make PWAS to gain user base on low end phones and emerging markets.

And because making them is quite cheap.

So most companies aren’t using PWAs to save money on Android and probably wouldn’t on iOS either....

Do you propose that Apple makes Safari more able to invade privacy?

If the only purpose of PWAs for Android is to make it easier to run on low end cheap phones - that’s really not a good argument is it with iOS is it? Even the 6s from 2015 is more performant than many mid range new Android phones.

Yes. I don’t want to press the “no” button for a 100 times.
You should lobby W3C to remove the API from the standard then.

Or ask browser vendors to have a global allow/deny flag for every Web API

I don't know if you're being sarcastic or not, but here's the thing:

I don't want websites asking me to enable notifications. 99.9% of the time, the answer is no.

I don't want websites asking me to enable location access. 99.9% of the time, the answer is NO.

Nor do I want them asking for permissions to install to my Home Screen (the answer is no), or to track me (the answer is NO).

>Or ask browser vendors to have a global allow/deny flag for every Web API

When possible, I've carefully configured my browser to automatically reject these requests, but instead of respecting that, these websites, with all their hubris, have chosen to circumvent my preferences by presenting shitty JS-based permission requests (as opposed to using the permissions UI built into the browser).

Each one of these new web APIs have significantly degraded my experience as an end user, by presenting a million permission dialogs whenever I'm visiting webpages, without providing me with any features of value (again, because I'm not ever, ever gonna trust some random website with these permissions).

Users don't care to pontificate about the virtues of the open web, they just want their stuff to work. And until the open web can provide a better user experience, of course users are going to flock to various walled gardens (App Stores, Facebook, etc...). Until we find a way to implement web standards elegantly, without degrading the user experience, the open web is always going to face an uphill battle over the relative safety of walled gardens.

I can relate.

Every time I pickup an old iOS device the stupid thing is nags me to update it, 100 times. And you can't just click no you have to click multiple things to get it to fuck off.

So, in practice, Apple vetting process doesn't even do what they say it does and still grabs 30% from developers?
Yes, absolutely! Just like I'd rather pay for Apple Arcade so that I don't have to wade through the sewage of free-to-play games clicking "no" on in-app purchase requests and hiding spammy notifications. Just like I'd rather pay for streaming services with no ads rather than having to mute commercials on live TV or skip commercials on DVR'd TV.

It's not absurd to me to pay for platforms that attempt to preemptively remove filth rather than need to be on the constant lookout for filth. This is particularly true when most of these entire ecosystems (the web, app stores, video content) seem to be based on sneaking filth in front of your eyes at every available opportunity.

Web notifications are a standard feature, meaning the APIs are in the web standard.

Making an hyperbole here, but wouldn't Mosaic 1993 edition solve every issue then?

Reasonable people can disagree about which features are and are not useful. And those reasonable people can purchase smartphones and computers which best cater to their own views about these features.
True, but reasonable people that know about web notifications API are less than 1% of Apple customers...
That sounds like a great reason to not let every trashy website in the world to spam them asking if they want to enable notifications.
But is it Apple's call?

I mean, removing features of course makes software more secure

I argue that disabling JavaScript would only bring great benefits to humanity

If Apple had a dominant market position in smartphones then one could argue that end customers don't have much of a choice, but Apple only has at most 50% market share in the US and much lower globally. For my own smartphone usage I would much rather Apple choosing which features and APIs that third-party developers (of apps and websites) can use rather than those developers being able to do whatever they want. I think it's pretty clear that developers tends to have a much more hostile relationship with their end users than Apple does with their customers.
The argument is not about market domination, but about money power

Apple market is rich, it is the richest tech company, with the highest market valuation ever, one cannot avoid it

So it's gonna drive adoption no matter what

Like it did for Flash (right or wrong, they did it)

I was writing web applications during the 90s, they were called intranets back then, IE wasn't bad, it was simply unavoidable

And being unavoidable halted competition for more than a decade

On another side: having a platform that doesn't obey to common standards creates tech segregation

I remember seeing japanes phones 20 years ago, they were ahead of time,but unusable outside of Japan

Last but not least, having a flag that says "allow me to shoot myself in the foot of I want to" it's less hostile than "you don't know what you're doing let me handle it for you"

So then write for all browsers, support what you can for each, and don’t promote Chrome anymore? If you continue to promote a one size fits all browser and the market moves that way then we’ll shortly be having this same discussion about Google. If you were writing websites in the 90s you should know this.
> So then write for all browsers, support what you can for each, and don’t promote Chrome anymore?

WOW

That escalated quickly

I never promoted Chrome, in fact I'm an old time Firefox users and in the 90s I owned a Netscape 3 gold license.

I don't write fronted software anymore, but writing for every browser means adhering to the standard

Apple has steered away more than any other vendor lately

So...

> I don't write fronted software anymore, but writing for every browser means adhering to the standard.

Yes, which you’ll find if you do Safari adheres to quite well. Finding examples where it doesn’t is easy, just like on chrome. Which is why we have media queries and poly fills because it’s simply impossible to have a unified platform without one entity owning it. If you found out Chrome doesn’t render the same on linux as it doesn’t on windows, would you call this not adhering to the standard?

> Yes, which you’ll find if you do Safari adheres to quite well

They don' t

Apple refused to implement 16 web API in Safari

> Which is why we have media queries and poly fills because it’s simply impossible to have a unified platform

And that' s why big players like Apple hat control a closed ecosystem shouldn't be allowed to be assholes

At least on Android I can install other browsers and other browser engines

Do you see the difference?

> Chrome doesn’t render the same on linux as it doesn’t on windows

that' s not true

Windows and Linux that have simply different font rendering engines and different native widgets

That's all

> would you call this not adhering to the standard?

absolutely NOT!

In no part of the standard rendering is formalized

It wouldn't make sense

The way things are rendered is standardized, not the way they should look

https://www.w3.org/TR/2014/REC-html5-20141028/rendering.html

> HTML is intended to apply to multiple media (it is a media-independent language). User agent implementors are encouraged to adapt the suggestions in this section to their target media.

> Apple refused to implement 16 web API in Safari

OK and these APIs don’t stop real work.

> And that' s why big players like Apple hat control a closed ecosystem shouldn't be allowed to be assholes

And putting all that power into the hands of a single browser will not end well, so stop promoting Chrome or saying other browsers should be like Chrome. FF isn’t going to win.

> At least on Android I can install other browsers and other browser engines Do you see the difference?

Yes, next question, do I care?

> that' s not true

100% true, read the dev blogs and understand the WM on linux is fundamentally different than windows or mac, therefore rendering is not exactly the same.

Standards help align, they do not force alignment. If safari implemented a p element as a span, then this is not following the spec. Choosing not to implement a portion of a modular spec, is still following the spec.

> But is it Apple's call?

Yes, just like you’re free to never visit an annoying website asking to spam notifications you’re free to take away Apple’s decision making power you grant them by simply not buying an iphone.

> you’re free to take away Apple’s decision making power you grant them by simply not buying an iphone.

That's a very common argument

But it doesn't get any less stupid with time.

I never owned an iPhone.

Because I am an adult homo sapiens that can take decisions for himself.

But you should know that if a standard exists, and the standard has been approved by a consortium, a consortium where Apple is a very important member, they should at least support what they signed for, instead of forcing developers to go through hoops just to support their platform.

When Elon Musk make Teslas he has to put airbags in them, stop lights, front lights, safety belts, they must pass crash tests, because that's the standard, otherwise he couldn't sell them as cars.

So if Apple believe that the standard that they approved is too dangerous, they can make their OS more secure, instead of putting the blame on developers.

Developers are not jumping through hoops to support their platform. I’m a full stack dev, I understand what it takes to support safari and a majority of the time is actually Chrome being fast and loose with the standard, not Apple. Is it a partial implementation, sure. But the features lacking don’t stop meaningful work at all. Just like hearing my statement is old, so is yours.
> Developers are not jumping through hoops to support their platform

They are

> I’m a full stack dev, I understand what it takes to support safari and a majority of the time is actually Chrome being fast and loose with the standard

I am as well, I understand a closed platform when I see one.

> But the features lacking don’t stop meaningful work at all.

If only it was true...

It' s not lacking, it has been removed on purpose.

The web engine Safari is built from already supports those features.

I can play this game too, Nope.
Nope, apparently you can't play the game.

You don't even understand the rules.

Sorry.

Notification APIs are in Webkit, the open source implementation of Safari.

proof: https://github.com/WebKit/webkit/blob/89c28d471fae35f1788a0f...

Can you prove that Apple didn't remove standard APIs from their browser?

So this somehow keeps other HTML from rendering and CSS just doesn’t display correctly right? Look around, you’ll find very little care for that API except from sites trying to spam devices, something apple is against. So again, no, safari is following the spec just fine.
Privacy concerns about Google and security updates at the mercy of terrible carriers.

But those reasons are weakening.

I totally agree. Apple is great for privacy - and that's important to me - but I'm slowly starting to think I might move to something else. Sadly, it seems my only real option is Android. I miss windows phone and blackberry.
I agree with those reasons, not sure my will is weakening, so I'll add: vendor versions of Android, the dreaded "Android" slowdown, and slower/choppier performance - generally - when comparing latest releases of hardware & software.
> and security updates at the mercy of terrible carriers.

Buy the hardware, install lineageos, insert SIM?

Is LineageOS the most trustworthy aftermarket smartphone OS out there? What makes it so?
Aren't I still bound by a GMail account for login and contact information, so if Google randomly decides to ban my account (see what happened to the viewers of a Markiplier stream), I'm in trouble?
How so? Lineage works without gapps, although obviously you then lose access to those services, including the Play Store.
I’ve never used LineageOS, I was asking. I didn’t see how you could completely separate Android and Google, especially for things like contact syncing.
Ah, okay. So the simplest case is that you just don't have those features through Google so you have to find another provider. For instance you can do contact sync through CardDAV courtesy of apps like https://www.davx5.com/, email with K-9 Mail, get apps from F-Droid, etc. Depending on exactly what the problem with Google is, you can also use unofficial software that still talks to Google services like https://microg.org/ instead of play services and newpipe instead of the official youtube app.
LineageOS comes with AOSP stock applications and you can install additional app stores on it. You can also install the google apps packages including play store and play services, but you don't have to. Of course many 3rd party apps rely on play services e.g. for payment.
It’s great, but you need a phone that’s popular with its developers.
> Why wouldn't you use Android then?

Frankly, because everyone I know uses iMessage.

Safari on macOS supports push notifications and it hasn't intrinsically been a bad thing -- at worst, I have to tell a web site "no, I don't want your notifications." They're opt-in rather than opt-out like native app notifications are. The higher prices you and I are paying aren't protecting us from "low-quality" notifications as it is, anyway.

At any rate, maybe you're so worried about single-page web apps being bad actors that you're happy Apple so severely hamstrings them, but I... just can't see a lot to worry about there. And if Apple let PWAs be even a little better on iOS than they are now, it would go at least some distance toward ameliorating complaints about the App Store.

>They're opt-in rather than opt-out like native app notifications are

Native iOS notifications are opt-in

Just a point of clarification: native app notifications on iOS are absolutely opt-in. If the app wants to send notifications it requires a dialogue and user confirmation.

Disappointingly, Apple makes an exception for their first party apps.

Thanks. It may be that the exception was stuck in my head. :)
This answer is wrong on so many levels...

I don't know why Apple is allowed to keep other browser engines out of their system, but probably just because the relevant people just don't understand that the Chrome/FF/etc. on iOS are just a Safari with a different UI and that it gives Apple about half (depending on country; in the US probably more) of the mobile browser share and users just the chance to either use Android or be stuck with Safari.

In addition, the author obviously doesn't know that the before mentioned push notification API is not just used for regular push notifications, but is also required for other use-cases like messengers for example.

Playing the devils advocate here. This browser restriction is what I'd wager is keeping the non-chromium browser market at a substantial proportion.
I am wondering what you are referring to with 'non-chromium' browser market. Typically people don't complain about chromium-based browsers, but about the dominance of Webkit-based browsers (Safari, Chrome, Opera, Edge, etc.) and from that perspective there is more or less just Firefox left.

Nevertheless, that is besides the point as the rendering engine is not the sole source of browser differences. I am not saying the Googles high market share isn't a problem itself, but that Apple is abusing their market position to hold back the development of the web (by not implementing relevant APIs and not allowing competing browser engines on their platform).

> Typically people don't complain about chromium-based browsers...

In my neck of the woods people most definitely do complain about Chrome, specifically the lack of privacy from being a Google product.

Yes. Including mobile WebKit users, there are enough non-chromium users to give devs incentive to support non-chromium browsers. Take away mobile WebKit and alternative browser usage dips into single digit percentages, which is low enough for many devs to readily disregard.

It’s a bit ironic, but browser engine monopoly on iOS is the only thing standing in the way of browser engine monopoly across all platforms.

Google nominally allows other browser engines on Android, but non-Chrome marketshare is a rounding error. There's not some great browser engine ecosystem out there, waiting to be unleashed.

The conversation is 100% about how much influence Apple should permit Google to have over the evolution of iOS.

Actually, since a year or so Firefox is a pretty solid mobile browser and I am pretty pissed I can't use the real thing on my iPhone.
> there is no - Add to homescreen dialog - Background sync - Proper push notifications

All of those sound like things that will be abused by the majority of developers the minute they are allowed to inflict them upon users, either willingly or commanded to by their overlords in the name of ""Engagement""

I have not seen these things abused yet. The user agent prevents it.
Of course you haven’t seen them abused yet, iOS doesn’t allow it. I remember developers abusing notifications in Android Cupcake.
I don't use iOS. I use only mobile and desktop OSes that allow these things. I still haven't seen them abused.
There are already countless websites abusing the web notifications API to push spam to end users. You're probably savvy enough to effortlessly avoid it, but the average end user often is not. We can't keep ignoring the the UX issues with a lot of these web APIs if we want them to be successful. Users don't care to philosophize about the open web, they just want their shit to work. That's what Apple iOS is providing them, and they will continue flocking to iOS until they're presented with a better alternative.
Reasonable implementations let users easily block the notifications after receiving them. It doesn't require much savviness.
I really have no idea what you mean by your comment, but humorously enough user agents are frequently one of the most widely abused parts of the browser.
The "User Agent" is the browser itself the header just how a "User Agent" identifies itself to the server. That language really only shows up in the RFCs though.
> Walled gardens hurt innovation a lot

How?

What do you even define as """innovation"""?

Honest question, I'd love to see some actual answers here instead of the usual canned hyperbole.

So far Apple's users are mostly satisfied with them, happily voting with their wallets, and the only people complaining about Apple are mostly the developers and companies who want unfettered access to iOS' users, and I haven't heard any good reasons from them other than "we want to maximize our own profits."

One example I saw cited recently is the Web browser itself. This is according to one of the original iPhone developers at Apple:

> Apple’s iOS rules would not have allowed for the invention of the web browser. Let that sink in. They would have rejected one of the most important technical innovations in the history of computing. Microsoft‘s bully tactic of making IE free seems quaint in comparison.

> But here’s the kicker: think of all the other amazing ideas that haven’t gotten a chance to be invented because they aren’t allowed on mobile devices. Mosaic happened less than 10 years after the Macintosh. We very well might have already had a browser-caliber invention by now.

> Just for people asking: the flagrant violations of AppStore policy that web browsers would be rejected for in this hypothetical are:

> 1) Running outside code

> 2) Allowing payments that circumvent Apple’s IAP

> 3) Allowing access to NSFW content

Source: https://twitter.com/tolmasky/status/1297199788316692480

More commentary: https://mjtsai.com/blog/2020/08/25/potential/

It’s hard to give specific examples about innovation that hasn’t happened, if only because not everyone is sufficiently innovative to come up with truly groundbreaking ideas.

I doubt any of the original Mosaic developers had any idea just how important their original innovation would become.

I get what you're saying, but right now, in the current state of the industry, here's the thing:

People are free to "innovate" and experiment and invent on Android and the PC, and if an innovation is deemed desirable on Apple's curated platform — which they are perfectly within their rights to control, and millions of users continue to be happy with that — then Apple will make a provision for it.

On iOS, there would be a whole host of problems with allowing third-party browser engines and app stores that the people clamoring for looser restrictions have yet to address:

https://news.ycombinator.com/item?id=24469664

Not the least of which is: How would you enforce a user's settings for privacy and parental controls on third-party browsers and app stores?

>hard to give specific examples about innovation that hasn’t happened

It's hard, but not because of prohibited innovation. It's because we have android, and it doesn't have neither ios rules nor a fantastic potential innovation that breaks the deal with apple. There is simply no example that could be used as a good enough argument. Apple users do not live in a vacuum as well, many of them have seen or used other platforms and still stick with ios as it is.

>iOS rules would not have allowed for the invention of the web browser. Let that sink in.

Web browser is a highly secure piece of software, protected on par or even harder than the os itself. If any ios app could freely download, compile and execute an arbitrary code from the internet, that would be a world-wide security and privacy disaster every few weeks. Let that sink in instead.

> Web browser is a highly secure piece of software, protected on par or even harder than the os itself. If any ios app could freely download, compile and execute an arbitrary code from the internet, that would be a world-wide security and privacy disaster every few weeks

It sounds like you’re saying iOS is insecure compared to WebKit and Blink, and that they can be trusted to run arbitrary code downloaded from arbitrary untrusted sources, but iOS cannot.

That’s a pretty damning indictment of the state of iOS, if it’s less capable of sandboxing than a browser, despite having tight coupling between hardware and software.

> Let that sink in instead.

Tragically, you’re probably right too.

It boggles my mind that a company makes a fairly innocuous decision (which you would expect consumers to punish them for) like requiring all web views to use the same renderer as Safari, and there are people like you rushing to have the government jump in and regulate "the kind of rendering for web pages that a private company allows on their devices". Seems like total insanity to me and I don't understand it.
> Seems like total insanity to me and I don't understand it.

They want to tear down Apple's defenses so they can feast unhindered upon the billions of users as they are rendered helpless.

Honestly, any entity that constantly cries foul about the high bars set up by Apple, makes me very wary of any product from that entity.

Apple does not own the device though.

If they own the device, then I want my 1k back.

Buyer beware? Were you under the impression whatsoever that you were buying 'free' hardware?
How could customers punish Apple for that, and that specifically? (I'm being careful with my wording to exclude the response of "switch to Android", because that is not a punishment for that thing specifically–the fact that people don't switch just means Android is worse to them, not that they agree with this particular part of the iOS.)
One way would be if major web apps launched and iOS users complained about being unable to use them. For example, Spotify Web Player launched without desktop Safari support. If macOS only had Safari, users might have complained and put pressure on Apple to change it.
Consumers in theory would punish Apple by not buying Apple products. But they don't and I can only guess why (they don't care about browser rendering engines).

If you're trying to narrow your punishment to be specifically "the crime of not letting me pick my own browser rendering engine" then I can't help you. This is not a hill I even remotely interested in dying on or spending more time on.

Kind of like Windows requiring all users to use IE?
Sorry, it's been a decade so I don't remember that whole thing. Were users required to use IE, or was it required to be installed? I remember using Chrome/FF/Opera on Windows for many years. You could swap to another browser for whatever browsing experience you wanted.
You can definitely add websites to your home screen on iOS.
I do this for Facebook to avoid summoning that demon on to my phone.
By "dialog", they likely mean an API with which to prompt the user to add it, like they have for apps on the App Store.
I think they're referring to PWA-style "Add to Homescreen", which I agree is a weak point of iOS/MobileSafari. I also wonder why there isn't good/any support for WASM in Safari.
Does android provide a way to launch this dialog from within the website?

iOS has a PWA-style add to home screen dialog, but it's part of Safari. It's accessed from the share sheet.

Oh please point me to the latest Web innovations that do something else other than track me or pester me with junk I don't need.
I fail to see the point, as far as I know Apple has been vocal about iOS since WWDC and typically releases the OS relatively quick after events. The beta's been out and available for every iOS developer for months in order to prepare for this.

There's enough to rib on Apple on, but this really doesn't seem like one?

Apple has always given one week to use the golden master tools and build to run final tests on and submit your applications so they can be out before a million people try to install it on iOS 14. If your iOS distribution person is out on a camping trip for a couple days, you’re not hitting the deadline anymore. If you live in certain parts of the world where you wake up 7 hours after the event and Xcode takes fifteen hours to download, your don’t hitting the deadline anymore. There is absolutely zero reason why Apple had to do this.
Unless your app is broken by the iOS update there's no more urgency to release an update than there is for point releases.
I am in a slightly uncomfortable position of being _fairly_ sure none of our apps were broken under iOS14beta6 last week, but still assumed I'd get the traditional week between the new xCode GM and users getting iOS14 pushed out to them.
Nit: last week’s release was beta 8.
(comment deleted)
The article does mention Apple normally provides at least 3-4 days of Golden Master availability and usually a week+ before General Availability and that this is useful for various reasons. A lot of these are ecosystem failing that developers work around normally, when given enough time. Since it doesn’t seem to provide enough detail maybe I can fill in some missing context.

The App Store submission process is tightly integrated with the Xcode version used to build the app, if you want to be ready before users upgrade the App Store needs to be updated at least a few days before users automatically get the update. The App Store being updated to allow builds from the new version of Xcode is the most important issue. That only happened after 2pm ET on the 15th, and I’ve seen report their had been some delay (thankfully I only had to verify existing builds and didn’t need to submit a new build today). This means even if you had your build completely done based on pre Golden Master beta, and can either quickly reverify it or are comfortable just throwing it out there, you could only actually submit it today. Review times even without back and forth over policy points can take multiple days. Things will be worse for users over the next couple days.

iOS betas are frequently quite noisy and variable, if you test against an early beta you will need to retest against the actual GM with potential backwards compatible breaks each time. If you are either unlikely to have bugs or have enough capacity to spike doing a lot of work within a week you have the option of only doing the expensive thorough verification work against a single release.

There are still many reasons why real device testing with the production IAP environment are necessary. This is mostly a failure on Apple’s part to ever update their test environment’s capabilities and achieve parity with production. Doing this early requires you to be able to afford and have extra hardware of spend extra time having to upgrade and downgrade OS versions in order to verify the new version and continue to support live production hot fixes and support. A week between GM and GA is in the Goldilocks zone for developers, so that if they’re not doing a huge release to correspond with the iOS version they can upgrade test devices once, do one chunk of testing and fixing issues, and have their own build which will happily support both the old and new OS reviewer and live before users actually get the new OS.

Apple greatest asset is the accessibility to a large market. In return to the loyalty of the clients they do an excellent work in validating apps for isolation, privacy and vetting. Technology is not magic and bugs exist, so Apple chose this methodology for their store.

If companies are able to hijack this process by uploading assets it could be easy to exploit.

We are talking about a personal phone not a remote computer. Imagine if hackers got free reign in the private information of key political figures ?

I choose privacy thank you very much.

Privacy and user freedom are not two mutually exclusive things. You can have both at the same time too.
This comment doesn't seem to have anything to do with the article, which is about the short launch window for iOS 14 and issues surrounding that. Are you simply reacting to the title?
Just trying to give the context of why Apple is so protective to the App Store and why these lead them to do some unreasonable decisions.

I wanted to break the preconception that software is just inherently secure. If anything it's super brittle and the continuous delivery cycle has its downsides.

That has absolutely nothing to do with why they would depart from their usual reliable release cycle and force developers to scramble to update their apps for iOS 14.
Why are people constantly personifying corporations? All you're going to end up with is a sociopath as that's what large companies are when you try to do that.

Apple isn't a single person with evil intentions that thought: "let's make it very hard to work with this stuff", even if it might seem that way. It's far more likely that:

- The alternative was worse

- An internal policy or rule had unforeseen side-effects in planning or releasing

- The team doing the work on the release and the team doing relations aren't the same team and didn't communicate properly

- A deadline was set and because it was only met just barely you get an odd release schedule

Does that mean that this release is a fun planned schedule? No. But it doesn't mean the thousands of people working there are combined into one big person that wants to do bad things to you.

> Why are people constantly personifying corporations?

Because corporations aren't democratic, so their policies are not the sum of all employees working there's opinions. Most of it is the result of top-down decisions, which in practice are made by fewer than 20 people: the board and the CEO. Technically, we could add shareholders to that list, but IIRC they barely exercise their right to vote. What's more: corporations as legal entities specifically exist to limit liability for the aforementioned people.

So when "Facebook" doesn't care about your privacy, it's Zuck and the board that don't, not individual developers. When "Shell" sponsors climate change denial, it's the board, not someone pumping your gas deciding. The personification is valid up to a point because the corporation as such is only a (useful) fictional construct.

> It's far more likely that [...]

I don't know the broader history of Apple's behaviour towards developers since I'm not an iOS developer, so I can't say whether this is a matter of policy or a snafu. Based on what I know, I'd also lean towards incompetence and not malice in this particular case.

Web Web web, fuck native apps.
Web is great for a lot of things. But not games, especially if you want efficiency.
Or things like real time audio processing, AR or on device ML. Anything thats not a JSON viewer or CRUD app basically.
I think that is a very pessimistic view of what you actually can achieve in a browser! With web assembly a lot of those things actually are very possible today.
web will never become as fast as native apps. it's the model. until that one is changed this will always be a fact.
Sure that is true, but it is fast enough for many apps already and will be even faster in the future or do you really argue that most native apps on Apple Store couldn't be done as a web app?
Yes, you're right. actually not most, but more close to 95% of them apps could be done as web instead. Yet, on mission critical apps while they can be done as web apps, the decision to make them native it's not a choice, is a must.
If SpaceX can have a web app for their astronauts, I think so can you even if it's "mission critical". I just don't see any argument why a web app cannot be mission critical and work just as fine as a native app would.

Ok if you make an AAA-game title with extreme need of performance or if you make a database engine or something. This is however a very tiny minority of apps with extreme performance needs but again probably 99% of the apps on the appstore doesn't have those requirements and could be done as a web app.

I understand why you don't want code running medical equipment be dependant on some garbage collection or whatever, but no one is saying that we should use javascript for your heart monitoring equipment, unless it can fail and it won't kill you or hurt you physically.

OK then, let me tell you an example, since you can't see any argument.

I have this client, it's an Arkansas truck company that is hauling cargo all over US. So a few years ago they decided to ease the way, and also double check on their drivers, of how cargo is delivered. To optimize routes (fuel economy), to make it easier for drivers to enter/use data in the system, stuff like that. So they decided to give them drivers work smartphones, GPS enabled always with location reported through Google services. And a custom app that would use them features to run on said smartphone which would connect back to their server and interact with the central DB there. Server on AWS, back-end there, client app on smartphone - classic programming job, OK? So they hire a developer who was just like you "if it can be a web app then should be a web app" that caught their eyes with "look how nice works on any device or any operating system since is a web app" kind of argument. Job done, and they started to use the new system. In the beginning everything went fine, then client wanted more features. Add reports, add logging errors, add more contracts in the system that drivers show/sign with their cargo clients, notification if a nearby new customer pop-ed up in the system so the truck driver takes a little detour - stuff like that. And of course the aforementioned web developer delivered. Implemented all them features over the course of next couple years.

And then problems started to creep-up. More and more features, means more and more power was drawn from the phone battery. Have you ever seen a company that seek to reduce their operating costs give expensive with long battery life smartphones to their employees? Because I never seen one. So them phones had to be plugged into charges more often, battery cycle was shorter, also plenty of batteries don't like to be charged on short many cycles throughout the day or otherwise they start to swell, best case scenario, or to even explode (worst case scenario). So the company started to experience problems with smartphones, their drivers complained a lot about how when the smartphone was hot after charging the app was sometime unresponsive so they had to wait for the phone 5 minutes to coll off, time which added to their operational costs. Tell me, how do you think truck drivers are? University graduates who have a lot of tech understanding or simple folks trying to make a buck for their family and are tech illiterate? Because in my experience they are 99% of the time the latter rather than former.

What was "mission critical" (as you like to mock it)? Get an app running on an inexpensive phone, used by tech illiterate humans that definitely will use it wrong, to lower the company costs without hiccups!! Did the web app achieved that? Absolutely not, made it worse actually.

My solution? Get rid of GPS crap from smartphone, move that as a microservice running on a Raspberry Pi, which also had attached a LoRa module, phone would connect to RPi's access point only. RPi would also have a GSM dongle to connect to internet and always stay in the truck's cabin plugged in. Let's see running costs. RPi is 15 USD, LoRa is 5 USD, GSM dongle another 10 USD. Total cost for the rest of their life a grand total of 30 USD. Do you know how much is a battery replacement? Average of 40 USD, if you manage to find the battery model, otherwise you need to replace the entire phone. So which one is better? 40 USD every 6 months or 30 USD one time payment? Now multiply that with 300 trucks.

I made all of them native apps as native apps are also draining less battery, turned off all Google location services, GPS, notifications services and implemented my notification service instead, pushed from RPi's local server to phone's app. Back to charge the phone only once per day.

Funny thing. As a side effect of my implementation they made a bunch of their clients happy. See some of them are mining operations, and sometime the boss of th...

> So they hire a developer who was just like you "if it can be a web app then should be a web app"

I can see arguments and I am not like that, you're portraying your predisposed view about me onto me.

This argument you have is not really saying a lot to me actually since you could use Rpis with a web app as well? Tbh I don't think you save that much battery on just making it native. You complain about battery, but fail to mention that Android phones needs to be switched to be able to use the newest api:s in android development. So if you want to use new shit, your client needs to update their phones, something they would not have to do if it were a web app. But in your case, I would probably also have made a native app but that app you built don't really describe how most apps are. You are talking about an exception to the rule IMO.

I can give you a pretty similar counter example:

I worked for a client once that made a newspaper. This client has a list with all shops, kiosks etc that sell their newspaper in a database. To save fuel and to be efficient, they used an old Java Swing application that would every day calculate the most efficient route for each driver. It did a lot of other stuff as well, but that isn't important for the story. The app was fine, it was just a pain to develop and release. Because it was still actively developed. In every release, a jar file had to be distributed to each user of the app since there was no good way of auto updating the app since it was so old. Any way, the users of the java swing application would run the calculation functionality and it would give a result that was printed out and given to the drivers.

What happened later was that the app was remade and presented in a web page. Each driver didn't have to wait for a paper printout of the result of the java swing app, they could simply open their phone, visit a specific url and see their route for that day. There was nothing to install for each driver, since drivers was often changed, no need to wait for some guy that had to print out a paper for them and everything was basically automated.

The benefit here of a web app was great, since as you say truck drivers aren't the most tech literate people in the world, managing a native app here would be a great pain.

So what can we learn from our examples? That the needs are different. I get that. I never said every app should be a web app. But if you can make it a web app, you probably should at least consider it. The benefits usually outweighs any negatives. My entire point was never to not make native apps, it was to avoid them if possible.

Let's agree to disagree. And frankly I love people with love for hypes and technologies that bullshit their clients into adopting that. It means I get to do this type of work, which I call "cleanup jobs" that bring me the big bucks.
Since when is doing stuff for an open standard that will have backwards compability for likely decades following a hype? The hype technologies is imo android and ios apps. They will only work for a few years and soon enough their UI will look so ugly because of the hundred times Google or Apple has revamped their entire UX so they deprecate all apps that don't update SDK version.

Then, the clients have to replace their devices because otherwise they can't run the new app versions. This is literally a hype.

I on the other hand dont use any big frameworks, I just do web apps after the open standard that everyone agreed upon. You're a slave for whatever platform you develop for.

In 10 years when people run iPhone 50 my apps will still work as they do today or probably better due to better hardware. Can you really say the same of yours, given no updates are made?

The main thing to note here is that the moment you offloaded some of the work off of the phone, the comparison stopped being apples-to-oranges. It'd be interesting to see how PWA vs native app would compare against each other (both performing the same work).
My job as a freelancer is to view the bigger picture of the client. Then discuss things and see what's the best course of action. Hardware, software, operating systems - all these are irrelevant. You advice your client to his needs, not to your " I like web apps so this has to be a web app". So in this particular case the phone had to be unloaded and that's exactly what I did.
But it's not always about if it's possible. I think we can even take a step back here and not look at performance critical apps to begin with, there are a whole host of successful native iOS apps on the App Store, making money that could be replicated as web apps with todays tech and added to the home screen, even on iOS Safari, yet these native apps keep getting built and sold. Why is that?
None of that matters for smartphones. The use case for a smartphone is basically a portable browser.
The use case for your smartphone? plenty of people want to do different things with their phone and plenty of developers are interested in building those niche apps for them. I think it still remains to be seen if the web is the right fit for some of these tasks, with WASM we might eventually bridge that gap, but not right now.
> But not games, especially if you want efficiency

Well, it's not great for games anymore.

There was a golden age of gaming on the web, 10 years ago. But, for some reason, platform/phone/browser owners intentionally killed the tools that made this golden age of gaming in the browser possible.

WebGL 2.0 => castrated OpenGL 3.0. ES

WebGPU => To be done, will be a castrated Vulkan/Metal/DX 12.

native => OpenGL 4.6, OpenGL 3.2 ES, Metal, Vulkan 1.x, DX 12 Ultimate,...

More to the point: Apple refuses to support WebGL 2.0, as they want to actively cripple the web, not just castrate it, so even if your app would work fine with it, you can't use it.
Apple added a commit to WebKit enabling WebGL 2 by default two days ago, which I assume means it’ll roll out in the next couple releases. Now, I think it’s still buggy in some places (I’ll check tomorrow to see if any improvements were made in ToT vs my iPad) but it is there and they support it.
Update: I tried a bunch of things on noclip.website and ShaderToy (which never seemed to work properly before) and they seem to be largely functional.
Yeah so lets continue throwing money on a company that actively prohibits you as a developer to actually make your game for the web. /s

By giving money to apple and by continue to build for their platform only ensures that this will remain true in the future as well.

All companies doing Web browsers and Khronos are the ones to blame that 3D on the Web is castrated.
The web offers you the same API on every OS. Meanwhile native applications probably have to use whatever the OS provides, forcing you to support multiple APIs.
Except not, because browsers enjoy black listing GPUs, so while in native you get 3D performance no matter what, on the Web it might just run with software rendering using single digit FPS.

Then each browser is a different species, unless you adhere to the ChromeOS === Web school of thought.

Apple will not blacklist their own GPUs in WebKit.
That doesn't change the fact that everyone else does it, thus Web browser 3D gaming remains at the level of basic Flash alike games.
I thought App developers would be testing against the beta version? I don't really understand the problem. There's public beta's, it's out of beta, and will go to the public tomorrow, apps will continue to work.
You cannot submit you application except using the toolchain that was released today, which is occasionally different enough from the beta tools that your app will no longer work. So now you have a broken app and just hours to fix it, and then somehow App Review is going to get through it while a thousand other people are submitting at the same time you are? No way.
Well you can always ship updates with the old iOS 13 SDK toolchain (Xcode 11) the entire time. You could have tested on the iOS 14 betas, and if you found a crash, you could try to implement a workaround and resubmit in the weeks and months leading up to today.

Sometimes your crash is because of bad assumptions in your code, or sometimes your crash is due to real Apple bugs creeping into the iOS APIs. Not saying it's always possible to implement a workaround, but it's not as bad as the blog post makes it out to be.

That is correct. But I know for many apps building for iOS 14 is a requirement or bad things will happen™.
Care to elaborate? Did Apple break backwards compatibility with apps built on the iOS 13 SDK with no way to work around it? Seems hard to believe that everyone upgrading to iOS 14 will end up with no functional third party apps today?
Apple does a lot of weird "quirks mode"-like BS by checking for what version of a library or toolchain was linked against at build time (and with multiple kinds of checks, which is annoying). I absolutely have experienced cases numerous times where my app was fine if it just was allowed to run, but Apple insisted "no, this app was compiled against an iOS SDK so it should get a shitty and broken simulation of the older skeuomorphic properties panel, and should do some ridiculous reverse display scaling on this new iPad we just released"... and to be clear that this is merely the quirks mode BS, my solution finally to not have to keep updating my copy of Xcode was to get angry and write a tool to edit my binaries and update their load command version references. I have no clue what Apple thinks they are accomplishing with these checks.
> to be clear that this is merely the quirks mode

Most of the problems I hear this year are not the compatibility checks that Apple had out in but UIKit just being broken for certain things. The difference being of course that “compatibility quirks” is Apple knowingly trying to fix something and doing a poor job as opposed to what’s happening here where they just changed random stuff and thought it was compatible but it the observed behavior is now different and breaks apps. For example, I have a bog-standard navigation bar that’s been broken since iOS 13 (if I build for that SDK) because Apple evidently thinks that they did their implementation correctly but somehow the way I have put my table view in a navigation view in a tab view (real complicated, I know) is something they couldn’t keep consistent.

One example is the new photos permission API. If you don't rebuild for iOS 14, your app will continue to work... but your users get a horrendous experience where they're presented with a confusing permissions popup every time they launch your app.

I'm sure there are other examples as well.

> Well you can always ship updates with the old iOS 13 SDK toolchain (Xcode 11) the entire time. You could have tested on the iOS 14 betas, and if you found a crash, you could try to implement a workaround and resubmit in the weeks and months leading up to today.

When I was an iOS developer, this is exactly what I did. Install iOS beta, find any show stopper bugs, fix them in the current SDK and get the bug fix out. Most of the time it was just the beta OS highlighting an existing bug that the current OS ignored.

Once the bugs are fixed, then start adding beta OS features. These features often have to be gated anyway since it's normal to want to support current version -1 or -2.

So yeah, Apple should have given more than a day, but it's not nearly as serious as the hot takes want to make it out to be.

deleted
Yep, I do, although thankfully I’m not affected. But I assure you that there are apps that will be in a tight spot here (particularly ones that use SwiftUI, which has been notoriously buggy and prone to changed across beta releases). Some things can only be fixed using the GM. And sometimes new issues crop up in the new iOS build!
Can confirm that visual bugs not present in SwiftUI in the early betas popped up in some of the later ones. Something to do with grouped list styles.
> The next major release of iOS is announced to be shipping on Friday (in a few days) or sometime the following week, like the next Tuesday.

> But today, Apple announced that iOS 14 is shipping tomorrow.

So... the only difference is it's not "few days" but "one day"? For an OS update everyone knew was coming because "for as long as I can remember it goes something like this"?

What's the assholery?

I think they mean that the developers usually get development version of the OS to install into their build system and test if anything is broken or add new features for that OS which gives them an advantage over competition and reduces random uninstalls.
No one said you HAVE to update your app to iOS14 on day 1. Also, the beta versions have been out for months. If you’re not ready, it’s your fault.
If you’re not out on day 1 and your app has more than a few users, expect bad reviews and bug reports. The beta being out for months doesn’t change the fact that you have something like 15 hours to build and submit your app and hope it gets through review.
You can’t build against the latest version until Xcode is released and Apple enables submissions of the latest apps.

That was done after the announcement

The profane language really isn’t necessary. It would be helpful to understand what portion of apps are negatively impacted by the new iOS version. If it’s insignificant, there’s really no strong incentive for Apple to specifically set a launch date with developers.

It’s besides the point by the profanity just weakens the argument. Presumably the iOS beta has been out long enough that developers could have pushed out an update if their app seriously breaks with the update.

Yeah it's fucking bullshit.
> there’s really no strong incentive for Apple to specifically set a launch date with developers

Except that they used to do it a week later every year? And that there is no reason to release it tomorrow, like new hardware that ships with that pre-installed?

> Presumably the iOS beta has been out long enough that developers could have pushed out an update if their app seriously breaks with the update.

You can’t push out an update for the new OS except using the blessed toolchain that Apple released today. That’s what we’re annoyed about, not that the beta period was too short.

> The profane language really isn’t necessary.

No one cares, boomer.

People have different opinions on the use of profanity. It's a language tool, like any other, and I find in my use of it, it expresses sentiment quite clearly, whether that be humour or frustration.

The article is the author's speech, it is their choice to use or not use language tools as they desire, but I ask you this. How would you title the article while maintaining the clear and concise form?

I don't believe profanity does weaken the argument, it shows that people (developers) are getting beyond the point of being able to maintain their decorum because of the sheer frustration at the arbitrary rules and actions from a company who's trillions are made, in a no insignificant part on the backs of others' work.

I’ll counter your question with a question of my own. How would you title a document at your work that’s trying to convey that some process or practice doesn’t help customers and burns trust?

I’m not saying we need the same decorum in personal writing. But I am stating there’s another way to make the argument.

Of course we write professionally at work. But that's work, and there is a level of bullshit required in all professional writing, because that is what is required.

This isn't work, this is a personal blog, where someone is clearly and concisely expressing how many people feel using language that many people can relate to.

I'm sure many have made the same argument before, and many feel the same way about Apple and its tactics, however, this one is ranking high on HN right now because it has a title which clicks with people's frustration. Apple's being an "asshole", there's no need to mince words.

Man, don't you understand that you are not allowed to critize Apple here. Don't touch my walled garden and (fake) privacy.

iOS 14 has introduced home screen widgets, it is a game-changer man, it has only been on Android for like 7 years :)

> Man, don't you understand that you are not allowed to critize Apple here. Don't touch my walled garden and (fake) privacy.

The community here over the last few months and prominent people in the Apple developer community itself have been very critical of Apple and their behaviour lately, so I don't feel as if this holds true.

His downvoted comment would say otherwise. For comparison, FB might have done more harm, so I guess one might expect it but just notice the difference between the near unanimous dislike for FB compared to divide in criticism of Apple. Out of FAANG, only Netflix might have higher positivity around them in HN.
I felt the downvoting was more in response to the comment itself sort of missing the point and coming off a bit tone deaf. I agree with your point though.
He is downvoted because his comment isn't useful or encouraging healthy debate, not to mention its tone and spelling mistake. It reads like a snarky, angry man posting irrationally late at night.
Is Apple moving to a model where all the apps that matter come from Apple?
probably. And I like that, it means they will finally become the true vertical company they wanted from beginning. Meaning they'll lose all developers and become a niche company.

Meanwhile what I really want to see in developers world is the same in cellphone area as is in PC area. Freedom of choice of what OS to put on my phone. On PC I can have HDD partitions and install Win/Lin/Mac all in the same hardware. This is my dream.

There are x86 tablets that dual-boot Android and Windows. Pretty sure now that Windows runs on ARM there would be similar devices that do the same on ARM.
I know they are. But my point is about that currently any PC, be it desktop or laptop has that possibility right from the start. And I do mean any. Actually is even better then any current. It's close to any in past 5 years at least can do this. Can you say the same for smartphones/tablets?
I mean, why should developers get 70% of the money, right? /s
Maybe.

Personally on macOS or iOS I rarely use any of Apple's apps but I imagine I'm in the minority.

I've been using the betas, and haven't had any problems with the apps.

What patches are required for apps to work on iOS 14?

If you use some sort of thing that the new privacy things will block you need to update to account for the new behavior. If you have new features you want users to have you need to build with the new SDK. If you have fixes for your app being broken (either because of you or Apple’s bugs) you need to fix them.
> If you use some sort of thing that the new privacy things will block you need to update to account for the new behavior.

I am not shedding a tear for the producers of the apps that used privacy invading code all the time, and didn't stop since iOS betas exist, waiting instead for "official iOS 14" to "do something" -- which is probably forcing the user to agree or not use the app.

I hope I'm wrong, and to accept that I'd need a specific example.

Having only ~24 hours to submit a fix for your app, or risk negative reviews from disgruntled users ... is pretty shitty though.

Apparently developers are unable to do this during the betas.

One of my apps, Black Highlighter [0], uses the photo library permissions to display your library to actually pick a image to edit in the app, and also to write your edited images back to the library. This is the main functionality of the app, and it's what people want to be able to do. I'm not doing anything nefarious with people's images, I'm just… building an image editor. Can I use other methods to let people pick an image? Sure. But until iOS 14, they were a demonstrably worse experience. Even still, it's a bit odd, because the initial screen of the app becomes a big blank view with a button to display the system photo picker.

I did my due diligence and I added a new button to use the new iOS 14 system photo picker months ago, when Apple first announced these changes. But until today at 11am, I could not ship those changes. Period. Nothing I could do to have a version available for users any time before today. In under 24 hours, I have to update my CI system, generate a build, check to make sure nothing broke, submit for App Review, and hope I get approved.

But wait! I also have two other apps that have iOS 14 functionality. So I've got to do those as well. And these are just my side projects. I have a day job, doing the same kind of work. And I'm the iOS CI "guru" there, so I've got to do the exact same thing… make sure Xcode 12 is updated on all our build agents, get actual builds out of them, submit to the store, etc.

All of the privacy work is done. It's been done. But the difference between ≈24 hours to get final builds out the door and a week to get final builds out the door is huge when you've got multiple different projects to handle. Especially when App Review is eating several of those hours all on its own.

So guess what? My projects are going to fall by the wayside, in favor of my day job. Is it a big deal? Who knows. Maybe I'll get some bad reviews. That'll suck a lot. Did it need to be this way? Absolutely not. Apple could have given us the week that they normally do, and everything would have been fine. Instead, they gave us a day, and that's just not enough time. So apps people use and like are just going to be broken for a few days, and there's not a thing developers can do about it.

###

[0]: https://blackhighlighter.app

Sorry, I still don’t understand why you believe that you has to ship an app using new features in 24 hours if your app worked even without using them all this time? Did I understand that the existing picker worked and will work in your case? So where that 24 hour pressure comes from in your case? I didn‘t understand that your app built with the tools for 13 would be broken on 14? And if it would be, why?
That’s thing it wouldn’t work. It would have broken permissions and would never be able to properly function. Just like the location api changes etc. If try to launch an ios11 app like Instagram in ios14 it would be completely useless and nonfunctional because of just permission api changes. Not to mention any of the million other things Apple changes. So ya that’s this 24 hours is a crunch because even if 15% update the first day that’s 150+ Million Devices.
This article is missing the best part, that the new Xcode you have to use to build your app was released today at 11 AM, with a build number of ‘208. It was a really strange build in that it was missing components to build for Apple silicon: for that you need to use the old beta, which Apple has kept up on their website so you can juggle both. But that’s not all! Soon afterwards they changed the website saying the new Xcode was actually build ’209. Around this time people had finished downloading the update, which was slow because everyone was freaking out about getting their app ready in time and grabbing it at the same time, and they realized that Xcode wouldn’t let them upload their updates. So everyone thought that of course build ‘209 was the right thing to get so they hit the website again to download the file…except Apple doesn’t do checksums, obviously, they do a really slow verification thing that every iOS developer hates with a passion and gives no useful information. In this case manually running the checksums told everyone that while Apple had updated the version they claimed to be have on their website, everyone was still getting build 208 and this build could not be used to submit updates. Then, later in the afternoon, Apple flipped the switch to allow build ‘208 to submit updates (which now need to go through review…). But that’s not all! In the evening at around 7 people started getting a different Xcode, the actual build ‘209 they claimed there were distributing all along…and now every developer is stuck with the decision of whether they should pull their old binary they uploaded and recompile with build ‘209 (as there are many differences between the two, based on a diff -r) or wing it. Totally uncool, totally unnecessary. If anything the blog post is not strongly worded enough about how much of a affront this is to developers.

Edit: and guess what, if Apple didn’t have advance notice of this do you think their own build process could have handled it? I’d bet money on “no”. XBS takes hours itself to spin up a new build, and with the usual testing a validation you see even the fastest updates taking at least a day. Back in iOS 7 it took them two to get critical fixes out the door, and patching the unc0ver 0-day took like a week for reference.

> iOS developer hates with a passion and gives no useful information

That's typical Apple, they are allergic to technical info and error display, when things are not working, there's no way to know why.

All in the name of UI cleanliness and simplicity. Like how there's no way to manually trigger the firmware update for the AirPods. You just have to keep them plugged in next to your iPhone and ... wait ... until some magic pixie in Apple's cloud decides it's time to push the update to you.

Steve Jobs used to say it over and over again when criticized by angry developers[1] that their main focus will always be users instead of developers and that the latter will just have to suck it up if they want to get a piece of the lucrative Apple user base pie.

In comedic contrast, here's a sweaty Steve Balmer shouting "Developers!" for half a minute.[2]

Ah, the early 2000's, with Apple and Microsoft battling it out, what a time to be alive.

[1]https://www.youtube.com/watch?v=oeqPrUmVz-o

[2]https://www.youtube.com/watch?v=Vhh_GeBPOhs

Yeah, I guess some people decided that technical errors helping you to find what is going on are "ugly".
Mac/iOS error: App just disappears

Android error: App displays error and disappears

Windows error: App displays error, possibly writes to error log, dumps memory to disk, and suggests you visit a URL that provides no useful information.

None of them are great, but at least Windows gives you something to search for.

EDIT: Formatting

On Android, if you tap the button to report the error, it will show you a stack trace and other information that are often enough to diagnose crashes in third party apps.
Crash logs are available on iOS in the settings.
Yeah agree, and I'd say it's better to hide them away in settings because most users have no idea what those error messages mean.

For example my auntie calling me in tears because windows "had performed an illegal operation" (verbatim error message text) and she was terrified she was going to prison.

Stongly disagree, as much as this example is hilarious and toching, it really isn't typical.

Many non-dev folks around me have resolved windows errors by typing the error message or code into google - if they are spesific and well written, they enable you to do that!

Strongly agree with you. When Apple things fails to 'just work' it is a nightmare. I used to have this issue for downloading MacOS updates. My internet wasn't too fast and it would get interrupted and restart from zero. Who can't do download resume in the last 10 years, I would assume only apple. My office network was faster and we also had those cache server, it worked for everyone except me. MacOS provided zero hint and it 'just failed to work'. Office internet was fast enough to download in multi MB/s yet Apple update weeks after released (so I don't think there was rush and it was US night) would have speeds 50 KB/s to < 500 KB/s and of course you can't choose a mirror or whatever cause it 's meant to 'just work'.

This is just one example that I vividly recall. The simplest of operation downloading of an update, only apple can make it as big a nightmare as it was. Now they do a lot of things fabulously but when the fail they just fall on their face and ignore it or they would fail where I can't even imagine how to fail this bad.

The latest blunder (again download), my iPhone lost it's wifi after a fall and wow! behold you can't download an update over cellular. Apple will make you save your money by not using your expensive cellular data after all it's so much more expensive than your $800 phone.

A lot of people seemingly don't have the patience or knowledge to do this, unfortunately :( I know people sneer about "computer classes", but I think it would be very useful to have people learn to try to solve their problems by themselves.
Windows even offers to resolve the issue which, as I understand it, has never in the history of time resolved anything.
The only time it did something for me was when the network diagnostic tool requested a new dhcp lease because I “did not have Internet access.”
In Windows 8.1, if the Sound service crashes, clicking on the sound icon with an (X) on it will bring up a UAC prompt. Going through that will get the "resolve the issue" prompt to restart the Sound service, which will fix the issue.

Not having the problem in the first place would be better. Automatically solving the problem would be great! But, for once ever, I can safely say that this does sometimes fix problems.

Why use windows 8.1 today? Windows 10 was a free upgrade and a major improvement.
Windows 8.1 works, uses significantly less RAM, lets you disable the telemetry, lets you create new users without a Microsoft account, doesn't move things around all the time, has a non-Chromium-based browser built into it, doesn't automatically install Metro apps…

The only real downsides versus Windows 10 are the Start Screen and the conhost implementation, but Classic Shell and Powershell fix both of those.

Windows has been getting worse and worse at this as it increasingly follows the bone-headed trends started by Apple and shitty web designers.
Seems about the same as always. Either Windows is working, or you get a blue screen that says ":( Error code: WE_AUTO_INSTALLED_A_SHITTY_DRIVER_FOR_HARDWARE_YOU_DONT_CARE_ABOUT_AND_IT_OVERWROTE_THE_OS'S_MEMORY"

Then you google it and the first 300 results say you need to install their malware to fix the problem. Never change, Internet... never change.

On the Mac you get a crash dialog with a report button that can show a detailed crash report with a stack trace. Much more useful than Windows errors. Like I used to have a series of Safari crashes where the stack trace clearly showed it was a Unicode bug
macOS has an option to show detailed crash reports, which can be more detailed than Windows' crash alerts, along with a field for describing what you were doing or attempting to do.

See TinkerTool for an easy way to enable such options:

https://www.bresink.com/osx/TinkerTool.html

Over here on Windows side not everything is "Developers!" as it should be though.
True, but I can still run my program that I compiled back in 1999.
you also have largely the same OS and hardware architecture that you did in 1999
You make it sound like it's a bad thing.

My company can build and maintain a really big program with a minimal number of developers because Windows is so backwards-compatible. No need to rebuild everything every 3 years because APIs changed or some framework got deprecated. It's just running and running and running on our customer's hardware.

Modern Linux kernels can also run binaries compiled in the 90s. Apple just doesn't care.
Sure, if they're statically compiled with no non-kernel dependencies whatsoever. Once Linux userspace gets involved it is a shitshow.
Right. Most Linux user space software actually subscribes to the Apple philosophy of breaking everything in the name of progress. From what I've read, even GNU rejects binary compatibility concerns because to do otherwise would help proprietary software, sometimes resulting in breakages in vital stuff like glibc.

> statically compiled with no non-kernel dependencies whatsoever

I'd love that. Would be great if we could even get rid of the C library. Compilers should emit Linux system call code directly.

This makes fixable library bugs more or less impossible to fix.

Look at how many DLLs get updated in a typical windows security update.

Most of those would have been permanent security vulnerabilities if everything was statically linked.

That shouldn't happen assuming the Linux distribution maintainers update everything whenever a library gets fixed. I agree that dynamic linking produces significantly less work for maintainers.
Microsoft takes backward-compatibility as seriously as Apple takes product aesthetics.
I wish there was a bit more of that on the Win32/UWP reboot (Project Reunion, WinUI 3), .NET unification, C++/CX replacement.
I think Microsoft is at the point we're the old guard is leaving and the new hip kids take over who mostly only plugged libraries together because they never needed to write assembly.

Maybe the knowledge of how to make backwards compatible systems is even slowly leaving with the old guard and they just will never know how to make it work ever again.

A colleague of mine is very active in Microsoft's GitHub repos and is complaining daily that no employee there seems to know how their own software works. He routinely needs to explain Microsoft employees that their ideas will not work because of $generic_windows_api_behavior.

Yeah these whipper snappers can't possibly pick up c and assembly. Only boomers and gen x can do that.
Knowledge can be lost. There is a stark difference between using a tool and mastering a tool. It's even harder for theoretical knowledge. Don't use it, lose it.

Look at the US space program for example. It took them 12 years from the first man in space to go to the moon. Nowadays Space X, Blue Origin etc. seem to have to re-learn everthing and edge themselves slowly towards launching manned missions. They very likely have the books about space flight but not much experience.

I'm not saying that young people don't know assembly and C. What I'm saying is that most younger people don't need assembly and C, so they are a lot less proficient in it. Hardware has become so fast, it doesn't matter that JavaScript is 20x times slower, so people nowadays write entire desktop programs in JavaScript that are slow on not-cutting-edge hardware and have bad OS integration.

I read a good article years ago about microsoft and philosophical struggles with backwards compatibility.

Here was an interesting bit:

> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

No offense, but I can still "roll my own" desktop with Linux and Windows, replacing components out as needed. I understand that this sounds like some technical hurdle to many, but it also feels like a cause to the rising hardware illiteracy of the average citizen.

I might be conflating causation and correlation, admittedly. I've always enjoyed the hardware aspect of computers, so it's hard to look at this sort of thing completely objectively.

You know, apple did a really good job on this in the past - with rosetta to emulate PPC when the first intel macs came out.

It's too bad they just don't make VM stuff available, and make it available for a long time.

Yes it might be only nostalgia, but why don't they have something simple like dosbox for macos that would run mac classic apps or recent stuff.

I guess you just have to keep your old systems around

Lol what hardware do you think apple uses? ARM and Intel/AMD are all ancient designs with improvements bolted on.
Macs only just work, don't expect much else.
Until they don't, or put your display to eternal sleep with no way to ever wake up, or...
I watched the whole video of Jobs, and I enjoyed it and took something away from it. I also don't think that it applies to this conversation.

From Jobs's perspective here, App Store developers are also customers. So while he is talking about starting at the customers' perspective, rather than the engineers, I believe he's only talking about Apple engineers. 3rd party software devs that are building the Apple ecosystem are:

1. Paying for the privelege of being an Apple Developer

2. Paying Apple a portion of their own earnings.

3. Opting to develop for Apple, rather than other platforms

So if we are Apple developers, we are customers, and according to Jobs's philosophy laid out here, it's Apple's job to deliver value to us (as well as the actual end users).

Apple does deliver value - a huge market of higher paying buyers than Android.

That's their value. Not that their software releases will always be perfect.

None of you will stop making iOS apps over this.

Just because some value is delivered in the form of paying customers doesn't mean Apple (or any business) should stop thinking about other ways to deliver value to their customers (being developers in this case).

Full disclosure - I have developed many apps for iOS, but have never monetized them. I have used both Hybrid and native tech to do this. It has been probably 5 years since I've done Hybrid and about 15 months since I made a native app.

I don't think that they are - they've added numerous features to their hardware that software devs can interact with.

Honestly we just expect everything of everyone else and nothing of ourselves anymore. So they had some wonky version releases, like none of us on here have ever had issues like that before.

> App Store developers are also customers

I found the concept of monopsony to be quite interesting here.

It’s far worse than that I’m afraid, but that’s not really important.

AppStore was about enforcing expanded Human Interface Guidelines to ensure overall product quality while getting some money to the indie devs that had historically starved due to market fragmentation. The combination of overall user experience, apps and Tim Apple’s buying up all the manufacturing capacity in ChYna (to lockout competitors —a lesson they learned from the PC knock-off days) assured ..$2T!

> their main focus will always be users instead of developers and that the latter will just have to suck it up if they want to get a piece of the lucrative Apple user base pie

Developers are users as well. In the early days of computing, both terms were actually synonymous. If Apple designed the user interface of its programming environment so that the software developer cannot find out what went wrong and why, Apple deserves all the hatred it gets.

Also, this "lucrative Apple pie" is the only reason anyone even cares about it. If money is removed from the equation, I have no doubt developers would rather invest their time on a Linux system that doesn't insult their intelligence.

Well, I think you might be misunderstanding this a bit. What happens is that you download a compressed application and that is signed by Apple to prevent tampering, I assume to prevent XcodeGhost-like malware. The issue is that 1. this only tells you that the file you have came from Apple but not what it contains and 2. Xcode is massive and downloading it, verifying it and then uncompressing it to run it and check its build number takes ages: you could have a gigabit connection and a 18-core iMac Pro and you’re still looking at half an hour from opening the developer downloads site to being able to check to see what you just downloaded. When Apple messes up their labeling/caching/whatever you can see why a SHA would be extremely useful, as I know people who repeated this process multiple times through the day in hopes of getting the build Apple claimed they should have. (Eventually people started spreading hashes, not verifying the archive, and sharing it around via file hosting sites like Dropbox, which totally defeats the point of all of these things, so good job Apple on making this process so annoying that people will just jump through the hoops to bypass it.)
The last beta was 28Gb, nearly double the size of version 11.
What? Are delta updates not a thing?
Not for beta releases of Xcode, since they’re only provided through the developer site (not the App Store) and you have to download a full installer every single time.
Not an installer, but a compressed (and signed) archive of the thing.
That’s bizarre. They provide delta OTA updates for iOS betas...
Xcode betas just don't go through software update for whatever reason. Not sure why.
Gee, it sounds like even devs internally weren't aware of it and everyone's scrambling.
Probably. Unless they’re something that clearly explains why this update just had to go out tomorrow, like new iPhones shipping or something, the people who signed off on this should be writing a report tomorrow about how badly they’ve damaged developer relations and created a huge amount of work internally for the app review team and probably the engineering as well. The fact that the main part of the even from today that I care about is a ten second snippet from Tim instead of how fast A14 Bionic is or whatever is a really bad look for how much this has ruined developer trust in Apple.
It's likely because of the Apple Watch Series 6, which will almost certainly release with WatchOS 7, which is in-turn only compatible with iOS 14. The Series 6 launches Friday, so if they wanted to delay iOS 14, they'd have to delay that launch too.
> The Series 6 launches Friday, so if they wanted to delay iOS 14, they'd have to delay that launch too.

Or they could have just launched both on Friday.

I had so much fun reading that!
Question - why are apple downloads slow - I don't get it.

I've downloaded lots of stuff from google. Its rarely slow.

I use cloudfront on AWS - also rarely slow.

Apple - often slow. They have billions - is there something wrong with their caching layer at ISPs etc?

Mac mini's don't have fast NICs, and they're probably still unable to use the current Mac Pros for production reasons. The old Mac Pros keep rolling off the rack.
A Mac Mini with gigabit ethernet can saturate a gig and not break a sweat.

A Mac Mini with a 10G Ethernet port can saturate 10G.

So, how are they not fast?

They're actually usually pretty decent, back when I had a gigabit connection I would regularly saturate it with Xcode or macOS or whatever beta Apple had the for the week. The issue is that when they're rushing and developers are rushing they just don't handle the load well at all–right after presentation when new things get posted is usually a bad time :/ Perhaps they just don't scale very well.
That is what I mean. When netflix releases a popular new show - it basically still streams etc. The bandwidth must still be nuts.

Apple falls over after big events for developers etc. Is there not a cashing layer locally at ISP level - ie, push '209 out in advance to ISP cache, then everyone can gobble it up when you announce and link on your website?

It really depends on region. I have seen in US, most of the downloads are fast as that is their main region I guess. As the network latency does not matter when downloading big files, I use that VPN and get much better speed than using local CDN.
Definition of incompetent:

a: lacking the qualities needed for effective action

b: unable to function properly

> the final public release of iOS 14 ships tomorrow, which came as quite a shock to all third-party developers.

Really? This is the way they have done the releases for about 10 years now.

Nope, they ship a GM a week in advance.
Wait, what? Did Apple announce that GM is released to public beta, or did they announce that they are actually pushing out iOS 14 to over 1B devices as of tomorrow? Because the two are very different. If it’s the former, I agree with the author that it’s a complete disaster for a lot of development teams. There is really no sane reason to do something like this, so I just can’t imagine it’s true — it’s not like the OS update has to be pushed out ASAP because some magical new device or service requires it.
Latter: iOS 14 is going out to 2 billion devices tomorrow, probably 10 AM.
My phone is offering to install it right now (In Australia, 19:35:00+10:00). It's _possible_ I'm getting it early because I've been running the recent betas on this phone.
That’s probably the GM, which went out today.
My take. Developers will be positively surprised today to find out how fast their app updates will hit the store if their app is already in the App Store. Apple could have released everything next Friday, including products that need the new iOS, but decided to pull the trigger right away. They MUST have a plan on why acting like this make sense. Still, it's 2020, so maybe I'm wrong and it's just another sign of the weird times we're living.
Just replying to my own comment to point out that iOS 14 is out since 12 hrs, more or less, and the world hasn't ended, nor the users have taken to the streets pitchforks in hand.
A testament to the low software grade I’ve come to expect from Apple. I wonder if anyone inside Apple reads HN abiding NDAs or they simply have no clue.
Of course they do, HN is huge. But don't think that the software engineers there have much more ability to make decisions than you.
They can because Google with Android sucks also. If you are an app developer just get used to bend over.
Don't worry Apple hates users too.

I've once had a Windows update break software, and I was easily able to downgrade the broken update (and it wasn't really MSvs fault entirely, graphics driver issue).

Multiple times I've had ipad updates break apps, and some apps have never worked again because the developers don't bother updating the app, and Apple blocks downgrading because...

Windows has broken installations in the past, https://www.windowslatest.com/2020/02/16/windows-10-kb453269...

It’s not all roses over there.

As a Windows sysadmin I hate the OS with a passion, but at least on it you have one of the best development platforms out there (.net).
.Net hasn’t been tied to Windows for years.
The point is that windows can break but it provides you tools to undo the break. With Apple, you're SOL.
I'm not endorsing the stupid stuff that Apple has been doing in the article, but for your case, I don't see what they should have done differently.

Maintaining backwards compatibility for every app is a big technical requirement, and Apple chooses to spend their efforts elsewhere. Microsoft takes the opposite route because they have many enterprise customers who have to keep using an internal CRM that was last updated in 1994 and all the developers have died.

If you want your OS to support abandoned apps, then you should definitely choose Microsoft. But most people have other priorities.

Similarly, keeping devices on old OS versions has a cost too. They could be insecure, opening users to the risk of compromise of their personal data. Newer apps will not work. Having a significant proportion of devices that have not bothered to upgrade stops developers from using the newest OS features (for an extreme version of this phenomena, remember ie6).

Apple prioritizes getting users and apps on the latest OS releases over perpetual support of abandonware. The proportion of users who need to support abandoned software is probably tiny compared to those who can benefit from OS updates. It's a conscious choice, and other vendors choose differently.

(comment deleted)
And yet you ask any developer shop they will say it’s a good thing that they don’t have support 20 different OS matrixes like they do on Android
It’s only a fuck up if there are adverse consequences.
At the risk of sounding frivolous: because it is an asshole. There's a lesson in that, I think.
I guess I have a minority view, but when were they not?

Steve Jobs was famously toxic (which is just popular term to describe someone with a cluster B personality disorder, aka "psychopath"). But he dresses like a rock star and creates beautiful things and so everybody is willing to forgive him.

This is kind of like the abused spouse who, after decades of abuse, finally realizes he or she was making excuses for a psychopath all along. Just file for divorce and get it over with. The abuser will make sure it's a horrible experience for you, but you'll be happier in the end.

(comment deleted)
My response to the Apple Developer Feedback Request

HOW CAN APPLE MAKE APP REVIEW BETTER?

App Review has become faster but still feels very unsafe and unreliable. It feels like being delivered to the whims of the gods. They may strike you down, kill your business and refuse to negotiate about it. Speaking about which, speaking with app review is infuriating! They will mindlessly reiterate the same quasi-legal lingo about how your app should confirm to this or that guideline completely ignoring whatever actual logical or societally relevant or otherwise actually meaningful argument is made on the other side. I understand it is not these people themselves - they must hate their jobs - but the rules they themselves are bound to - but the resulting experience is god awful.

HOW SATISFIED ARE YOU WITH THE FOLLOWING APPLE DEVELOPER RESOURCES?

I used to like Apple - look up to your company. I was elated to be able to visit the WWDC. Even spoke with Tim Cook - however briefly. Watching the 15 Sept Apple Event I noticed I was getting more and more annoyed. I really resent the dishonesty. I feel that I am starting to actually hate what Apple has become to stand for.

-"We treat all developers equally". - The tax evasions via Ireland. - Bullying a tiny company about a pear-shaped logo - Pretending to care about freedom of speech while supporting censorship and banning of apps in china. - the list goes on

Apple tries to present itself as a force of good - but has become a despicable company. It makes me sad. You are the one company that could actually be a force of good. Untouchable. You could really make a difference.

Yet you don't.

Well not in a good way at least.

HOW CAN APPLE IMPROVE THE TOOLS AND SERVICES IT PROVIDES AS A DEVELOPMENT PLATFORM? Be as specific and descriptive as possible

Focus on quality more than on constantly churning out new features - it's not necessary. You are Apple - you determine what happens. You used to stand for the best. It used to feel remarkable to use and work with Apple products. It's now just above par. Why? You're worth 2 trillion dollars already. Is 2.2 trillion more important than going back to actually making the best again.

HOW CAN APPLE MAKE THE APP STORE A BETTER PLATFORM FOR DISTRIBUTING YOUR APPS? Be as specific and descriptive as possible

"This app is damaged and may harm your computer" - stop that! At least try to be reasonable. Please!