This. Just say you want to use UserDefaults for theming and setting languages… if you can‘t justify an API being used in written form, you shouldn’t use it.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Developers Required to Justify Use of Some APIs in Latest Move to Boost Privacy
- Thread starter MacRumors
- Start date
- Sort by reaction score
He probably means he is already in the habit of jotting down his reasons in the code so it would not be too much extra work to put together an explanation for Apple.
Actually, as a consumer I want companies collecting as little information as possible about me. Indeed, I think they should pay for the privilege of collecting my personal information. I'd like the same to apply for web sites, but I recognise I am in a minority with this view.
I'm pretty sure Apple has said in the past that UserDefaults in the preferred way to store user settings vs writting something to the disk, why did they changed this?
Also:
- The free disk size API, so you can't preemptively tell the user that you can't write big files? You need to show an scary privacy warning first?
- systemUptime. Oh boy, that's considered the "proper" way of getting deltas, I use it for animations for example, there's also a bunch of performance code hidden in many apps. How the hell can you explain such technical details to an user?
- the file timestamps. Again, I use it to double check everything I create on disk is fine, and do a cleanup if something weird happened. Do I really need to explain such technical, borderline paranoid reasons to an user?
Also:
- The free disk size API, so you can't preemptively tell the user that you can't write big files? You need to show an scary privacy warning first?
- systemUptime. Oh boy, that's considered the "proper" way of getting deltas, I use it for animations for example, there's also a bunch of performance code hidden in many apps. How the hell can you explain such technical details to an user?
- the file timestamps. Again, I use it to double check everything I create on disk is fine, and do a cleanup if something weird happened. Do I really need to explain such technical, borderline paranoid reasons to an user?
You probably don't understand the extent UserDefaults is used in even a small app, much less a corporate monster.
Is this justification also going to be shown to the user like in the camera permissions?
Users aren't stupid. Stop acting like they are. The language you used above is fine, and, as I understand it, you have to explain to Apple, not consumers. If you did make things clearer to consumers, I do not see how that could hurt. Indeed, I'd like to see more informative error messages. The 'Oops - something went wrong' error message approach is really beginning to annoy me.
Are you a programmer? Because something I got reprimanded pretty early in my career was about being too technical to the user
Yes, many users get easily scared if you go too technical and start demanding more explanations that they would still don't understand. There's a reason those generic errors exist
Maybe - I bet they have some Grade A decompilation techniques. They invented the language/compiler/apis/libraries/instruction sets/chips….
Beginning? lol. It has been annoying for many decades.
I'd also add the "Unexpected error occurred" error is another pet peeve. If you are trapping the error, at least give more information.
I've worked on several apps in the App Store. I can't think of a single one that didn't use User Defaults in some capacity. I can totally see justification required to use cross domain User Defaults, but I've only ever used that so that an app extension (like a Notification or Share Extension) could talk to the main host app-- never across apps. If this level of justification is needed for simply using User Defaults, even in capacity for talking across domains like in the case highlighted, then the rule is absurd. If there is concern with using User defaults as is, there needs to be API changes to User Defaults itself to prevent undesired cross-talk between applications. Otherwise, requiring explanation for using User Defaults api as it stands today is like requiring explanation of why an iOS developer needs to use SwiftUI or UIKit.
And push Apple to find new ways to restrict access to APIs and give users more power over accessing information.
Yea; though when I once proposed “Stop being stupid and read the instructions” it didn’t make it through the approval process.
Right. I've got no idea why this is problematic. It's the oldest, simplest way to store basic settings about your app. And those settings are sandboxed already. So, I don't see how this could be manipulated. I mean, this has got to be one of the most widely used APIs since the dawn of iOS. Could someone else share some info about why this would be a problem?
This is what I don't understand
Again, UserDefaults is the preferred way vs let's say, a json written to disk. If you need to justify UserDefaults, then you'll just write a json to the disk, but what's the point?
If they want to avoid fingerprinting, why don't restrict cross-domain use instead? this is so bizarre
Genuinely curious, do you have an App Store inexplicable rejection story like so many others seem to have? I hear all the time of rejections that sound like the person (if it even is a person) on the other end didn't even understand the basic purpose of the app. Twitter and similar being regularly stopped in review for "adult content" being just one high profile example.
Apple seems to require detailed approval for a lot of things which is fine if the system works. I just hear a lot of stories of the system breaking in basic ways that it shouldn't which have nothing to do with security and more with enforcing Apple's business objectives.
Yes, across an app-group... app-groups are owned by the same company. So, FB can't share user-settings with Twitter, for example. But FB could share settings with Insta, because they are owned by the same company.
It's user settings. It's a simple place to store basic data. Still don't see how this is some kind of fingerprinting thing.
Should be interesting what to see what they give for Threads.
I wish Apple would provide an official API that any app can use to continue running in the background without being suspended. Right now apps like Blink shell have to use the location API to avoid being suspended or killed in the background when doing things like SSH tunnels. This is a hack and something I could see Apple coming down on in the future.
Ah... you're expecting 100.0% perfection 100.0% of the time. In a world where that rarely exists (gravity being a good exception).
In 2022 alone Apple rejected 1,679,694 apps for privacy/security/fraud issues. Leaving 1,788,322 apps in the App Store that passed.
"The Apple App Store was once the example of quality apps compared to its Android counterpart. Now it just feels like Android Junk."
Apparently you have data to support your above assertion. Please feel free to share it.
Something that pisses me off about the systemUptime thing
Yes, I can totally see how it can be used for fingerprinting
But the vast majority of use is legitimate for getting deltas, even Apple uses it in their code examples
Pretty sure Apple has already identified bad actors, but, instead of calling them out and punishing them, they decide to punish everyone else, knowing pretty well they'll keep fingerprinting while the majority of developers will start looking for other solutions
Yes, I can totally see how it can be used for fingerprinting
But the vast majority of use is legitimate for getting deltas, even Apple uses it in their code examples
Pretty sure Apple has already identified bad actors, but, instead of calling them out and punishing them, they decide to punish everyone else, knowing pretty well they'll keep fingerprinting while the majority of developers will start looking for other solutions
There is one good thing. Seems to have little to no banking trojans compared to Google Play. But that's more to do with the system permissions than with the App Store. From what I hear from developers and see on the Store itself, it seems like their policies are more to do with protecting their legal and business interests than with app quality anymore.
One of the biggest reasons Apple will never forgive Epic is the way they publicly embarrassed them by switching out the in app payment system and demonstrating that it was possible.