9 ms·

I'm rather confused as to why you thought the following: > We understood that the new Xcode signing was designed to allow such use, but Apple has indicated tha

by eridius 11y ago

I'm rather confused as to why you thought the following: > We understood that the new Xcode signing was designed to allow such use, but Apple has indicated that this should not continue. Where has Apple ever indicated that the new Xcode signing was intended for your use-case? I never saw the download you provided, but I'm assuming you didn't actually release f.lux as open source, but instead just provided essentially a prebuilt download and had Xcode re-sign it. Is that assumption correct? Because that seems to be a pretty blatant violation of the spirit of the developer program, even if it's not explicitly spelled out in the agreement. The new Xcode signing model is intended to allow people to get started with iOS development without paying any money, so they can build and run their own projects on their own devices, and only have to pay for the dev program when they want to start distributing to other people. If you did in fact release f.lux as an open-source project, that would be within both the spirit and the letter of the agreement (I doubt Apple has any problems with people installing open-source apps on their personal devices). But it should be obvious that Apple wants all binary distribution to be done through the app store (or enterprise distribution where applicable). Speaking of enterprise distribution, did you ever investigate that approach? I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement. But I've never actually looked into it myself so I don't know.

potatolicious 11y ago
> "I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement." There are. Using enterprise distribution to distribute to the general public is explicitly disallowed for some IMO really good reasons (the ability to call private APIs being a big one). There's some gray area when it comes to using enterprise distribution (e.g., to external testers not otherwise affiliated with your company) and Apple generally doesn't police these, but allowing the general public to install is very, very much against the rules and will get you banned.
- eridius 11y ago
  I'm not particularly surprised. Actually, I would have been surprised if these restrictions weren't in place. But I figured it was worth looking into.
