In my opinion, there is legitimacy to the complaints being investigated.
In my opinion, there is legitimacy to the complaints being investigated.
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.
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.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> 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.
*Perhaps not in your specific country.
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.
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.
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 disabled autolock long ago though - so maybe that’s not how you’re supposed to use them?
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.
[1] https://developer.android.com/guide/topics/manifest/permissi...
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.
Why not?
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.
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.
Besides, they already provide documentation -to an extent- by providing symbol files.
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.
See: http://lowendmac.com/2008/rise-of-microsoft-monopoly/
“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
I mean it doesn't negate your point just curious whether this is a soft or hard limitation.
Apple's music app can stream music from the cloud or download it to the device for offline playback.
Spotify's music app can stream music from the cloud or download it to the device for offline playback.
Google's music app can stream music from the cloud or download it to the device for offline playback.
Amazon's music app can stream music from the cloud or download it to the device for offline playback.