Here is some context. There are two collections of frameworks available for iOS developers. The private frameworks cannot be used by non-apple applications. In some cases, this restriction makes it impossible for an App developer to develop an App that has the same functionality as the corresponding Apple app. Just to pick one example, the Music App has a download-to-device option (a cloud with an arrow) which allows users to move cloud-stored songs from their iTunes library onto their device. This functionality is not available in the iOS SDK.
In my opinion, there is legitimacy to the complaints being investigated.
I get reminded of this the most while driving and using Google Maps on an iPhone.
I've definitely had several close calls in traffic, with faceId requiring me to type the password, switch back to the maps app etc, since google maps can't stay open while the phone is locked like apple maps.
I think it's a pretty serious dark pattern when you consciously make an app unsafe for your user.
If their's a setting I'm missing to allow Google maps to stay on the lock screen, I'd love to know.
To clarify - The difference between Google Maps and Apple Maps:
If the phone is locked and navigation is in progress, on Apple, the active map shows in the lock screen. On Google, you would need to unlock the phone, and switch back to the Maps app.
Of course (and to be fair) if you don't lock the phone and leave the maps app focused, both Google and Apple will stay in view.
I've found that on longer drives where the maps app isn't needed, the phone will end up being locked/away, and when you do need a direction, that's when the API difference that I mentioned above clearly shows up.
Apple is definitely holding that API to themselves, with a side effect of making a more dangerous interaction (however un-ideal) for the user.
How you drive your car is your responsibility. Navigation or not. If you kill someone or get them handicapped it's on you. Be considerate. Safety over everything else man.
> I've definitely had several close calls in traffic, with faceId requiring me to type the password, switch back to the maps app etc, since google maps can't stay open while the phone is locked like apple maps.
You’ve had several close calls due to using your phone when you shouldn’t, putting others at risk. That sounds exactly like the definition of unsafe driving (and the strongest plausible interpretation of what you said).
> I think it's a pretty serious dark pattern when you consciously make an app unsafe for your user.
Nobody at Apple is making an app unsafe, but you are choosing to make the roads unsafe by using an app and interacting with your phone while driving.
It’s not against HN guidelines to call out incredibly unsafe behavior, even if it is the context for complaining about API differences.
I don't think anyone was debating that. It's more that apple is deliberately making it harder for Google to build apps that in turn make it easier for the customer to drive safely, for reasons of platform control and, ultimately, profit.
Why do you need the app to stay open while the phone is locked? I don't use Google Maps, but when Waze is open it keeps the screen on and the phone unlocked.
Not on an iPhone, but on longer drives, I will lock the phone to turn off the screen to conserve power and reduce distraction during long stretches where I don't need direction. It's nice when you can get back to navigation without unlocking.
If one absolutely must use a smartphone in traffic the only right moves to make after a navigation app stops working is to either ignore the device and continue on your way without it (seriously, can nobody navigate without these devices any more?) or to ignore the device and find a parking spot someone where you can sort it out.
No matter what that dumb smartphone does, it cannot make you have close calls in traffic unless you are acting like an utter moron. It can't reach out and grab the wheel, it can't slam the brakes, it can't block your field of vision. YOU ARE IN CONTROL OF THE VEHICLE.
This bit bears repeating: fiddle with that damn device and you will end up killing an innocent person.
>...ignore the device and continue on your way without it (seriously, can nobody navigate without these devices any more?)...
I can, and I'm sure most people can reasonably get around without on if they're familiar with the area. Towns and cities with a grid layouts and numbered roads means that most people can probably find an address if they get a cross, but most of the US is not laid out in that manner. It's doubly frustrating when you hit a neighborhood called Winding Oaks, and every road is Winding Oaks Trail, Winding Oaks Lane, Winding Oaks Circle, Winding Oaks Road, etc.
However, no, I probably cannot get to a location if it's in an area without a grid layout that I'm unfamiliar with. I could probably get reasonably close if I reviewed the directions beforehand, but with turn-by-turn navigation, there's a good chance that I will not have done so with detail.
For the record, I'm not condoning using a phone while driving. I was only addressing the point of people not being able to navigate without modern navigation.
While visiting Turkey a few years back I witnessed amazing incidents:
- The bus I was on was driving really slowly (walking would be faster), to the point the locals started getting frustrated... and told him to get off the phone: He was texting constantly.
- A driver of a 'biskilet' (an electric moped) had his phone jammed under his open face helmet so that he could talk white riding. I saw quite a few other riders with phones in their hands...
As an aside: I've also seen cops in my country (Oz) using phones while driving, despite being illegal.
I don't use Google Maps, but Waze stays open just fine. As long as it's focused, my screen stays on and my phone stays unlocked. I don't understand OP's phrasing. They seems to be saying they want to use maps while the phone is locked, which doiesn't make any sense to me.
Apple Maps on iOS will actually display the ongoing navigation on the lock screen. That's what the user is asking of for Google Maps but currently it's restricted to Apple Maps. The main advantage is saving battery life since the screen isn't on in the lock-screen mode except preceding a change. Also, if a passenger is using the phone (e.g. changing the music) and accidentally locks it you still have access to navigation.
>The private frameworks cannot be used by non-apple applications. In some cases, this restriction makes it impossible for an App developer to develop an App that has the same functionality as the corresponding Apple app.
How's this any different than Android, where some functionality is gated behind permissions that require signature or signatureOrSystem[1]? You could say that there's rooting/LineageOS, but those are out of reach for most users, and are entirely at the whim of the manufacturer.
Microsoft was attacked for the exact same thing 2 decades ago. If you make a platform, you shouldn't have any private APIs that only your applications can use, in my opinion.
I think there's a reasonable exception for some built-in applications that manage core services, but that privilege should be used sparingly and for clearly benign or user-friendly reasons. It shouldn't be used to gain a competitive advantage in revenue-generating applications or services.
Hmm, after writing the above it occurred to me that cloud storage like iCloud might have to be an exception to that rule for pragmatic reasons. iCloud is clearly a competitor to Dropbox, but it is also used to store backups of the phone's system settings and such. On the one hand Dropbox should be able to compete fairly against iCloud for offline app data storage, but I don't think it should have access to do backups of phone system settings.
I suppose the way out of that conundrum is to ensure that any use of iCloud for system related storage should not be part of a commercial service offering, which is sort of how it works as you can do that on the iCloud free tier. Still, it's an interesting edge case that shows how tricky these questions can be.
Because then it could read the phone's system settings, which could have dire security and privacy implications. It would also presumably need the ability to change them, because otherwise how do you restore the backups?
FWIW Apple encrypts all the data with your encryption key. So even if you swapped it out with a consumer solution like Dropbox that wouldn't make it less secure. It would make it more expensive for Apple to maintain that connection & increased customer support since people would complain to Apple when Dropbox had an issue.
>Microsoft was attacked for the exact same thing 2 decades ago
Can you elaborate on this? Windows isn't sandboxed, and there's no approval process, so I don't see any reason why a program can't use private Windows APIs.
That's mostly true but not absolutely so. Windows kernel space needs signed-code in 64-bits (except in a configuration only suitable for testing during dev), and MS very much makes use of internal undocumented and changing API to implement various high level features in a way that gives them a virtual exclusivity by the mere fact they are working at a level such that no competitor can even appear, or if a competitor do appear it will have the greatest pain to make a correct use of undocumented API and the competing implementation might not even continue to work after applying even security patches. Look for example at WSL: while it is very very cool and useful, no third-party can (at least in practice without MS collaboration) write a competing implementation. The same happened throughout the history of the dev of windows in various degrees and fields, and MS even has been found guilty of violating various anti-trust laws despite arguing in court that bundling disputed functionalities was a necessity of the design of their OS (they sometimes eventually managed to release extra stripped ISO extremely minimally modified compared to original ones to comply, making it clear that they are technically way better than what they argue in court...)
So it's a mere question of size and market share -- and it is not possible to reason from pure logic and as if it happened in a vacuum: the reason why they should not have an absolute unconditional right to design their exclusive features by implementing them using internal-only API is simply because they are a gigantic corporation shipping a behemoth OS used on a ton of computers and that would allow them to in practice and because of the clear advantage of maintaining the two sides of APIs extinguish any competition in the field they want on their platform.
Are you suggesting Microsoft (and other OS vendors) should be obligated to document all of their APIs? What constitutes an API and how is it different than private functions?
Besides, they already provide documentation -to an extent- by providing symbol files.
Am I saying that? No, but the GP specifically did.
It only matters when you have something like a monopoly. The issue with Microsoft was that they leveraged their operating system monopoly to create a monopoly on desktop office software, and part of the way they did it was by using secret, private, undocumented, proprietary, whatever you want to call them, APIs or features built into Windows for Office. A company is not allowed to give itself an unfair advantage when they have a monopoly to spread to new markets. That constitutes abuse.
Not sure about your question about private functions, because that’s a feature of OOP and not really relevant.
When Microsoft comes out with a new version of Office that works with a brand new version of Windows using features of their competitors did not know existed, I think it’s pretty obvious why their competitors are unable to have a product on the market in a timely fashion using those functions. Again, that’s only relevant if they have a monopoly on a market. Of course, a company is not otherwise required to help competitors do anything.
“I have decided that we should not publish these extensions. We should wait until we have a way to do a high level of integration that will be harder for likes of Notes, WordPerfect to achieve, and which will give Office a real advantage . . . We can’t compete with Lotus and WordPerfect/Novell without this.” - Bill Gates, 1994
Just to be clear, you are free to download your own streaming service's music. You just cannot download iTunes music–you must stream it. So this only applies if you're making an app to play music from iTunes.
Yes, you are right. But the point is that it is impossible for a third party to make a music playing App that plays music in a users' own iTunes music library and that has all the functionality of the corresponding Apple app. Note that I just chose this example because I am familiar with it. There are many "private" frameworks, all of which (a) offer functionality and (b) are off limits to non-Apple apps.
No it cannot: there is no way to get the URL of the asset if it is stored in the iTunes library on the cloud. There is at least one open bug report about this issue.
In my opinion, there is legitimacy to the complaints being investigated.