- Mikushi 11y ago
  So that's how it is nowadays, pay the Apple extortion fee it's good for you . As an app developer with principles I will never endorse Apple's business model as it is toxic and destroying the open internet. That users will not find the app is actually good as it might make them consider switching provider for their mobile OS and one less iOS user is a victory for anyone carring about the health of the internet market and mobile ecosystem at large.
  - mattlutze 11y ago
    > So that's how it is nowadays, pay the Apple extortion fee it's good for you . That's not what OP is saying, though. The f.lux folks were leveraging private APIs, that are unpublished and not part of the set of tools you're authorized to build commercial apps on for iOS. Apple doesn't want to support those APIs for whatever reason, so they're not included in the toolset. Just because you can find a way to do something (like distributing binaries to have users compile into their own version of an app, trusting that the distributor is trustworthy, that the distribution hasn't been corrupted somehow, that...) doesn't mean it should be allowed willy nilly. Strong requirements like this at some level have kept quality in the average iOS app high. I recently dumped Android for iOS again because I got sick after 4 years of my devices never quite working right. If I don't have to spend so much time on my iPhone policing apps from randomly deciding to go off the reserve (like happened even with quite popular apps on Android), I'll take that over complete unfettered license to muck about in the operating system. Cause that as a practice just doesn't turn out well. For every f.lux there's 100 development operations who are gonna screw something up.
    - bad_user 11y ago
      I've been an Android user ever since 2011 and I also own iOS devices. Care to name "popular apps on Android" deciding to "go off the reserve" and that don't work? My first smartphone was actually an iPhone 3GS. Because of Apple's walled garden, it couldn't help me with a really simple and downright obvious task for a smartphone - blocking unwanted phone numbers from calling or texting me. People had to jailbreak their phones and install Cydia in order to do that. And because Apple caters to users instead of mobile careers, my iPhone could not tether my 3G connection either because Orange wasn't allowing it without an extra $5 per month. Oh wait, I think I got that backwards. So another use-case for which my smartphone was completely unsuitable for. Now I've got an iPhone 6s that I received as a gift (well, I'm blessed with friends that think I want Apple stuff just because I use a MacBook for work). And I find the restrictions to be as annoying as ever. Yesterday's Firefox release for iOS reminded me of this very fact. On Android I've got the real Firefox and it can do extensions and it can innovate. For example I was blocking ads long before iOS 9, the very concept of ad blocking happening for Firefox first. Plus I use Firefox on my desktop so syncing is nice and I hate monocultures, like what WebKit has become. You see, I couldn't give a crap about F.lux, but I do care about having Firefox, as it's the open-source browser that saved the web and the browser that now keeps WebKit from taking over the whole market, like IExplorer 5 and 6 once did. > I'll take that over complete unfettered license to muck about in the operating system I understand that, but this is were we disagree the most. In society people can be very evil, people can steal from you, can leave you without your job, people can hurt you and your family in myriads of ways. Yet we can cope with this uncertainty, as we've invented institutions that protect us in times of need, we came up with rules for interacting with society (e.g. the concept of trust), we do our part in educating our children to not be complete assholes and all of this usually works, in spite of having certain rights and freedoms, like the freedom of expression, the right to having property, or the right for privacy. People often forget about that last one of course, as we increasingly prefer to police our peers in the name of security, in spite of a lack of evidence that it leads to a more secure environment and often forgetting what it is like to live in a police state, though as somebody that grew up in an Eastern Europe country that was once a police state, trust me when I say that's not nice. But back to the point - personally, I consider any platform that rejects useful apps to be completely inappropriate, no matter the reasoning. And of course, Apple can do whatever they wish with their property, which is a fundamental right after all, but that doesn't mean I can't exercise my freedom of expression to bitch and moan about how much that sucks.
conradev 11y ago
> Where has Apple ever indicated that the new Xcode signing was intended for your use-case? Apple never officially explained the decision, but from what I've heard it was to encourage Swift adoption.
yaegers 11y ago
That's what I was wondering, too. I think Apple may have been a bit too generous with this offering. How long does the code signing stay valid this way? Forever? I think it would have been sufficient for the majority of use cases if an app sideloaded like this would only be valid for like 12 - 24 hours. I mean, as you wrote, this system is supposed to be for devs who want to test their apps on devices without having to pay for the dev program. I think 12 hours would be enough time to judge you progress on device. Since you are going to test many iterations of that app, you are going to deploy it often anyway. Why would there be a need to have those apps work forever? I realize there are edge cases where some people would want a longer, broad beta test for their app but is that really necessary for such a "free" option? Surely if you plan out your app of such scale and you arrive at that point in time to warrant a week long beta test you will very likely deploy on the app store anyway so you might as well buy into the 99 bucks a year program to correctly sign your apps. Had Apple directly limited the time sideloaded apps like that work and made it public that this is "just" a feature aimed at developers to become interested in iOS development, this whole thing could have been avoided.
- eridius 11y ago
  Why time-limit it? There's no rule that says you must publish every app you make to the app store. What if you're making an app that's intended precisely for your own personal use and nobody else's?
INTPenis 11y ago
I gotta say I was infuriated until I read your comment, you totally nailed it. Distributing binary code to thousands of iOS users is dangerous, if nothing else. So Apple clearly has a point trying to control distribution through the app store. And if the author truly does believe in curing sleep issues, as they state, then they should have released the source code and let people install the app themselves. In fact, with 176000 page views, and 15 million downloads of their desktop app (I myself have been a long time user) I don't see why he didn't just pay the 99 USD and distribute it via the app store. I certainly would have payed for it because it pains me to see my SO in bed solving sudoku with a flipping 50W lamp in her face.
- detaro 11y ago
  > I don't see why he didn't just pay the 99 USD and distribute it via the app store If I understand correctly, they can't do so since they are using undocumented APIs that they are not allowed to use in store apps.
  - reticulated 11y ago
    That's correct. Additionally, although there are many ways to work around these static code checks Apple performs at app review time (due to Objective C's runtime capabilities), you can bet an app as popular as f.lux would get pulled very quickly with potentially long-term damage to their relationship with Apple* (* See https://ifixit.org/blog/7401/ifixit-app-pulled/ https://ifixit.org/blog/7401/ifixit-app-pulled/ )
- xuki 11y ago
  Flux uses private API, it will not be allowed on the App Store.

by eridius 11y ago

potatolicious 11y ago

> "I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement." There are. Using enterprise distribution to distribute to the general public is explicitly disallowed for some IMO really good reasons (the ability to call private APIs being a big one). There's some gray area when it comes to using enterprise distribution (e.g., to external testers not otherwise affiliated with your company) and Apple generally doesn't police these, but allowing the general public to install is very, very much against the rules and will get you banned.

eridius 11y ago
I'm not particularly surprised. Actually, I would have been surprised if these restrictions weren't in place. But I figured it was worth looking into.
Mikushi 11y ago
So that's how it is nowadays, pay the Apple extortion fee it's good for you . As an app developer with principles I will never endorse Apple's business model as it is toxic and destroying the open internet. That users will not find the app is actually good as it might make them consider switching provider for their mobile OS and one less iOS user is a victory for anyone carring about the health of the internet market and mobile ecosystem at large.
- mattlutze 11y ago
  > So that's how it is nowadays, pay the Apple extortion fee it's good for you . That's not what OP is saying, though. The f.lux folks were leveraging private APIs, that are unpublished and not part of the set of tools you're authorized to build commercial apps on for iOS. Apple doesn't want to support those APIs for whatever reason, so they're not included in the toolset. Just because you can find a way to do something (like distributing binaries to have users compile into their own version of an app, trusting that the distributor is trustworthy, that the distribution hasn't been corrupted somehow, that...) doesn't mean it should be allowed willy nilly. Strong requirements like this at some level have kept quality in the average iOS app high. I recently dumped Android for iOS again because I got sick after 4 years of my devices never quite working right. If I don't have to spend so much time on my iPhone policing apps from randomly deciding to go off the reserve (like happened even with quite popular apps on Android), I'll take that over complete unfettered license to muck about in the operating system. Cause that as a practice just doesn't turn out well. For every f.lux there's 100 development operations who are gonna screw something up.
  - bad_user 11y ago
    I've been an Android user ever since 2011 and I also own iOS devices. Care to name "popular apps on Android" deciding to "go off the reserve" and that don't work? My first smartphone was actually an iPhone 3GS. Because of Apple's walled garden, it couldn't help me with a really simple and downright obvious task for a smartphone - blocking unwanted phone numbers from calling or texting me. People had to jailbreak their phones and install Cydia in order to do that. And because Apple caters to users instead of mobile careers, my iPhone could not tether my 3G connection either because Orange wasn't allowing it without an extra $5 per month. Oh wait, I think I got that backwards. So another use-case for which my smartphone was completely unsuitable for. Now I've got an iPhone 6s that I received as a gift (well, I'm blessed with friends that think I want Apple stuff just because I use a MacBook for work). And I find the restrictions to be as annoying as ever. Yesterday's Firefox release for iOS reminded me of this very fact. On Android I've got the real Firefox and it can do extensions and it can innovate. For example I was blocking ads long before iOS 9, the very concept of ad blocking happening for Firefox first. Plus I use Firefox on my desktop so syncing is nice and I hate monocultures, like what WebKit has become. You see, I couldn't give a crap about F.lux, but I do care about having Firefox, as it's the open-source browser that saved the web and the browser that now keeps WebKit from taking over the whole market, like IExplorer 5 and 6 once did. > I'll take that over complete unfettered license to muck about in the operating system I understand that, but this is were we disagree the most. In society people can be very evil, people can steal from you, can leave you without your job, people can hurt you and your family in myriads of ways. Yet we can cope with this uncertainty, as we've invented institutions that protect us in times of need, we came up with rules for interacting with society (e.g. the concept of trust), we do our part in educating our children to not be complete assholes and all of this usually works, in spite of having certain rights and freedoms, like the freedom of expression, the right to having property, or the right for privacy. People often forget about that last one of course, as we increasingly prefer to police our peers in the name of security, in spite of a lack of evidence that it leads to a more secure environment and often forgetting what it is like to live in a police state, though as somebody that grew up in an Eastern Europe country that was once a police state, trust me when I say that's not nice. But back to the point - personally, I consider any platform that rejects useful apps to be completely inappropriate, no matter the reasoning. And of course, Apple can do whatever they wish with their property, which is a fundamental right after all, but that doesn't mean I can't exercise my freedom of expression to bitch and moan about how much that sucks.

conradev 11y ago

> Where has Apple ever indicated that the new Xcode signing was intended for your use-case? Apple never officially explained the decision, but from what I've heard it was to encourage Swift adoption.

yaegers 11y ago

That's what I was wondering, too. I think Apple may have been a bit too generous with this offering. How long does the code signing stay valid this way? Forever? I think it would have been sufficient for the majority of use cases if an app sideloaded like this would only be valid for like 12 - 24 hours. I mean, as you wrote, this system is supposed to be for devs who want to test their apps on devices without having to pay for the dev program. I think 12 hours would be enough time to judge you progress on device. Since you are going to test many iterations of that app, you are going to deploy it often anyway. Why would there be a need to have those apps work forever? I realize there are edge cases where some people would want a longer, broad beta test for their app but is that really necessary for such a "free" option? Surely if you plan out your app of such scale and you arrive at that point in time to warrant a week long beta test you will very likely deploy on the app store anyway so you might as well buy into the 99 bucks a year program to correctly sign your apps. Had Apple directly limited the time sideloaded apps like that work and made it public that this is "just" a feature aimed at developers to become interested in iOS development, this whole thing could have been avoided.

eridius 11y ago
Why time-limit it? There's no rule that says you must publish every app you make to the app store. What if you're making an app that's intended precisely for your own personal use and nobody else's?

INTPenis 11y ago

I gotta say I was infuriated until I read your comment, you totally nailed it. Distributing binary code to thousands of iOS users is dangerous, if nothing else. So Apple clearly has a point trying to control distribution through the app store. And if the author truly does believe in curing sleep issues, as they state, then they should have released the source code and let people install the app themselves. In fact, with 176000 page views, and 15 million downloads of their desktop app (I myself have been a long time user) I don't see why he didn't just pay the 99 USD and distribute it via the app store. I certainly would have payed for it because it pains me to see my SO in bed solving sudoku with a flipping 50W lamp in her face.

detaro 11y ago
> I don't see why he didn't just pay the 99 USD and distribute it via the app store If I understand correctly, they can't do so since they are using undocumented APIs that they are not allowed to use in store apps.
- reticulated 11y ago
  That's correct. Additionally, although there are many ways to work around these static code checks Apple performs at app review time (due to Objective C's runtime capabilities), you can bet an app as popular as f.lux would get pulled very quickly with potentially long-term damage to their relationship with Apple* (* See https://ifixit.org/blog/7401/ifixit-app-pulled/ https://ifixit.org/blog/7401/ifixit-app-pulled/ )
xuki 11y ago
Flux uses private API, it will not be allowed on the App Store.