1. 34
  1.  

  2. 25

    No doubt a couple of readers will be thinking “well this is what Apple/proprietary software is like, what did you expect?” I’m extremely familiar with that argument and I don’t like it very much.

    My observation of people who object to this argument is that usually, they haven’t experienced Apple (or Google, or Microsoft) breaking something that they personally value.

    Then it happens, and they post an article which makes the case that normally, $CORPORATE_OVERLORD makes these decisions for the users’ own good, but this one time, they’ve got it wrong, or gone too far.

    I don’t like it very much ;)

    1. 18

      No doubt a couple of readers will be thinking “well this is what Apple/proprietary software is like, what did you expect?” I’m extremely familiar with that argument and I don’t like it very much.

      You may not like it, but it’s happening and you can’t change it, however many blog posts you write about it. The walls are closing in, and your only out is running nonproprietary, free software. Simple as.

      Among the many restrictions on iOS which make life difficult for developers I can usually see a direct reason why this helps the end user in some way. Often it’s related to privacy or protecting their battery from runaway apps.

      No, don’t try to spin this any other way. It is exactly what it is — a bigcorp exercising their power and locking you in.

      1. 24

        your only out is running nonproprietary, free software. Simple as.

        I’ve come to view this perspective as a cop-out. It’s trivially, banally true. It lets you be right without putting in the work to understand the needs of people for whom computers are only a means to an end. If I recommend iOS to someone they can’t install an untrustworthy browser extension, they can remove any app they dislike and it will be gone, and they will be reliably prompted to get security updates for approximately the working lifetime of their device. Walled gardens must be understood as both a blessing and a curse, or they are not understood at all.

        As for me, as a nerd, I’m mostly de-appled now because I can see what’s going on.

        1. 11

          It’s trivially, banally true. It lets you be right without putting in the work to understand the needs of people for whom computers are only a means to an end.

          As for me, as a nerd, I’m mostly de-appled now because I can see what’s going on.

          I think it has value even for nerds. Computer scientists want to write compilers, not shell scripts.

          1. 7

            Even software engineers want their computer/phone/blah to not randomly start BSODing/be overtaken by malware/what’s that, you apt upgraded? hope you don’t mind wasting a morning on getting the nvidia kernel module working again!/etc. on a good day. I just want to be productive and then do something nice.

            1. 2

              How long ago have you used free software? 20 or 30 years? ;)

              1. 4

                About 20 years now, yes. I do not know what your point is.

          2. 3

            Totally agree. However, there’s different levels to this. Google, for all their flaws, actually strikes a pretty good balance here a lot of the time. On e.g. Android installing from non-Play Store sources is disallowed by default, but can be enabled after you get a warning from the device. On the hardware side Pixel devices are secure by default but bootloader unlocking is an officially supported feature (even if whatever you do next isn’t), and Chromebooks have developer mode for the same purpose.

            The problem isn’t walled gardens. The problem is walled gardens without doors. Nothing you just mentioned is incompatible with giving the user choice, behind scary warnings, because the user is always free to pay attention to the warnings and keep the restrictions turned on.

            (Edit: missing word, typos)

          3. 10

            The walls are closing in

            Ah yes. Apple are terrorists who hate our freedoms and hate us because we are free! That is why they are waging a War on General-Purpose Computing! Tim Cook holds meetings every day asking his staff how the “destroy all freedom everywhere and ruin everyone’s computers while you’re at it” project is going. And when new employees ask why, he lectures them on how freedom is evil and must be ended.

            Or… this is probably going to end up having a fairly boring explanation to do with security policies and threat models whose prioritization you and Apple don’t agree on. But it gets more upvotes when you spin it the other way, same as how the “War on Christmas” plays well on cable news despite being objectively as real as the “war on general-purpose computing”.

          4. 19

            I actually think the author’s suggestion that “one day they’ll get rid of BSD sockets entirely” is entirely plausible and even defensible from Apple’s POV. Any networking model that is invisible to users and can access their local network segment is actually incredibly risky. Normal end-users don’t know what “multicast” means, and the fact that it could trivially expose the hardware and services running on their local network to a 3rd party application isn’t obvious unless you have way-above-average levels of computer knowledge.

            If you think of an iOS device as a general-purpose computer, this seems arbitrary and obstructionist. If on the other hand you think of the whole hardware + software stack as a nicely integrated, full-featured, but highly restricted application-delivery platform like modern web browsers it doesn’t seem so odd.

            Browsers also don’t allow direct access to TCP sockets, much less multicast. They don’t let you change system-wide network settings or filesystem permissions, and they don’t allow you to install long-lived, privileged background tasks.

            What they do offer is lot of hooks for advertisers + platform owners to tag a device and track it everywhere it goes, no matter how many privacy extensions you install. Apple is making a push to stop at least casual privacy invasions like that being the norm, so I get why they continue to march towards ever more restrictive API limits + sandboxing.

            I don’t like this as a developer. I also choose not to develop iOS (or Android, or Mac/Windows store) applications. That means that nothing I write will have the kind of exponential growth that a popular mobile app can via one-tap app store installs. I’m okay with that, because my living doesn’t depend on having an app that people can install with zero friction. Other people have different needs and considerations, and I respect that too.

            What I don’t think we’re going to have much success with is pushing back against whatever Apple and Google think the right privileges and protections are for app users. They have minimal reason to listen to OSS/Free Software partisans, and only slightly more cause to care what app developers who want to bypass supported platform features for e.g. device discovery want to do.

            From their perspective, well-defined, locked-down APIs that give “just enough” functionality in that kind of area are absolutely better than “open” APIs like POSIX that were honestly designed for a much kinder, simpler age of computing.

            1. 2

              iOS is moving towards moving things like camera and even local subnet access under controlled permissions dialogs, so this scans.

            2. 5

              well this is what proprietary software is like, what did you expect?

              1. 2

                This is going to make Osmosis development much more difficult… I was already considering these two changes, but now I’m forced to make one or both of them:

                1. Use Bonjour for service discovery instead of a custom protocol. (I don’t know the tradeoffs here, but most Bonjour libraries seem complex and outdated.)
                2. Make Osmosis a separate app that other apps communicate with via IPC (or a localhost HTTP port), rather than a library to be included in other apps.

                iOS is always the most complex, limiting part of cross-platform app development, but it has too large of an install base to ignore. :/

                1. 3

                  Bonjour is pretty simple to implement IIRC, and not really proprietary. Go that way.

                  1. 1

                    For service discovery NSNetService works fairly well. mDNS just isn’t that dependable under packet loss scenarios.

                    1. 1

                      It looks like NSNetService is deprecated, does that matter? And is there a cross-platform library for it?

                    2. 1

                      #2 isn’t going to work because iOS doesn’t support arbitrary background apps.

                      Using mDNS (Bonjour) is probably the right way to go. It generally works and where it doesn’t your custom protocol is probably also blocked or broken.

                      You could support iOS devices by going via a server rather than p2p I guess.

                      1. 1

                        Hmm… I don’t have any experience with iOS apps, and this kind of information seems hard to find, but it looks like there might be loopholes for background apps? Based on some quick Googling, it seems like iOS apps are allowed to run continually in the background if they use the Location or Bluetooth permissions. And one (long shot) idea I had for Osmosis was to allow Bluetooth as another transport for p2p sync, to sync devices without a router present. So maybe the app could cheat by requiring Bluetooth LE to be on even if it’s not actively using it, allowing a server to run in the background…

                        Of course, an app that exists only as a service to be used by other apps is pretty weird in the mobile space anyway, so Apple reviewers might not allow it no matter how I set it up.

                        1. 1

                          In my (limited) experience background access is quite tightly controlled. It would probably be easier to have apps that use Osmosis apply for multicast access from Apple.