- The documentation could be improved a lot - with examples ideally.
- The App Review process seems to flag a number of the same issues which are subsequently resolved after sharing a video that there is already compliance. This could be improved
- Showing specific error messages - I think this is somewhat Universal but Apple gets it wrong far more often. For example if you don't accept an Agreement somewhere in App Store Connect, you will just see a random error when you try to test In-App Purchase and some developers may think it's a problem with their code when in fact it's something else entirely. This wastes time and can be incredibly frustrating and demoralizing. Also the In-App _Purchase sandbox user flow is needlessly complicated.
I recently went through the second one for my hacker news app HACK.
I had an urgent bug fix update which fixed issues related to the hacker news website making some small html changes which broke the parsing code.
Apple rejected the update saying my app didn’t allow user content to be flagged, blocked, hidden etc. this had already been dealt with in a prior update and my app already included these features. Somehow Apple reviewer decided to review the app without logging in and obviously without logging in, you won’t see the ability to flag, hide, block etc.
This ended up wasting 2 days. And this is something which was already dealt with in prior update and my app already included.
What about bringing back the "deprecated" documentation that is still quite relevant and only old timers like ourselves can find it, because we have the bookmarks and also know what to search for?
And also Xcode. And breaking existing functionality.
But, in the end, it boils down to the fact that "developers, developers, developers" just isn't an Apple mantra (viz: Jobs' initial reluctance to open an appstore).
They know that, as long as they corral a lot of paying customers the developers will keep coming, no matter how many problems they throw in the way.
I remember when Apple first launched the System 7 Helpline. It was 13 May 1991. And it was the first time in Apple's history they took direct consumer questions. [I worked on the System 7 Helpline with the initial cadre of support reps.]
At the time, they had some sort of developer support line which was considered practically a state secret. They didn't want anyone trying to reach Apple developers directly. Not even the people from the System 7 Helpline. I remember making a new version of the "System Errors DA" for System 7. Apple users considered me a god. The actual Apple developers were creatures from beyond time and space.
Apple also only wanted to take limited calls from their dealer channel, and most of that was for hardware issues only. Supporting software at the developer level, unless you were at the Microsoft Office level, was anathema.
So here we are thirty one years later and finally Apple is opening up a direct developer relations line. How might Apple's history have been altered had it actually been less standoffish towards developers in the 1990s, 2000s, and 2010s?
Did I miss other iterations at something like this over the decades? [I have to admit it's been years since I've fallen off the Apple wagon other than as a user.]
Also, why is this limited to mere "one-on-one 25-minute consultations?" Why can't it be a team Zoom call? Why can't it go for an hour? Where's the Slack channel?
What would an annual team developer support agreement look like? (Scalable for individual developers, small teams, large teams, etc.)
I guess this is a step in the right direction, but it still smacks of decades-ago thinking. Long overdue. But perhaps not sufficient for this day and age.
>Also, why is this limited to mere "one-on-one 25-minute consultations?" Why can't it be a team Zoom call? Why can't it go for an hour? Where's the Slack channel?
Aren't you a developer? How would you feel if your job was suddenly "customer support engineer" overnight? IMO, direct developer channels only makes sense when you are small; and one developer has the entire product in their head. Once the problem becomes large you end up with:
1. Developer knows nothing $problem, because it was written by a different team, effectively making them tier 3 support.
2. Developer quits because being "tier 3 support" wasn't communicated effectively in hiring.
3. Developer(s) actively avoid hour long team support sessions because developers aren't promoted on being closing support tickets, they are promoted on delivering features
4. Customer does not bring in enough revenue to support tying up $n developers for hours at a time.
Not to say you cannot build great developer support systems; just that direct customer contact with the engineer who built $x isn't scalable.
I may be an anomaly, but most of the Ask Apple topics wouldn't be terribly useful for me. In general, I haven't had much difficulty figuring out how to use the various frameworks and features as they are released. I don't want to discount the experience of anyone who has had difficulty however. Getting direct technical help may be the key to their sucess.
I am a former Apple employee but this has given me no special privileges or advantages at all. Perhaps it has given me some particular skill at diving into header files to figure out a solution to a technical problem.
The issue(s) I need the most help with revolve around generating revenues that don't involve advertising, subscriptions, dark patterns or racing to the bottom on pricing. The AppStore model makes it very difficult to use some of the techniques that worked in the old days of shrink wrap and direct online distribution; trial periods, version upgrades and other concepts that don't fit into the AppStore buy it once and get upgraded for life.
It was my decision to make an application that incurred expensive development costs and it was also a risk to depend upon Apple and the AppStore. They sure do make it hard for small developers to try and make a living selling "professional" level applications.
> The issue(s) I need the most help with revolve around generating revenues that don't involve advertising, subscriptions, dark patterns or racing to the bottom on pricing. The AppStore model makes it very difficult to use some of the techniques that worked in the old days of shrink wrap and direct online distribution; trial periods, version upgrades and other concepts that don't fit into the AppStore buy it once and get upgraded for life.
The part that bugs me is that Apple could fix these issues but is choosing not to. Rather than adding upgrade pricing (something developers have been asking for since 2009), they added and have been pushing for subscriptions :(
I’m not as down on subscriptions for apps as other people seem to be. If—and I recognize these are big “ifs” here—the annual price is reasonable (which I’d roughly define as “no more than what you’d be paying for upgrades if they were amortized over a yearly basis”), and developers use this stable recurring revenue to make frequent updates to their apps on a rolling release rather than holding big features back for major updates every one to three years, I’m happy enough to pay for them this way.
Granted, I’d prefer to see the ability to handle subscriptions the way Panic does for their editor Nova, in which you get all the updates as long as your subscription is valid, and if you stop paying you stay on whatever the most recent version was when your subscription expires. (This is distinct from Jetbrains’ take on this, where when you stop paying you stay on the version that was current when your subscription started.) This is something I don’t think the App Store supports, either.
> I am a former Apple employee but this has given me no special privileges or advantages at all. Perhaps it has given me some particular skill at diving into header files to figure out a solution to a technical problem.
It’s definitely the latter. Being a former employee or a longtime developer on Apple platforms gives you a ton of background knowledge. Apple’s frameworks generally have a lot of consistency with each other (probably because of how they do review of new APIs internally), so once you know several frameworks you can easily pick up another. People without that background struggle, even if they’re experienced developers on other platforms.
I experience this myself in the other direction when I try to write stuff for Windows. I’m also ex-Apple so I know the tools and I know where to look to find out what I don’t yet know on the Mac, and worst case scenario I can dig in and reverse engineer Apple stuff that does what I want to do pretty easily. On Windows, I’m just a lot slower and I have to do a lot more hunting around to find out what I need. Generally when I do a new feature that needs platform specific code on both Windows and Mac, I do the Mac side first so I can validate the idea and get something working, and then I do the Windows side second so I’m not having to do exploratory work there, it’s just a matter of trying to find the equivalent functionality and hooking it up. I hear from a lot of Windows folks that they struggle to code on the Mac and they blame Apple for this, but really it’s more just the fact that they have a ton more background knowledge on Windows and they discount the value of this.
Thanks for that observation. You are totally right. Having learned to dive into framework headers and map idioms from one to another is totally something I learned at Apple, especially in the early days of creating a lot of the frameworks that form the foundation of the OS. I have always found Apple's docs to be frustrating, but when I look at them without the benefit of my background, I can see how it must be maddening to developers coming to the platform.
Basically: it's a subscription, but you get to keep the last features you got on it if you cancel. Owners of the original Halide got a year of free updates.
> Developers can ask for [...] help with App Review Guidelines and distribution tools.
This bit is really interesting. It's not a solution to app distribution woes on iOS and macOS, but it is a response to the outcry from developers wanting more clarity on App Review Guidelines. It would be really nice if they could ratify these guidelines as a more consistent set of universally-applicable rules, but I guess an audit session with your local Genius is the next best thing.
This might be great, but who are the “apple experts” you get to be in contact with? It makes me think of the unnecessary logic board replacements their experts (“geniuses”) at apple stores always want you to do, at roughly the cost of a new machine
Independent repair shop fixes Apple laptop at a low price https://www.cbc.ca/player/play/1346591299727 "Louis Rossmann, the owner of a repair shop in New York City who teaches millions to fix Apple products on YouTube, repairs a MacBook Pro at a much lower cost than an Apple Store in Toronto estimated."
'Complete control': Apple accused of overpricing, restricting device repairs https://www.cbc.ca/news/thenational/complete-control-apple-a...
"CBC News used a hidden camera to verify reports that Apple customers are often told their malfunctioning computers are not worth fixing, even when minor repairs could remedy the problem. When presented with a MacBook Pro laptop that had a common issue where the screen was not displaying properly, an employee at the Apple Store responded by saying the device would need significant repairs at a cost of more than $1,200."
Wasn't Louis the impetus for the "right to repair" movement? I have always thought he was a primary driver in getting these companies to allow people to repair their own devices for a long time.
Am I right to assume, he's always been the most vocal about this?
I had this on a mid-2012 MBP (bought new in 2015). Somewhere around Apple's 4th or 5th repair of the machine. Replacement logic board didn't solve the issue, but it sure made macOS complain loudly that my machine appeared to have been stolen.
(Real problem was Apple's flaky SATA flex cables, notorious for breaking on this model. Been replaced 6 times by Apple. I still have the machine - I'm typing on it now - but I do my own repairs. And of course I switched years ago to Windows on a Thinkpad X1 as my daily driver after that Apple experience.)
I went to an Apple store to get the (under warranty) battery in my perfectly functional Macbook Air replaced. The "genius" tried to convince me that the computer had water damage and I should buy a new one. I stood my ground and demanded the battery I was entitled to and he acted like he was doing me a huge favor by ignoring the supposed water damage and giving me the battery. He also commented on my android phone and told me I should buy an iphone. I went there for warranty service, not a sales pitch.
I've read elsewhere that claiming water damage is a common tactic by their employees to avoid honoring the warranty.
IIRC there are moisture indicator stickers scattered around on the internal components, so I don't know how they get off claiming this without using these as proof -- but I've seen myself from other laptop dissections that these can change color if they're old, possibly from gradual ambient humidity?
>I went there for warranty service, not a sales pitch
This changed when Steve Passed away and Tim Cook decided to look at Apple Store as a cost centre and revenue generation rather than Customer Experience and Support.
I have been stating this on HN when their Apple Retail's KPI changed over the years. But every time someone will downvote the comment.
not the OP, but my logic board of my 2020 MBP has been replaced twice already to solve problems. Always under warranty, so I did not pay myself, but I can attest that they do like to suggest these replacements if they can't solve it any other way.
MB failures were a thing back in the oughts; I think it was some new mandated lead free environmentally friendly solder used at the time in the BGA slots for their GPUs and at least some CPUs...granted, they either replaced the MB or the entire computer for free for me...
The App Review Guidelines at 4.3) Spam states: the App Store has enough ... dating apps. We will reject these apps unless they provide a unique, high-quality experience.
Does the App Store accept any new dating apps at all? How high is the bar set for the definition of unique high-quality experience? I'd hate to invest time and money into creating an iOS app just to have it rejected.
I'll try to ask this question on October 17th in the App Store Slack channel they've created but I'm just wondering what you all think here.
My guess is that this in response to the X,000,000 dating sites that are all owned by the same companies and are minimal rebrands with identical shared content in order to capture SEO clicks, and the inevitable webview wrapper dating apps for them.
Maybe my app is too simple, but I have had no issues with developing for, submitting, and shipping downloads (with infrequent updates) in the Apple app store.
Honestly, the major annoyance is paying $120/year while Google only charges a one-time $25, but it is what it is.
At the time of my reply, there are 11 comments with only one being overtly negative (towards bug report resourcing). The post is less than 25 minutes old. Surely we can afford HN more time than that to move on?
I suspect the comment you're replying to is also thinking of other posts, but if so, yes that makes it confusing too. You're response is no less accurate.
Personally I do tire from the <insert pet gripe about X company in the announcement> and general pessimism around HN. I'd much rather hear about what folks think of the specific thing and less about the ongoing conversation about topics surrounding the company. So I kinda get that sentiment.
This seems to be a common position, but a weird one. It seems like you are saying Apple is the best, but you are mad at them, even though nobody can do better.
I literally quit my job at Apple shortly after having this realization myself. It's actually a somewhat comical short tale.
So there I am sitting at my desk right outside the iPhone hardware team's main conference room. I don't recall who on my subteam I was talking with when an exec meeting was just ending from that room, but I distinctly remember exclaiming "We're not good, but we're the best!" before looking up to see people like my boss's boss's boss and the likes. Yikes. But also, fuck them all, they were probably having a meeting to discuss how they could calm down people about the 3.5mm jack they removed.
Are you actually claiming that to be a real event?
The only thing of note about it seems to be you personally making a statement at work that honestly doesn’t sound a million miles away from what Steve Jobs or Jony Ive might have said.
They were famously never satisfied, even though they thought their products were the best.
Sure - but why the anger? Why not direct the anger at Linux. Everyone goes on about how philosophically great it is. Why not be angry that it doesn’t deliver on experience and features?
“Apple has practically unlimited resources and power”
This statement isn’t grounded in reality. If it were, it would make more sense to be angry that they haven’t solved world hunger and ended the threat of nuclear war.
Huh? How can you draw that conclusion from that data? Just because people are moving to the best option does not mean that option is not getting worse.
In my experience, talking to a mac user about macs is like talking to a smoker about smoking.
U can explain with facts how it's expensive and harmful, but u will never convince them to stop.
@prange.. Windows LTSC or any kind of Linux u want, setup exactly how u want, on exactly the hardware u want. You know, like some kind of "personal computer" almost, which you the user have control over and can do what u want with.
I've been using Linux on my Thinkpads for a while now. As well as many other machines. It does have some issues, primarily when it comes time to integrate with my smartphone, which is the primary issue here.
And before someone chimes in, yes I have used both the PinePhone and Purism platforms. They are promising, but not a suitable replacement yet.
If everyone around, except you, sounds angry about something, it might just mean something is wrong.
Whether this goes against your comfy-in-my-relaxed-state attitude, or you are not ready to face the negative information, does not mean everything is fine.
The devil you know is better than the one you don’t.
Also, those with issues tend to be the loudest. You don’t hear from all the people who are basically fine with the status quo, or even from the complainers about all the things they are satisfied with on the platform.
Personally, I love using and developing for the Apple ecosystem, but I too have my gripes. I would rather my perceived issues be fixed, therefore making things even better, than starting from square one on an inferior platform. Which leads to another saying:
XCode is amazing for working on large C++ codebases compared to pretty much everything else.
The closest I have seen is QtCreator, but that's not as polished.
The trendy ones don't even come close.
I’m happy for the initiative – but only if it’s actually backed up with genuine resources. My fear is the typical ‘fanfare and forget’ approach. Plus I’m concerned that this format makes finding good answers to problems completely unsearchable. Lost in the focus on a 1-on-1 format. That seems unsustainable.
I’d be happier if they gave proper resources to the existing dev forums. That means: Ditch the custom format, use discourse/stack exchange as the engine, but then actually answer questions and foster a community. It’s possible. Look at the Swift forums.
Because it could facilitate more code sharing between the platforms, reducing development costs, increasing the talent pool of engineers who can contribute to native mobile projects, allow for development toolchains outside of XCode and Android Studio.
It's just a case of offering a system API that could be called from whatever language - but Apple don't want iOS apps written in Kotlin or C++ and who knows why Android is so locked down.
Further fragmentation to support many methods (eg languages and frameworks) to develop apps on a single platform also spreads the support of the platform thinner as there are fewer developers using a core set of methods on the platform, resulting in wasted and duplicated efforts across all the various methods.
Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house.
Another approach that results in higher quality software is to have domain experts in each area using the languages and tools most optimized for that domain.
Do you hire 20 Javascript developers doing all the programming across the entire solution? Or hire a mix of developers with different skillsets to achieve better quality? The hiring of only one type of developer is a lazy approach, in my opinion, and is largely responsible for poor quality of software with greater complexity.
> Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house.
Sadly this statement describes the current environment. It's hard to find a desktop application today that isn't written using Electron or a similar Web engine for the GUI layer.
Not only is it more fiscally efficient for businesses to consolidate their engineering skill sets, but it reduces the technical liability that needs to be tested.
That said, Electron sucks - so why don't companies use native GUI libraries? Because they are hard to use and unstable (Windows WinUI is a great example).
An abstraction layer to offer a stable consistent GUI API ensures applications are stable while the burden of maintaining stability rests with the abstraction.
> Or hire a mix of developers with different skillsets to achieve better quality?
If we look at the mobile ecosystem as a case study, apps which are available on Android and iOS are most often build with a UI abstraction like React Native or Cordova (WebView/WebKit).
Seldom are native apps for both platforms developed. This is for various reasons - anecdotally my previous employer had dedicated iOS and Android teams comprising of 1 person on each team. We had roles open for 12 months, then the Android developer left so the iOS developer had to learn Android development. They managed to hire a new Android engineer after 18 months.
Overall - if making a UI for all operating systems was as easy as consuming a crate/package into your Rust or Go project and building a UI - we would see a lot more efficient native applications.
"We’ve been listening to feedback from developers around the world about what will be most helpful to them as they build innovative apps"
Lol, the feedback is surely "stop deleting all your documentation without replacing it" and also "please don't make me re-download Xcode for 3 hours using an account I forgot the credentials for in your terrible app store with its unresumable download flow... before I can do anything", but they came up with this?
"Make it so I don't contemplate self-harm and/or abandoning my life to live in the woods every time I need to update XCode" would indeed be a big improvement. IDK WTF they're doing wrong with that but god damn.
Not really. The App Store installation first scans the entire bundle before installing the bits it needs, then it downloads the update and applies it, which goes through some not-very-optimized installation code that compresses the bundle on disk using zlib. This is ok for normal apps but for Xcode this can take a while. Blowing away the entire directory and just installing a fresh copy is usually far faster, if you optimize this you can do it in under five minutes.
Is there a reason that these big installations of OS "components" aren't just distributed as APFS .dmg files, where the (pre-compressed) APFS volume in the disk image just gets shoved into your OS APFS container and wired up to automount at its directory mount-point?
(Basically like how Ubuntu's Snaps work filesystem-wise; but interacting directly with the logical-volume manager to create volumes, rather than keeping the disk image around as a file in your filesystem.)
For that matter, given that the APFS OS volume is read-only, is there a reason macOS hasn't yet transitioned to the coreOS model where OS updates just are just Courgette-alike binary diffs that construct a new OS volume beside the old OS volume atomically by stream-merging the old volume with the patch, and then blessing the result? Or the game-console software update model where the base-images of things are immutable, and instead updates are their own read-only volumes that get overlay-mounted on top of the base images when you mount the base images? (I know macOS can already do the latter for security hotfixes; it's strange that they don't use that capability for regular updates.)
Xcode is not an OS component, but it could certainly be distributed as a APFS disk image that could be union mounted (this is actually how the watchOS and tvOS SDKs work today, plus Apple does this internally). I suspect they use XIPs to get that signature (which, tbh, is kind of useless) and compress it hard, but IMO these tradeoffs are not great. I have a long-term goal of writing out to a disk image myself, but my motivation would be to bypass filesystem performance bottlenecks when decompressing the archive.
> For that matter, given that the APFS OS volume is read-only, is there a reason macOS hasn't yet transitioned to the coreOS model where OS updates just are just Courgette-alike binary diffs that construct a new OS volume beside the old OS volume atomically by stream-merging the old volume with the patch, and then blessing the result?
To my knowledge this is pretty close to how updates work today.
> To my knowledge this is pretty close to how updates work today.
But isn't the key advantage of coreOS's model, a sort of green/blue deploy model for the OS — i.e. that it can write out the new updated OS release in the background while the previous release of the OS is running; and then, when it's done, "update" by just rewriting the EFI boot list to default to the new release — without even needing to reboot to perform the update, instead just saying "the next time you reboot, you'll be booting into the new release"?
There's no reason that an "OS update" under this model, should ever be a thing that takes over your whole computer, and then sits around with an "updating" progress bar, blocking startup. But that's what macOS does.
I think your intended meaning, was that the current model involves a binary diff that gets used to patch the OS volume, while the OS is booted into the recovery volume. Which, yeah, uses kind of the same abstractions — but doesn't give any of the key advantages.
> "please don't make me re-download Xcode for 3 hours using an account I forgot thee credentials for in your terrible app store with its un-resumable download flow before I can do anything", but they came up with this?
I'm glad I'm not alone in that experience. Why the hell do I need an account to get developer tools in the first place?
How does that have anything to do with requiring users to have an account to download software signed by Apple from Apple's servers? That doesn't make a lick of sense to me.
This problem was solved years ago with code signing.
Running unsigned code requires several hoops, even running signed code which isn't Apple Approved requires telling the OS that you know what you're doing, twice.
Running signed code which has been altered, such as a hacked XCode, isn't possible, as far as I know.
If this was the reason developer accounts were required, it no longer is. From Apple's perspective, there's only upside in requiring them, which is the most likely explanation for why they do.
Technically you don't, there's an unauthenticated endpoint discovered recently that lets you grab their tools without requiring credentials. But it's annoying to use :(
It's absolutely not. Apple desires quick and easy fixes. Devoting time to good documentation, product support, caring about bugs, and devrel ... not gonna happen.
Friends might be apple developers instead of just developers trying to do something unrelated and randomly discovering they need to download Xcode to do something :(
Not sure exactly what you mean, but everyone can choose to either download Xcode via MAS or https://developer.apple.com. I think I tried it with MAS once about 7 years ago and have never done that again since.
It’s pretty normal that if you want to use the developer tools on a platform and you are not a developer for that platform, you are going to have to figure out how to install the tools.
I was in this position just recently where git suddenly stopped working, due to needing a complete update of xcode tools. Annoying blocker but OK, let's get it done.
But trying to download the xcode tools put me into a loop which wasn't completing for some reason. After several attempts waiting for it to download and install I gave up and created an alias 'git' which points to my brew install of git (in usr/local/bin I think).
When you try to install git it forces you to install Command Line Tools for XCode (whatever the f that is) which can take an unknown time to download, force you to accept a license and breaks, and force you to reinstall them at least once a year (or randomly the next time they break something)
Did you know that GCC take an unknown time to download, and forces you to accept a license?
I think it’s pretty common knowledge that Macs are sold as consumer machines that don’t include a full tool chain out of the box. Guess what - it’s free to download and sometimes it gets updates.
It’s hard to understand why you are making such a fuss about installing developer tools on a developer machine.
Sometimes I find I have to install gcc or clang or llvm on a Linux machine in order to install some other package. Why would I moan about this?
> Did you know that GCC [...] forces you to accept a license?
No it doesn't. The GPL is only relevant if you plan to distribute GCC, and you are never made to affirm your agreement when downloading, installing or using GCC. GCC never prompts you with any "click agree to continue" bullshit.
> Prompt or no prompt, if you use GPL software, you are forced to accept the GPL.
No prompt, no forced acceptance. You are simply wrong. The GPL permits all use, it has no restrictions on use. It restricts only distribution.
> This is no different from Apple’s license, which also allows you to use the software freely unless you want to redistribute it.
You are wrong. You didn't read Xcode's license. I did, it places substantial restrictions on how and where you can use Xcode, not just restrictions on distribution.
Limits on distribution are limits on use. If you don’t understand that, I suggest you Google for some discussions about why many people don’t use GPL’s software - it’s because the limits on distribution affect their usage.
Fair point about the XCode license being more restrictive than I said.
As you can see from the other replies here, it's not just me.
XCode presumably works fine if you work with it daily. What I can't fucking stand is having to download it to do something unrelated to it (and, lol, how it decides to be the terrible default editor for every file that's even vaguely related to code and then I have to go update all the file associations).
I especially hate that you have to download a second copy every year for the Mac beta. Especially when you have no desire to ever write Swift or Obj-c code in your life, like most of us.
Yep. How expensive would it be to hire some tech writers? There was a time at the company (okay, it was decades ago) when writers (like Scott Knaster) were considered important-ish employees. The company had a heck of a lot less money back then, so what's the excuse for not doing this now?
Honest question - why do you all put up with this nonsense? Of all the companies you can invest huge amounts of time deving for, Apple seems to be the one that makes life the most difficult.
Even the annual "Developer License" is absurd... and the revenue such licenses generate is trivial.
Some will argue iOS is where the money is at... and that is true... but just think about it. The money is on iOS because you are putting up with Apple's absurdities!
If more of you stopped putting up with this nonsense then either Apple will have to change or another platform will become where the money is at... it's that simple.
Steve Balmer chanting "Developers, Developers, Developers!" comes to mind. Microsoft realized early on it's 3rd party developers would cause Windows to sink or swim, and by most accounts developer platforms and tooling coming out of Redmond are really good. Why put up with this stuff from Apple?
Well it's because Windows, and especially development on Windows, is total fucking garbage. I complain about apply but holy shit at least they don't try to put ads on my start menu.
(And Linux is infuriating for other reasons, like not having the sleek and snappy UX of Mac). Of the three, Apple is my favorite. Still think the company is weirdly incompetent at totally basic things, though. Like all API design. I will never do Apple-specific development for that reason, but I prefer it for general purpose work.
Because for some reason many people haven’t gotten over their addiction to food and shelter nor have they found a legal means to support their addiction besides trading labor for money.
> Steve Balmer chanting "Developers, Developers, Developers!" comes to mind.
Yes and because of Steve Balmer’s great leadership, MS was able to conquer mobile like they were able to conquer the desktop. I see where you are coming from, why don’t people just develop for Windows phones?
> If more of you stopped putting up with this nonsense then either Apple will have to change or another platform will become where the money is at... it's that simple.
You really think that if every developer who writes iOS apps and posts to HN stopped that anyone would care?
I stopped too, after they threw back some of my reports because they were missing some completely unrelated generic diagnostic info (like which MacBook generation was I using, even if the bug was 100% reproducible everywhere), even though I’ve provided them a minimal working example on GitHub, and even the method name of the problematic private API.
Gonna ask the Devs if they thought about domestic violence and the ethical implications of their work whilst they coded a bunch of features and tech that enables it. Tracking through keytags, deleting messages, payment control. I'm gonna guess that one goes unanswered...
- The documentation could be improved a lot - with examples ideally.
- The App Review process seems to flag a number of the same issues which are subsequently resolved after sharing a video that there is already compliance. This could be improved
- Showing specific error messages - I think this is somewhat Universal but Apple gets it wrong far more often. For example if you don't accept an Agreement somewhere in App Store Connect, you will just see a random error when you try to test In-App Purchase and some developers may think it's a problem with their code when in fact it's something else entirely. This wastes time and can be incredibly frustrating and demoralizing. Also the In-App _Purchase sandbox user flow is needlessly complicated.