Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the OS should provide the ability to select items and then give opaque handles to applications. The app could send a message to the OS to display photo selector. The OS could send a message back with a handle to selected photo. One could then asks the OS to send a handle, which would forward selected item somewhere else.


Both mainstream mobile operating systems have APIs for this. Even Linux has this at this point! Android has been restricting apps for at least a decade now, every time under heavy user protest because some weird app doesn't work anymore with the restrictions enabled.

The backwards compatibility of Android is a problem in this regard, because apps targeting old versions of Android get old, often less private, behaviour from the system to keep them working. Google has been forcing developers to upgrade their targeted version for a while now, though, so any app that still receives updates should be forced to use the modern API.

In the end, there will always be apps that need full media access. File managers, galleries image collage tools, you name it, you can't completely disable the generic file API. All other apps can use more appropriate APIs and often do, but those that hoover up data have little incentive to use the modern, privacy friendly versions. They're dragging every well-meaning app down with them through their terrible business practices.

I fully blame the advertiser laden crapware for the fact I can't sync my phone's clipboard in the background through KDE Connect anymore. The fact Google restricted the APIs instead of kicking the borderline malware out of their store irks me to no end and the fact Apple has placed similar restrictions onto their platform tells me it's not just Android.


iOS already has this feature precisely. I can either grant access to all photos or only a selected subset, or even just one.


And I love it, but it has two issues:

- Apps can refuse to work with that, like Google Photos (it used to work during the beta and it was perfect for me)

- Apps still offer their awful photo picker on top of your already-picked photos, so selecting new ones requires a lot of taps.

I wish Apple would reign in some of these apps. In-app browsers and custom photo pickers should be banned unless they have demonstrated advantages.


It's the same with location data. iOS allows you to restrict apps to only approximate location, but apps like YouTube TV and ESPN require precise data just to do region checking. I wish iOS just wouldn't allow apps to figure out if they're getting precise vs. approximate location.


It’s incredibly confusing when apps do this. Often, the symptom is that GPS looks broken.

GrapheneOS’s location services have a similar issue, but 100x worse. There, apps can definitely have lat/long, but not full Google location service, and all sorts of proprietary software ends up with no/wrong location dots on their maps.

Open source apps, and Google maps competitors work well, so I know it isn’t a hardware or radio issue.


> GPS looks broken

It’s a failure both on the app and Apple side to convey this information properly. Approximate location should be shown with a large circle and the user could be told explicitly about this.

Some apps really need exact location (think Uber and Google Maps) but many don’t (any social network)


Yeah, I had Snapchat location map enabled with imprecise locations during iOS beta, but they disabled that...like, why! just show the error bar on the map if you care.


If I had to guess, probably because some of Snapchat's revenue comes from selling your location data and the general location is far less valuable.


Yes, or better yet, UIimagePickerController [0].

It’s a hook for the system’s built-in image picker sheet — as such, it allows the user to browse their entire library, however the the app only gets (one-time) access to the individual piece of content they pick. Nice thing is that the app doesn’t need to ask any photo permissions at all (as far as read access is concerned).

With some exceptions like Messages, which presents a custom picker UI, this API gets dog-fooded by almost all Apple’s stock apps (Safari, Notes, Mail, the “iWork” office suite etc…).

An example of a 3rd party app implementation is MaskerAid by Casey Liss [1]. However, the amount of apps I’ve encountered that use this interface is suspiciously low.

The realistic answer is probably that the sheet looks pretty barebones, and most developers seem to prefer a sleeker, custom-designed integrated gallery view, and/or need write access.

But the paranoid part of me raises the question: why do so many apps insist on continuous access to at least a portion, but preferably the entirety of the user’s photo library?

0 – https://developer.apple.com/documentation/uikit/uiimagepicke...

1 – https://apps.apple.com/app/maskeraid/id1590163828


Apple recommends PHPickerViewController for this use.


I read that as "Apple recommends PHP."


They really need to implement this for contacts. The main reason I’ve never bothered using WhatsApp or any other third party messaging service is that they all refuse to work unless you give them access to your entire contacts database. No thanks.


I feel like this was introduced within the last couple years and did not get a ton of attention when it did.

But like many things with iOS Apple did this and apps had no choice but to work with it since (seemingly) as far as the app is concerned it is the same situation as before.

I do wish though it was easier to grant more images without needing to go to settings. I have had one app that somehow gave me the ability to add more images, but I am not entirely sure how it did it.


Or none, then the all would think you have no photos, instead of getting permission denied error.


Android does provide this. Your app can send out a message on the system: "i need a picture" and usually the built-in camera-app will accept the request, and send a picture back to the requesting app (which then does not need camera permissions since it, itself, never accesses the hardware).

This feature is actually quite foundational to the Android architecture, where the vision was a bunch of small apps working together in this manner.

Unfortunately it's a slightly more clunky user experience than what users these days have gotten used to: big monolithic apps that handle everything themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: