It's considerably rare for me to do this, but I'll advocate for the devil in the white suit.
Imagine you added support for a device that's not out yet, that you probably don't even physically possess (unless you're a heavy developer, and even that's probably a pre-release model), but that you're assuming will readily accept your updated app. Except when finally the device is released, it turns out the support you added for the new device was imperfectly applied, frustrating the experience of users everywhere who are used to this app working just fine on other devices but not this one.
Now imagine this happening with multiple apps, perhaps because the developer documentation for the device was an inferior match for reality, perhaps because the documentation was consistently mis-interpreted, perhaps because the emulation in development was slightly inaccurate. Whatever the cause, a vast lot of supposedly compatible apps are very much not.
Which product's image is harmed most by this outcome?
True, Apple's stated reasons are even simpler and more sensible: you can't advertise compatibility to a pre-GM application or device. That's part of the rules, and explicitly stated in the original rejection message.
GM stands for Gold Master I believe. Apple's concern therefore isn't that the device isn't out yet, it's that it's not finalized, and they don't want an app update to say that it supports something which isn't finalized yet because it could change tomorrow (even if that's unlikely).
Devs can still try to support the XR, Apple is just saying don't claim to support it. That approach is often described as "under promise and over deliver" (and generally works better than the reverse)
This entire thing is based on the author missing and still never noticing after writing this entire rant up the key term in the initial rejection:
> Apps with compatibility references to a pre-GM version
Apple didn't say you can't mention the iPhone XR, they said you can't claim compatibility with it yet... the author went through some great lengths to play up the absurdity of Apple wanting to keep the model under wraps and it's pretty clear that was never what they were asking
Combined with childish behavior and trying to follow the letter but not the spirit of the rules. A great idea if you’re being judged by a computer, a bad idea if you’re requesting a person to re-review your app.
Why not just state ‘compatibility updates’ and nothing else?
Because had OP done that, then wouldn’t have been able to write up this childish screed I just wasted time reading as well as everyone else and thus make a total arse of themself, and waste app reviewers time because OP can’t be an adult.
A fun read and on the face of it, Apple's stance does seem obstinate/bizarre... but on the other hand, with my testing hat on: how can you claim to support an unreleased phone? There's not even a cloud testing service yet...
> It merely translates the iOS calls into OSX ones
That is not an accurate description of what the simulator does. It is a separate userspace running on the same kernel, in this case the iOS userspace running side-by-side but isolated from the macOS userspace.
The simulator uses entirely iOS binaries, built for x86/x86-64. This includes UIKit, Foundation, libc, libdispatch, etc. It does not use the macOS ABI, nor the macOS libc/Objective-C/Swift runtimes. Each individual simulated device is its own isolated mach bootstrap, with its own separate launchd, daemons, and XPC services.
With the exception of a few libraries like the syscall interface and libpthread, which are tightly bound to the kernel.
And still, the simulator is not the same as running on-device. Much of the iOS security model is non-existent in the simulator. If you’ve ever written an AppEx using a shared container, you know that. (Or you’re running to verify your code works on-device right now)
The simulator has to render the screen via the macOS display device, and I can tell you my trusty Radeon 5870 is only up for rendering about 5 frames per second in the simulator.
I’m pretty sure any Metal apps will be wildly different in the simulator.
I don’t even consider myself an expert iOS Programmer at this point, and I can come up with three examples off the top of my head. I’m sure there are plenty more. And there’s a reason every single iOS library or widget on GitHub requires all bug reports to be made only after testing on-device.
It's even worse: one of each device for every OS version supported, which Apple themselves make exceptionally difficult as it's nearly impossible to downgrade to older OS versions.
Ok, but for many apps the only thing that really changes is the new screen size. For example, I will be pushing out updates to my app without testing on the new devices themselves, since it really does not rely on any new features.
Yep, Luc's own app was previously approved with Mojave mentioned in the release notes, then rejected later by Apple for mentioning it. It seems to be the luck of the draw, depending on which reviewer you get and how strictly they want to apply the rules that day:
"Fly the pirate flag, toss a hammer at Big Brother, think different — just don’t violate Section 3.2 of the Program License Agreement, and communicate to your users words that are on a billboard you drove past on your way to work. Be a rebel, but somewhere else."
Apple seemed to be very reasonable here—they reached out to the developer sensing their frustration with advice on getting their app approved. Seems to me that apple wants to help this to get approved by investing the effort of calling the developer. Remember all the complaints about how apple doesn’t communicate with developers? Seems like they’re trying to do better and I never saw any angry app updates. I mean maybe the policy is silly but there’s better ways to protest than passive aggressive release notes that would confuse the users. I mean there’s a lot of disagreeable things Apple does but is this really the hill you chose to die on?
Part of it could be legal. I don’t want to say this is likely in any way, but the bottom of every XR page says this:
> iPhone XR has not been authorized as required by the rules of the Federal Communications Commission. iPhone XR is not, and may not be, offered for sale or lease, or sold or leased, until authorization is obtained.
It could be that they aren’t wanting to imply that they’ve given out review units or other demo units in violation of not having approval.
I’m not saying it’s super likely, but it’s also not impossible.
This is the only reasonable explanation. If they fail to release it for any reason, they don’t want apps to mention a phone that never existed (especially if, say, they don’t have the rights to the name)
This is far from the only reasonable explanation. The reasonable explanation is that Apple doesn’t want devs claiming compatibility with a device that they can’t have possibly tested on yet.
An extremely fun read, but the obvious "solution" to this silliness is to simply write "added support for new display sizes such as the iPhone XS." and call it a day.
But I appreciated a look into what happens when you start pushing back...
I'd suggest that the policies are pretty childish, and anyone who has worked with the App Store before knows full well how completely arbitrary and insane it is--this should come as no surprise.
The Author of the article said it beautifully - I know that millions of people are battling every day for their dignity and their families and their lives. But, goddammit, this is a bridge too stupid, and I can’t cross it.
> But, goddammit, this is a bridge too stupid, and I can’t cross it.
And I am sure the customer care person at Apple found this so hilarious.
This is nothing more than a refined version of the idiots on YouTube squirting water guns at McDonalds cashiers. Because you know they deserve it for daring to work at McDonalds at the first place.
This comment seems to imply that you have a salary threshold where you deem it acceptable to make people's lives a misery just for doing their job... So what is it? $50,000? $75,000?
But the policies are clearly asinine. If those low level customer care employees aren't empowered to bubble up legitimate customer complaints then there's at least _two_ things here Apple needs to address.
> Fly the pirate flag, toss a hammer at Big Brother, think different — just don’t violate Section 3.2 of the Program License Agreement, and communicate to your users words that are on a billboard you drove past on your way to work. Be a rebel, but somewhere else.
Sure, he should leave the customer care team alone and speak with the higher ups!
How does one do that, exactly?
I think his particular battle with Apple is not the most worth, and it's not unreasonable of them to prevent you from claiming compatibility with unreleased phones, but please let's not forget we're talking about a company that does not even have a public bug tracker, and will close your tickets as duplicates without you being able to read or be notified about the other supposed ticket your is a duplicate of.
It's a totally opaque company that gives developers no resort to fix their issues. You can only talk with the lowest level support and you can only take it out on them (which you should do politely, of course)
The author tried real hard to paint this as some weird Kafkaesque attempt to keep the phone under-wraps, when really all it is is not being able to say your software is compatible with a device that isn't even out yet, and which you've done no testing on. The author comes out of this seeming slightly deranged.
I saw the humour in not being able to mention a publicly advertised and software compatible device. I'm honestly not sure how you think app development for new devices on _an existing platform_ works.
> The author comes out of this seeming slightly deranged.
That you think so makes me think you seem "slight" deranged by Apples guideline process. That's some next level stupidity where that corporate line of "hey, we have emulators for it, which are intended for you to test, but you cannot mention this in an update" makes actually sense to someone.
I'm not sure, since I have no idea of the rationale behind the rule. Might be because Apple wants apps to seem like they just "always work", rather than requiring them to be fixed for each release? In any case, I've heard people get around this rule with clever wording, as long as they don't explicitly mention the new hardware/software. For example, "dark mode support", "full screen display", etc.
lloeki elsewhere in this thread mentioned that Apple is approving some apps that mention Mojave in their release notes. Whatever the rule is, Apple isn't applying it to everyone.
I love a good story where the little guy stick it to the big guy. The double irony of this is of course that Apple used to be that little guy. In an alternate reality, Steve would have gotten wind of this and done something about it.
My theory is that Jobs' main task at Apple was to create theater to distract the press and business folk, so that Woz and the rest of Apple's technical staff could get some decent work done while nobody was looking.
The only technicality protecting Apple from massive anti trust regulations with regards to the store is that the iPhone actually isn't a monopoly in cell phone unit shipments.
However, many economists have noted that app revenues (not advertising) is highly skewed towards Apple's platform. When will a $100B app market stop being treated as a feature of physical phone unit shipments, worthy of its own independent regulation?
You're allowed to criticize things and continue to use them (in fact, I would argue that you very much should criticize things when they could be improved, regardless of whether you use them or not).
Especially in this case as I imagine a large part of his income is tied to releasing apps for ios devices, so he doesn't really have an option to just stop developing for apple.
If I believed that Apple were so arbitrary, strict, and controlling with their devices and App Store, I don’t think I would be deliberately trolling them with my app changelogs.
Imagine you added support for a device that's not out yet, that you probably don't even physically possess (unless you're a heavy developer, and even that's probably a pre-release model), but that you're assuming will readily accept your updated app. Except when finally the device is released, it turns out the support you added for the new device was imperfectly applied, frustrating the experience of users everywhere who are used to this app working just fine on other devices but not this one.
Now imagine this happening with multiple apps, perhaps because the developer documentation for the device was an inferior match for reality, perhaps because the documentation was consistently mis-interpreted, perhaps because the emulation in development was slightly inaccurate. Whatever the cause, a vast lot of supposedly compatible apps are very much not.
Which product's image is harmed most by this outcome?