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.
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 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.
Ah, the early 2000's, with Apple and Microsoft battling it out, what a time to be alive.
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).
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!
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 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.
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).
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.
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.
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.
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.
> 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?
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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%.
>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.
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.
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.
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.
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.
> 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""
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.
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
>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.
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:
Maybe I am missing something, but iOS 14 has had beta versions out for developers for months; I had been running iOS14 and Big Sur for testing for weeks. Apple has always had developer previews and at some point, when mostly stable, they often release public previews to get a few interested users involved in testing as well.
They've been working with developers for a long time on the new App Clips functionality and that's been open for developers to start working.
So I am not following what is this article is saying? It seems like they're suggesting that Apple should release iOS a few days after announcing, but, that isn't enough time for most developers to test and release updates for a major iOS update; but Apple never intended those few days to be the only time developers had.
Past major iOS releases have usually given about a week between the release of the final build to developers (with app submissions opening at the same time) and the release to the general public. This gives developers time to validate their code against the final build of iOS and submit updates if needed, allowing plenty of time for App Review to do their thing. This is also the first point where Apple will accept app updates which take advantage of new features in the new iOS release, so giving devs some notice to finalize those updates is nice as well.
Yes, developers should have already been working with the iOS betas and already have some confidence that things will work against the final release-- but there is no substitute for actually testing against the final release build. In this case, iOS 14 Beta 8 appears to be mostly identical to the GM Seed build (what released to devs yesterday, and what will release to the public today), but that, historically, has not always been the case-- in some cases, bugs get fixed in between the last beta build and the GM seed; in others, new bugs get introduced.
Usually there's a period of time between announcement and when it ships, such that a developer can get the release version of Xcode (if necessary), do some final testing, then send any updates to Apple for review. With enough lead time that their updated app can be available on the App Store the same day as the iOS update being available.
Say the iOS update has brand new features. Your app can't take advantage of those fancy new features and your users don't get them until next week either.
Possible marketing, usually Apple has categories in the App Store for apps that support the latest features or are ready for that iOS version. They could in theory do this next week I guess, but point is there's excitement today, and will be less next week.
Possible bugs in your current app that aren't fixed but exist only in the latest iOS. If you base your entire process on past experience you planned to release bug fixes for iOS 14 with a larger update and now those updates aren't available to a majority of your userbase.
The first point doesn’t make sense to me at all. No particular date was set for when users would be able to install apps with the new features.
Point two seems weak. The idea that Apple won’t promote apps with the new features when they are released makes no sense at all. You make it sound like this is unlikely, but I don’t see why you’d think that.
As for excitement - what excitement are we talking about? Users will get app updates automatically as they become available.
Are you suggesting that users typically buy a whole load of new apps on the one day iOS updates ship, but only if those apps have features only supported by the new OS? That would be an interesting fact if true, but it would also be supported by data, which I don’t see anywhere.
I’d speculate that users more often look for new apps when they get a new phone - which is supported by the data on Christmas app installs, and isn’t affected by this.
So we’re left with the possibility that the developer has bugs in the last iOS 13 version of their app that did not manifest under Beta 8, but do manifest under the GM.
I agree this is not impossible, although very unlikely to affect all but the tiniest handful of apps. Beta 8 and GM are unlikely to have significant changes of the kind that might expose such bugs, but again I agree it’s not impossible.
This seems like an extremely exotic case, and certainly in no way justifies Apple being called an ‘Asshole’, except by someone who has other reasons for wanting to malign them.
> No particular date was set for when users would be able to install apps with the new features.
The expectation is that apps will support the new features on day one. Because that's how it has worked in the past.
> what excitement are we talking about? Users will get app updates automatically as they become available.
Again, historically, apps support the new features on day one. That won't be the case with this release because there's no way an App developer will be able to ship an app to App Store review in 24 hours and have the app available the same day.
> Are you suggesting that users typically buy a whole load of new apps on the one day iOS updates ship, but only if those apps have features only supported by the new OS?
I'm not so sure about buying new apps, I am saying that typically existing apps get updates that take advantage of new features and those are typically available on day one of an iOS update and won't be this year.
I don't think iOS 14 has any major game changing features, so I don't think we'll see a massive buy in of new apps or anything. But if this trend happens again with a release that DOES have major new features then it's a big disappointment.
> So we’re left with the possibility that the developer has bugs in the last iOS 13 version of their app that did not manifest under Beta 8, but do manifest under the GM.
Keep in mind that developers on iOS tend to think in terms of larger updates. So an app developer may release a new major version on the same day as iOS 14, or iOS 13, etc.
These are typically 'free' updates for existing users, but they're whole version updates and come with a larger set of changes.
In the past, developers had time to prepare for release. If bugs existed in version 3 of their app running on the iOS beta, they probably fixed those in version 4 (unreleased) of their app, and planned to submit and ship version 4 the same day as iOS 14. That entire process is not going to happen this year, so it's possible that bugs existing in iOS 14, but did not exist in 13, will be present in apps until those updates ship next week sometime.
>and certainly in no way justifies Apple being called an ‘Asshole’
I'm not calling Apple an asshole, I'm not defending the author of the article who is calling them an asshole. I'm simply explaining how it worked when I worked on a major top 50 app in the App Store. Thank god I'm not doing it anymore, it was stressful enough doing it in previous years, it's probably even worse today.
Ok - so it sounds like it’s actually not really a problem at all this time around, but if there had been game changing features it might have been?
My guess is that Apple would have taken this into account when scheduling the release.
If there was some marquee feature where day 1 support was important, this would have been part of Apple’s planning.
It’s clear to me that this is really not a big deal at all and that the original author - not you - is trying to manufacture outrage where none is merited.
It’s also not clear to me that any significant end users would have reason to expect most apps to be updated on day 1.
Apps have simply never adopted all the new features they could, day 1 or not. Often adoption has been gradual. Even things that are very obvious like screen size changes sometimes have taken months to be supported.
I wouldn't say it's not a big deal. It could very well be a big deal to them.
Is it the end of the world? No, I don't think so, but it is very clearly causing a lot of developers pains today, you should at the very least acknowledge that and understand that just because you can shrug it off doesn't mean they can.
Something that is severely missing from the world of software, and I suspect engineering in general, is empathy. Hell, it's missing from the world today. Look at the political climate in the US for another big example.
So maybe that's what your takeaway should be, show a little empathy to those who are struggling today and understand that. On top of a global pandemic, on top of possibly having their kids at home and being home schooled or learning virtually, having maybe lost a loved one, maybe even had to abandon their home due to fires, that on top of any or all of that they now have to deal with the pains of an iOS release with no warning. Empathy. Try it.
So what word would be good to describe your behavior in writing a long screed that accuses me of lacking empathy? Covid! Fires! Loved ones! US Politics! Oh my! Is this you giving a demonstration of empathy for me?
I have plenty of empathy if developers are actually facing pain. Piling on to attack Apple, not so much. Apple employees also have families and many of them are in California too. I’m guessing they too are affected by all of these issues.
If the original author was able to articulate the pain they are facing, I’d have empathy for them.
They didn’t in fact do so, which is why we’re trying to figure out what the negative impacts would be.
It’s absurd also to suggest that there was an iOS release with no warning. That is simply not true. We’ve been expecting it for months, and we also knew the release schedule would be different this year.
If people are being pressured by managers in some painful way, then I do feel for them, but if that pressure is occurring because managers actually have a false understanding of what is at stake, then it is more empathetic to discuss the misunderstandings about this than it is to just nod along.
It’s really not clear at all what pain anyone should be feeling.
Presumably their apps are ready to go, and all they have to do is submit them and wait.
As we’ve already discussed, almost nobody should be actually discovering bugs now, regardless of Apple’s scheduling.
Everyone knew iOS was coming out sometime soon. Nobody knew that Apple would drop the actual update the day after the Golden Master. They had absolutely no reason to. The fact that this went out, and that Apple themselves were unable to ship their own software on time to support this release, is an extremely annoying move. You sitting there and saying there "should" be no bugs is nice but not indicative at all of reality, where Apple changes their software and ships new bugs in the GM itself.
I love that you aren't in this field at all, but seem to know better than others who are. This is like that person that starts a new job, walks in on day one, and then proclaims that the place is doing everything wrong without knowing anything about how the business operates.
You need to compile your app with the new version of Xcode to target iOS 14, and you couldn't do that until the GM version of Xcode was released yesterday. Meaning that if there's any iOS 14-showstopping bugs, depending on the type of bug, you wouldn't be able to get a fix out promptly. There's also the work of e.g. verifying that your app works as advertised on the iOS 14 GM, which also was only released yesterday.
If its a popular app with lots of competition, if your competitors have a working app and yours is broken then people will jump ship and once that happens hard to get people to go through the hassle of moving again.
Though I'm not an mobile app developer just one of the things I can see as a downside.
There was a three-week gap since the last Xcode update and Apple is notorious for breaking stuff between Betas. We were given a single day to get everything set up (CI/CD, signing certificates, provisioning profiles, etc), update our codebase (yes there were source changes made in the GM update), and test that everything works (three weeks worth of Xcode changes), so no it's not really how you picture it to be. Having iOS14 features ready to be in sync with the iOS14 launch is pretty crucial for apps.
Even major apps like Instagram and Snapchat still have critical camera bugs on my phone right now that's running the latest iOS14Beta8 build.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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).
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.
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.
I don’t understand. Current apps will run just fine, won’t they? Also beta versions of iOS and XCode have been around for months - so it’s not like you’re starting from scratch today. And it’s not like you absolutely must release tomorrow, do you?
There's absolutely no guarantee current apps will run fine - Apple regularly adds new restrictions and API changes which break existing apps. They also tend to add a lot of new bugs every release which need to be worked around.
The problem as I understand it is that Xcode for GM was just (?) released and then you have the approval process. So they run a real risk of not having an app iOS 14 compatible at launch. It doesn’t matter if they’ve had the whole beta to test their app on and get ready if Xcode for GM was just released.
I think the rub is that a lot of the apps built at these massive companies use unnecessary third party frameworks and build their apps in janky ways, so while the content of their app doesn't appear to need anything special, it's actually standing on top of a house of cards built out of 3rd party APIs that are doing janky things that break between OS updates. If they just built their apps fully natively, using UIKit exclusively, they likely wouldn't have any problems between releases like you, I, and other devs see.
I'm in the same boat. All my apps are working and we've been testing against the betas without issues. Downloaded the GM and submitted for review. I can't imagine that A) there is a huge grouping of apps that will suddenly break and B) that there's any kind of reason for these apps to need this update out today. It's not like there's a new feature or SDK that would make or break an app over 1 day or even a week.
Considering all the bad press Apple is having with devs at the moment (from Spotify and EPIC, to this), I wonder how these behaviours haven’t back-fired yet.
At the end of the day, a platform without apps or developers dies (Windows Phone users say hi). If devs get so mad at some point and stop pushing new apps or updates, I wonder if Apple would change their position.
Of course, I suppose this is still hard because 1) they are the most profitable mobile platform 2) many companies kinda rely on mobile. But well, no one predicted 2020 who knows what will come
Most people/developers don’t care about these “issues”. Jessie Squires, while I am a fan of his, tends to be very outspoken on a variety of topics. It’s not out of character for him to write a profanity-laced tirade on the internet about something that doesn’t matter to 95% of people. This isn’t meant to be a dig on him or his beliefs (I wish I could be an anarchist) but just a matter of fact way of saying that most people and developers simply do not care about these “issues” and are just happy being developers for a great ecosystem that can line your wallet with fat stacks if you play your cards right.
As with most things on the internet, outrage drives engagement, so stuff like this will easily reach the front page of HN, even if most people really don’t care much at all.
many developers have really no choice (at least not individually). They don't really have the means to vote with their wallets, as foregoing the whole iOS market is.. not a choice.
What EPIC is doing is trying to rally people on their side of the fight.
This is the same reason why people (workers) have unions, in the traditional job market. It's not really comparable because developers are not workers, but there are some similarities: Apple benefits from the developers (immensely, with your Windows Phone example) and the developers too.. but Apple has the upper hand, by FAR.
I believe so too, but that does not mean anything for my argument. They are trying to rally people so that they can get better profits. The fact that maybe (and i'm skeptical about it) other people do too, it's coincidental for them, i'm sure.
The walled garden has been hugely beneficial for developers, the relative app sales rates between iOS and Android is proof of that. And iOS customers overwhelmingly prefer the walled garden, it’s the main reason they buy iPhones.
If the walled gardens was costing Apple customers instead of attracting them, the iPhone would have failed years ago. Android devices are cheaper, more diverse, and more flexible. There would be scant reasons to buy an iPhone.
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.
> 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.
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.
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.
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!
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.
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 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.
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.
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.
I like making my side projects cross-platform when possible. But I'm done trying to get code signing to work, I won't pay Apple $100 to distribute free software, and I have no interest in using XCode, so I feel basically restricted to Linux and Windows only at this point.
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.
I feel that, as industry, we need to move back to the rich, browser-based applications on the mobile phones. Apple-Google duopoly is just not the way to live. As tech community, we can take our power back. I think the good start is to start using web on mobile phones.
Both Google and Apple currently subscribe to the "open internet" philosophy on mobile phones. This was their selling point against the old, "walled garden internet", vendors. If they change that and start blocking the sites, I think we will see a serious backlash. We will begin to switch to Linux phones then. :-)
Apple set a hard deadline for themselves. This would have been some time back, with the purpose of coordinating various development threads, manufacturing, marketing, and the holiday season.
But the OS side slipped.
They must have been dealing with some pretty gnarly issues to give devs only hours with the GM seed and even less time with the version of Xcode you can use to actually release updates.
Makes we wonder what the issues are and whether the OS is the only thing that slipped? ...time will tell if they shouldn't gone ahead pushed everything back. That would have been very costly, but an unstable OS release that, e.g., loses or exposes user data for lots of users would be costly as well. We'll see.
> Who is in charge of iOS releases at Apple that thought this was a good idea? Who is the head of Developer Relations that thought this was a good idea?
I think, obviously, nobody did. It wasn't planned.
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.
One of my apps, Black Highlighter , 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.
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.
When I read this, all I'm really reading is, Apple's biggest cultural position on secrecy is also its biggest pain-point for external developers.
Secrecy is so ingrained in that company, at all levels, that it will never/ever change without fundamentally changing what/who Apple is as a company.
External developers, since the launch of the App Store, have been expected to be thankful that Apple even lets them on to their precious marketplace. There's also no special treatment when at bigger companies either. The only thing I've experienced is that we were invited to port our product to iOS 7's new flat UI just to be featured 6 weeks ahead of their rumored keynote date. They didn't even give us an actual time to submit.
Bigger products I've worked on do get a developer relations support person who makes sure we're able to meet Apple's latest demands, but they are not connected to the engineering (R&D) teams, so feedback is mostly downward. For example, they would ask why haven't we ported things to Metal yet? If we inform them there is a bug or missing documentation, they will make sure they get engineering involved to fix the bug so we can continue porting to Metal.
Bugs are another huge pain point that developers complain about. Whenever there's an issue, we're told, file the bug and it magically goes off into a black void with no feedback until some point in the future when the OS release has shipped and then we get to find out whether they decided to fix the issue or to mark it "Works as expected."
It really sucks that the company that builds the best tech is also the most toxic to partner with. They add undue stress and expect too much from their developer community. Partnerships should work both ways! Developers bring new experiences that light up the hardware, and make the platform better as a whole. However, Apple has somehow found a way to make the partnerships mostly one-sided and that will never change.
The only way out is really for all the coolest new features to land on Android and to put software in maintenance mode on iOS. Yet, I cannot fathom how that would ever happen either as that's 50% of the population in the US you would make suffer for the cause.
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.
Pretty simple answer. in August 2020 they became the first $2 trillion U.S. company. There is no repercussion for them at this point to treat everyone from Epic Games, to your run-of-the-mill Xcode devs, like trash.
In the case of the former, you can outlast these comparatively small players for decades with flush cash reserves and an army of bored attorneys with nothing better to do than watch your pittance of a legal team fight it endlessly until the last star falls from the heavens. Epic may want a fight, but its investors would capitulate sooner than people like Tim Sweeney think.
as for the latter, Apple has a fun track record of running small developers into the dirt. Either you sell your company to them, or they just build the same app in-house and blacklist you from the market.
Id also argue that the average apple afficionado outside of HN just doesnt care what apple does. Apple makes affluent status symbols and markets a premium brand identity, so developers like facebook and epic are hungry to tap into a market thats not only willing to drop more than a grand on a cellphone and accessories, but doesnt question often times predatory microtransactions. They want cash cows, apple runs the farm.
full confession though, i dont know how small devs fight this, and id be eager to know if anyone on HN has a cogent strategy? a boycott seems most effective.
Do developers get a pre-release of iOS to test on or how can you release a new version of your app before the targeted OS is released? Also, why do you need to release a new version at all? I'd expect the platform to stay largely compatible.
(Obviously, I haven't developed anything for the Apple ecosystem, so these are genuine questions.)
> Do developers get a pre-release of iOS to test on?
Yes, but those pre-release OS versions are changed and updated by Apple as the process goes along. So once Apple declares the final version (AKA Gold Master), then everyone needs to regression test their apps against this final version that will be installed on user devices. The process of submitting the app update to the store must be done with a new toolchain as well. Usually the GM version and new toolchain are available 1 week before release. This time they were only available 1 day before. Even if all the development is done and the testing against the GM version goes smoothly, 1 day is a very short turn-around for getting your app update approved by Apple, especially on a day where lots of other developers will be submitting updates too.
> Also, why do you need to release a new version at all?
Sometimes the new version introduces unintentional bugs that break existing functionality and developers have to figure out how to work around it. Sometimes Apple intentionally deprecates existing functionality. These are things that developers can address with the pre-release versions, but again, those are moving targets and until the GM version is released, you don't know for sure.
I'm sure some people at Apple do care about developers, but these are not the people making the important decisions.
Apple knows they are in control of +60% of the app mobile revenue worldwide. It wouldn't surprise me if management believed third party developers should consider themselves privileged to be on their platform.
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!
Apple has always been an asshole. I was an original Macintosh beta tester - I had a Mac summer of'83, 6 months before their release. Yet, I have never shipped commercial Apple software. Their developer treatment has never been ethical, and I simply never put up with it.
Read any Hacker News thread about the awful crap Apple is constantly pulling to see why they are acting like assholes- because their core fanbase (which is VERY big) will defend their actions regardless.
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.
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 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?
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.
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 the mining operation was inside the mine. Before they had to exit the mine to check stuff on the truck driver phone and make the do paperwork. Now LoRa module allowed the phone to have signal even inside if they parked their truck at the mine's mouth. Before that the phone would lose internet connectivity 20 feet inside the mine.
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.
> 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?
> 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.
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.
> 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.
> 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.
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.
Apple has become an ecosystem to avoid at all cost. From denying the right to repair, design of devices to make it prone to catastrophic failures, making it difficult to recover own data (to force people to use cloud backup so they can look at all your data) and many more (like trying to make employees go through security checks without being paid for it)... Greed has blinded them.
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.
First of all, the complainers do not speak for me, yet they seem to be speaking for everyone, that everyone has this problem because of 24-hour notice of the release of iOS14.
Anyone that has a work flow, even a personal workflow having nothing to do with actual earning of income, that updates as soon as an update is available, is an asshole to themselves, and a compulsive one at that. If there are no security patches, bug fixes or features that I desperately need, I don't update. I'm still running iPadOS13.4 and I may never update.
The problem here is not Apple's. Apple can do as it wants, and is under no obligation to make things convenient for the egotistical developers. From my perspective, (and fallacy argument from authority here, but fwiw, I studied computer science, flunky career in systems administration, and I am perfectly aware I rarely did any computer science, but am also aware programming is not computer science, either... CS is just math, and that is all... I personally just liked the problem solving necessities that sysadmining provided me, along with a decent living... I enjoyed solving those puzzles), developing for iOS sounds easy as snot. Developing a killer app is more difficult in that it must be innovative, clever, beautiful, and useful. But 99% of the apps on AppStore, and including 90% of the games, are duplicates of stuff that has been around forever. Where is the innovation?
And I have very little sympathy for developers because most of them made my life a living hell for 20 years. It is that precious few that did the opposite that I love, nay, that I worship. What are the chances anyone in this group of developer blamers and complainers, borderline narcissist egoists, are among them? Slim to none.
Apple gave you excellent tools. You have your own source code. Get something done! It doesn't matter how long it takes. But with the tools Apple provides, seems to me it is loading the tools, loading the source, grooming the source for the update, clicking a few radio buttons, compiling, and publishing. Shut up and get something done, or bail and go develop for another platform. Jeesh. Make install not war.
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.
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.
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.
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 ?