This seems like a positive change, or at least a non-issue. It’s not a big deal to ask developers to check a “I know what I’m doing” box.
However, I’m not sure how big of an attack vector they’re closing here. I’m thinking of two channels:
1. Drive by installs when someone uses a public charger or another person’s computer to charge while using their phone
2. Users being guided to install malicious apps themselves under the guise of fake support or similar setups.
These just don’t seem like major problems to me. (1) could probably work if you were targeting an individual, but it doesn’t seem like this is the weak link. For (2) I can’t imagine anyone who goes to the trouble of installing xcode and deploying to their device wouldn’t be willing to just check that box too.
2) is basically going to be attempted on nearly every single kid with an iOS device (see "free fortnite skins / robux just follow these instructions and paste these in, also turn off firewall and av")
(1) is already a non-issue because the device would ask you whether you "trust this computer" and then your passcode to proceed. Xcode won't even see it before you go through this prompt.
FWIW Android does a similar thing with USB debugging enabled, just without the extra step with the passcode.
A massive percentage of users will mindlessly say Trust and enter their passcode. Virtually no one will accidentally go into settings and enable Developer Mode
I’m not saying anyone would do that intentionally. But I think it’s well established that most people’s reaction to modals is to close them and get back to what they are doing rather than read and consider them.
After that, iOS users are sometimes prompted to enter their passcode on an unlocked device for things like updates. A user who doesn’t understand their phone (very common) or is distracted and has something they’re trying to do (basically everyone) could easily say “whatever, yes, trust this charger” then “ugh again!? Here’s my passcode” without even thinking about it.
Of the 9 family members I’m thinking of who use iPhones: 3 know enough not to do that, 4 know that “Don’t Trust” is probably the right answer but could be caught if they weren’t thinking about it, 2 would have no idea and it’s 50/50 which button they hit.
The passcode would never stop either of the last 2.
> But I think it’s well established that most people’s reaction to modals is to close them and get back to what they are doing rather than read and consider them.
And this is why I consider modals "out of nowhere" to be the worst UX sin out there. And iOS is chock-full of these things. Low battery? In-your-face alert. System update? In-your-face alert, and then sneaky "enter passcode to install overnight" crap. Something about your Apple ID that you couldn't care less about? In-your-face alert. Plugged something in? In-your-face alert. No SIM card? In-your-face alert. An app failed to download? In-your-face alert.
It would've been much better if it was a notification. You'd only look for it if you know it should be there, for example when your computer doesn't see your phone.
I have had iOS tell me I needed to "unlock the phone to enable accessories" (or something to that effect) when plugging in the charger that came in the box with the phone.
This has usually been when the lightning port has been fouled by pocket lint or the cord has started going bad, but I bet it happens often enough to desensitize users (especially for people using off-brand cords) that it has been identified as a possible attack vector, and developer mode is the solution.
No, the alert you see is different from the "unlock the phone to enable accessories" notification. That goes away (and your phone starts charging) as soon as you unlock your phone. The "trust this computer" is an alert that only shows up after you unlock your phone, and it looks like this: https://media.idownloadblog.com/wp-content/uploads/2018/02/i...
I don’t think so… I’m not sure, but it doesn’t look like this adds anything beyond knowing the passcode (already required in my understanding) if you have time alone with the device.
Will this allow the local building/installing of personal apps without uploading it to Apple? Also will the app continue working indefinitely or will it require a periodic (weekly?) rebuild as this did before?
Basically what my question boils down to is: can I locally and build a persistent app with this change?
Wasn't this already the case? I think you just need the developer subscription, but you don't have to upload your IPA to any Apple server, as far as I know
Last I checked, the app would only continue to function for a week or some limited time. A work-around was to repeatedly redeploy it. Is this still necessary?
Can someone summarize how this compares to how things were prior (if there is even any change at all)? Does this make it easier or harder to sideload apps, for instance?
Previously, each developer had to do one or more of:
* use TestFlight for centralized distribution of pre-release apps, through Apple (with some lighter-touch app review involved), or
* use enterprise signing (which requires enrolling in a more expensive program and jumping through some corporate hoops, with your apps subject to deactivation if you abuse it) to install on an unrestricted number of devices theoretically owned by your company, or
* whitelist a pretty low number of specific iOS devices to install arbitrary apps onto — I think that limit is still 100 devices per year, per developer account
This sounds like it removes the whitelisting requirement from the third option. Hope it's enough friction to prevent the worst aspects of sideloading from taking hold.
If this removes the whitelisting requirement, that would be awesome—but I’m very much not holding my breath. My pessimistic guess would be nothing else changes, just a bit of extra fiction.
I think it's an OK kind of harder though. It's harder in the sense that you have to more clearly express your intention to load a non-store app and take a reboot.
It's not harder in the sense of "you are prohibited from doing it".
Surely this is the beginning of providing a side loading option. Perhaps if they enforce the purchase of a paid developer account they can get their pound of flesh from the users on their way out of the store. It would be ironic if iPhone users paid Apple 100 USD a year to side load to play Fortnite etc...
Many people have already been doing just that for years albeit with Infinity Blade. Anyone with a free developer account can sign and sideload 3 apps while those with a paid one can sign an unlimited number of apps.
This might be a more pessimistic reading, but from what I can glean, Apple added a warning toggle and app code requirement to the sideloading and signing process. That's it. Nothing presented here indicates the lifting of any previous restrictions or the addition of any new features like on-device app-signing/compiling, now or in the future. If anything, this "Developer Mode" is another layer of soft lockout to those who wish to load jailbreaks or non-Appstore apps onto their phones. Those who don't know any better will think that Apple is capitulating, when the likelier scenario is that Apple is putting on a show to quell the complainers while quietly expanding its control.
Does this developer mode come with any changes to the signing requirements? For example, does it allow the installation of apps with self-signed, non-Apple-issued certificates?
Makes me wonder if enabling the developer options on my Android is opening any security holes. I would think not (assuming you don't then go into those same options and start messing with stuff) but I always do it first thing. I love turning on the option where it shows a little white circle exactly where it is registering your touch - I am sure this was intended to be just for testing but it is super useful on a device as imprecise as a touchscreen.
This seems like a positive change, or at least a non-issue. It’s not a big deal to ask developers to check a “I know what I’m doing” box.
However, I’m not sure how big of an attack vector they’re closing here. I’m thinking of two channels:
1. Drive by installs when someone uses a public charger or another person’s computer to charge while using their phone
2. Users being guided to install malicious apps themselves under the guise of fake support or similar setups.
These just don’t seem like major problems to me. (1) could probably work if you were targeting an individual, but it doesn’t seem like this is the weak link. For (2) I can’t imagine anyone who goes to the trouble of installing xcode and deploying to their device wouldn’t be willing to just check that box too.
2) is basically going to be attempted on nearly every single kid with an iOS device (see "free fortnite skins / robux just follow these instructions and paste these in, also turn off firewall and av")
(1) is already a non-issue because the device would ask you whether you "trust this computer" and then your passcode to proceed. Xcode won't even see it before you go through this prompt.
FWIW Android does a similar thing with USB debugging enabled, just without the extra step with the passcode.
A massive percentage of users will mindlessly say Trust and enter their passcode. Virtually no one will accidentally go into settings and enable Developer Mode
They will do so when plugging into a charger?
(I don't oppose there being developer mode, I'm just adding that there are extra steps)
I’m not saying anyone would do that intentionally. But I think it’s well established that most people’s reaction to modals is to close them and get back to what they are doing rather than read and consider them.
After that, iOS users are sometimes prompted to enter their passcode on an unlocked device for things like updates. A user who doesn’t understand their phone (very common) or is distracted and has something they’re trying to do (basically everyone) could easily say “whatever, yes, trust this charger” then “ugh again!? Here’s my passcode” without even thinking about it.
Of the 9 family members I’m thinking of who use iPhones: 3 know enough not to do that, 4 know that “Don’t Trust” is probably the right answer but could be caught if they weren’t thinking about it, 2 would have no idea and it’s 50/50 which button they hit.
The passcode would never stop either of the last 2.
> But I think it’s well established that most people’s reaction to modals is to close them and get back to what they are doing rather than read and consider them.
And this is why I consider modals "out of nowhere" to be the worst UX sin out there. And iOS is chock-full of these things. Low battery? In-your-face alert. System update? In-your-face alert, and then sneaky "enter passcode to install overnight" crap. Something about your Apple ID that you couldn't care less about? In-your-face alert. Plugged something in? In-your-face alert. No SIM card? In-your-face alert. An app failed to download? In-your-face alert.
It would've been much better if it was a notification. You'd only look for it if you know it should be there, for example when your computer doesn't see your phone.
I have had iOS tell me I needed to "unlock the phone to enable accessories" (or something to that effect) when plugging in the charger that came in the box with the phone.
This has usually been when the lightning port has been fouled by pocket lint or the cord has started going bad, but I bet it happens often enough to desensitize users (especially for people using off-brand cords) that it has been identified as a possible attack vector, and developer mode is the solution.
No, the alert you see is different from the "unlock the phone to enable accessories" notification. That goes away (and your phone starts charging) as soon as you unlock your phone. The "trust this computer" is an alert that only shows up after you unlock your phone, and it looks like this: https://media.idownloadblog.com/wp-content/uploads/2018/02/i...
Along with #1, could it also make it more difficult for attacks on devices where the attacker has physical access?
I don’t think so… I’m not sure, but it doesn’t look like this adds anything beyond knowing the passcode (already required in my understanding) if you have time alone with the device.
#2 is probably the single biggest attack vector on these platforms
Hmm this + the new API to check whether an app has been installed from the AppStore (https://developer.apple.com/documentation/storekit/apptransa...) makes me wonder what we’re in for
Will this allow the local building/installing of personal apps without uploading it to Apple? Also will the app continue working indefinitely or will it require a periodic (weekly?) rebuild as this did before?
Basically what my question boils down to is: can I locally and build a persistent app with this change?
Wasn't this already the case? I think you just need the developer subscription, but you don't have to upload your IPA to any Apple server, as far as I know
Last I checked, the app would only continue to function for a week or some limited time. A work-around was to repeatedly redeploy it. Is this still necessary?
This seems targeted at adding friction for alternative app stores eg. https://altstore.io/
Can someone summarize how this compares to how things were prior (if there is even any change at all)? Does this make it easier or harder to sideload apps, for instance?
Previously, each developer had to do one or more of:
* use TestFlight for centralized distribution of pre-release apps, through Apple (with some lighter-touch app review involved), or
* use enterprise signing (which requires enrolling in a more expensive program and jumping through some corporate hoops, with your apps subject to deactivation if you abuse it) to install on an unrestricted number of devices theoretically owned by your company, or
* whitelist a pretty low number of specific iOS devices to install arbitrary apps onto — I think that limit is still 100 devices per year, per developer account
This sounds like it removes the whitelisting requirement from the third option. Hope it's enough friction to prevent the worst aspects of sideloading from taking hold.
If this removes the whitelisting requirement, that would be awesome—but I’m very much not holding my breath. My pessimistic guess would be nothing else changes, just a bit of extra fiction.
It’s 100 devices per type per dev account, so 100 iPhones, 100 iPads, 100 Apple TVs, etc
Looks like harder as you have to explicitly opt in and restart your device
I think it's an OK kind of harder though. It's harder in the sense that you have to more clearly express your intention to load a non-store app and take a reboot.
It's not harder in the sense of "you are prohibited from doing it".
Surely this is the beginning of providing a side loading option. Perhaps if they enforce the purchase of a paid developer account they can get their pound of flesh from the users on their way out of the store. It would be ironic if iPhone users paid Apple 100 USD a year to side load to play Fortnite etc...
Many people have already been doing just that for years albeit with Infinity Blade. Anyone with a free developer account can sign and sideload 3 apps while those with a paid one can sign an unlimited number of apps.
This might be a more pessimistic reading, but from what I can glean, Apple added a warning toggle and app code requirement to the sideloading and signing process. That's it. Nothing presented here indicates the lifting of any previous restrictions or the addition of any new features like on-device app-signing/compiling, now or in the future. If anything, this "Developer Mode" is another layer of soft lockout to those who wish to load jailbreaks or non-Appstore apps onto their phones. Those who don't know any better will think that Apple is capitulating, when the likelier scenario is that Apple is putting on a show to quell the complainers while quietly expanding its control.
Upon enabling, it shows this warning[0], then upon reboot requires the passcode to confirm[1].
0: https://i.judge.sh/40fyN/1bNGK4tR_k.png
1: https://i.judge.sh/JbQcE/Q2UdipID_A.png
Does this developer mode come with any changes to the signing requirements? For example, does it allow the installation of apps with self-signed, non-Apple-issued certificates?
No, at least not right now. Apple may be preparing to be forced into allowing sideloading with this feature though.
Makes me wonder if enabling the developer options on my Android is opening any security holes. I would think not (assuming you don't then go into those same options and start messing with stuff) but I always do it first thing. I love turning on the option where it shows a little white circle exactly where it is registering your touch - I am sure this was intended to be just for testing but it is super useful on a device as imprecise as a touchscreen.
This doesn't appear to add any features, but just revert ones that are being taken away by default in iOS 16.