Apple introduces Ask Apple for developers
apple.com
apple.com
- 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.
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 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.
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.
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 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 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 :(
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.
https://lux.camera/pro-camera-action-introducing-halide-mark...
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.
HN thread on it: https://news.ycombinator.com/item?id=24860043
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.
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.
I've literally never heard of this, and I've had several repairs via the genius bar.
'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."
Am I right to assume, he's always been the most vocal about this?
https://en.wikipedia.org/wiki/Right_to_repair#History_of_the...
He's a relatively recent proponent. The movement's roots are automotive and agriculture (where John Deere is their Apple).
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?
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.
(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.)
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.
Honestly, the major annoyance is paying $120/year while Google only charges a one-time $25, but it is what it is.
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.
Plus a lot of my stuff is locked up with them and I don't have the time to migrate all of it right now. Specifically, music is a big issue for me.
I guess I can only hope we fix these problems before everyone starts putting "smart" contacts in their eyes.
Because Apple practically has unlimited resources and power while Linux and its ecosystem doesn't?
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.
Anyone claiming that it is getting worse is making an extraordinary claim that needs data to support it.
"Nothing is better than smoking" ;)
And before someone chimes in, yes I have used both the PinePhone and Purism platforms. They are promising, but not a suitable replacement yet.
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.
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.
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.
He or she never said that. He said that if you move away from apple, all your problems with apple are gone and you can relax.
So you can basically translate it to: "if you all are so angry with Apple, then why do you keep developing for Apple?"
(to which the answer of course is: money)
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:
Don’t throw the baby out with the bathwater.
"Deprecate your shitty XCode IDE, and partner with Jetbrains. Give us a solid editor just like what Google did with Android Studio"
Visual Studio is amazing for GUI debugging, and not much else.
For large C++ codebases with some meta programming, these are all fairly bad at code completion and refactoring.
VSCode is getting better though!
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.
No? No answer?
Funny that.
It’s called using the forums.
They reply once in a blue moon and never follow up on bugs.
"Why do you hate us so very, very much?"
but it looks like Google and Apple require you to use Kotlin/Swift to create UIs
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.
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.
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.
I would imagine these would be like 99% of devs questions.
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?
(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.)
> 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.
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.
lmao
https://twitter.com/fobwashed/status/1575943899478380544?s=4...
This is true for Linux and Windows too.
Downloading the command line tools package is just a convenient way to get everything, which is why people recommend it.
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?
Why do I need GCC for git?
> Macs are sold as consumer machines that don’t include a full tool chain out of the box.
It wasn't that long ago that Macs had server software out of the box.
Still doesn't explain why I need to download 670 MB of something to install otherwise separate tools.
And why the hell things like git break when XCode upgrades a version
You don’t - but you do need it on Linux to install certain other developer tools. There is nothing unusual about having to install developer tools.
> It wasn't that long ago that Macs had server software out of the box.
So what? Are you saying you didn’t realize MacOS is now aimed at consumers?
And yet, only in MacOS I need to install 670 MB of junk to install, say, git. Why?
> Are you saying you didn’t realize MacOS is now aimed at consumers?
This doesn't explain why I need to install 670 MB of tools to install separate developer tools that are not even Apple's.
With all due respect, it’s very unclear why you are experiencing so much pain over this. It really isn’t a big deal.
I agree that if there is a bug that causes a download to get stuck in a loop, it should be a priority for Apple to fix it.
However that isn’t what you are arguing.
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.
This is no different from Apple’s license, which also allows you to use the software freely unless you want to redistribute it.
Prompt or no prompt, if you use GPL software, you are forced to accept the GPL.
And really? Your complaint is a click to agree to a software license? Why does that upset you so much?
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.
Do yourself a favor and read this document, since you obviously have already agreed to it without reading it: https://www.apple.com/legal/sla/docs/xcode.pdf
Fair point about the XCode license being more restrictive than I said.
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).
This will bite me somehow very soon, I'm sure.
The question of "why the he'll do I need to download 670 MB of unknown junk before installing tools that are not even Apple's" remains
Honestly if having to download some tools is your chief complaint about their developer experience, they must be doing magnificently.
https://developer.apple.com/xcode/resources/
The download button gives options website or AppStore.
1. Use DevCleaner[0] to remove old/unnecessary device support files.
2. Remove platforms you don't develop for, e.g.
- rm -rf /Applications/Xcode.app/Contents/Developer/Platforms/Watch*
- rm -rf /Applications/Xcode.app/Contents/Developer/Platforms/AppleTV*
DevCleaner freed up 10G+ for me the first time, the two rm commands above free up ~3G each.
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?
Because there is a history of rootkits being embedded into development tools.
https://9to5mac.com/2015/09/20/xcode-ghost-app-store-malware...
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.
I installed the MAS version years ago and it seems to auto-update just fine for me.
When there is a beta, I install that from developer.apple.com and the two work just fine on the same machine.
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.
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?
> 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?
(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.
Apples software quality is pretty shitty these days
Ah well, this JIRA field was empty can’t do anything about it. WONTFIX