The biggest issue I have with this is the fact that, according to the article, Apple has arbitrary, non-disclosed limits on use of the Bluetooth APIs. If the app passes an "unknown" threshold, the app is blocked from using Bluetooth, and Apple won't even disclose those limits. How is anyone supposed to make a functional product in that situation? Imagine if an electronics datasheet said "if the product exceeds a certain unspecified temperature it will stop working for an unspecified number of hours...We know those figures, but they're proprietary and secret."
I fail to understand everyone saying "Tile, make your own app"... don't they have that already, and isn't that the issue here? That Apple is constantly changing the developer restrictions? It definitely smells bad for
any company to first restrict some product that depends on their product, and then almost immediately after offer that same product themselves. Many of the same Apple fanboys are the first to complain when their favorite show gets pulled from their favorite streaming platform, or when some book they paid for disappears because the service got discontinued, or...
And, for everyone who constantly repeats "it's Apple's platform", remember that most of the standards that have been truly successful were
open standards that, at the least, had fair, reasonable licensing provisions and costs. If Apple thought location finding was such a great idea, they could have built it themselves quite a while ago (they made the Find My iPhone app...how long ago now? You can't tell me nobody within Apple ever said "hmmm, what if you could find other devices?") It really does feel like Apple waits for
other companies to innovate, and then capitalizes on those efforts by changing the developer rules and then implementing the same product themselves without those same limits. The danger of "it's Apple's platform" is that you might get exactly what you wish for - a platform that is 100% Apple, with nobody else contributing. Businesses may just decide it's too risky to develop a product for Apple devices because of the inherent risk that Apple might change the rules and shut them out of the market, then take over and do it themselves. Sure, some companies will be "Android-only", but iOS is a large enough part of the market share, and
end users don't really care about all this infighting (they just want the products they paid for to work the way they expect), that many ideas will just never get off the ground in the first place.
(Let's not forget, Apple hasn't really ever "invented" anything. They certainly have applied their design skill to make better iterations of concepts, and their marketing skill to sell those products, but Apple has a long history of acquire-and-conquer. Let's see... GUI = Xerox, mouse = Xerox, all-in-one computer = HP 9830 or Commodore PET, tablet = Windows for Pen Computing, touchscreen tablet = many examples of Windows Tablet PC Edition, MP3 player = Diamond Rio, smartphone = depending on your definition, Nokia/Pocket PC phones/etc...)
[automerge]1595640172[/automerge]
If you are speaking from a user viewpoint, yes, you definitely can enable it in the Settings app. If you are speaking from a developer viewpoint, to be able to get location data of ALL phones with your app installed, with or without each users’ consent, it’s exactly what Apple wants to prohibit, and exactly what us normal users want Apple to prohibit.
Apple can make full-time location tracking work by simply requiring the user to explicitly go to the Settings app and specifically enable the app that wants full access to location tracking. No prompt in the app, the app simply cannot use full time background location until the user enables it
in the settings app. They can require you to enter your passcode (don't allow biometrics) and have a nice warning display indicating all of the risks of allowing an app to have this access. They can also add policies to the App Store that apps will be rejected unless they can demonstrate that such access is actually a requirement for the app's core functionality (like Tile). It's easy to do this securely. Any user purchasing a product like Tile is going to understand that Tile is going to have access to their location, since that's the entire purpose of the product in the first place. This will still block news readers, weather apps, etc. from arbitrarily collecting your location in the background, since those apps don't require it for their core functionality so Apple simply won't let them have that option in the first place.
The problem with arguing "but security!" for everything is it's a very short path from "secure" to "user hostile", because you can argue that just about
any user action has the potential to be "insecure". Security is always about tradeoffs, and since there's a very obvious way to implement reasonable security (like I've just described) the argument of restricting for "security" becomes less credible and looks a lot more like just a classic vendor lock-in and anticompetition scenario.