Transmit for iOS restricted from using iCloud Drive, forced to delete all share sheet options

13»

Comments

  • Reply 41 of 54
    asciiascii Posts: 5,936member
    Quote:

    Originally Posted by aduzik View Post

     

    You know there's no channel to "ask Apple about it up front", right? All they will tell you is to write the code, submit the app, and then they'll tell you if it's acceptable or not. I have done this on my clients' behalf and they will not give you any other answer. And again, Apple already approved the app and then rejected it after the fact. These are not the behaviors of a professional company.




    According to Panic's blog, Apple were very helpful with Coda's sandboxing issues:

    "Apple, to their considerable credit, spent a lot of energy assisting us with ideas, workarounds, and temporary exemptions we might be able to use to get around some of the issues. Apple genuinely went above and beyond the call of duty, and we’re really thankful for their help. We got extremely close and jumped over a lot of tricky hurdles thanks to them." (their emphasis, not mine)

    http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/

     

    To me it sounds like Apple is trying to add security to their OS and "going beyond the call of duty" to work with developers on it. Whereas you are trying to make out it's some kind of arbitrary impost. Maybe you experience has been different to Panic's.

  • Reply 42 of 54
    Quote:

    Originally Posted by Frac View Post





    That makes no sense when you are able to upload 'anything' in OSX via Transmit.

    I'd be surprised if this isn't settled in Panic's favour quite quickly.

    Not only that, but Finder gives you unfettered access to iCloud drive. If arbitrary files were a problem on iCloud Drive they wouldn't have included it.

  • Reply 43 of 54
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by aduzik View Post

     

    Apple didn't say it was a matter of security or privacy. They said it wasn't an acceptable use of their API's. And if that rule is published somewhere I'd like to see a link to it because it's not on the App Store review guidelines. Again, Apple approved the app and then rejected an already approved app.




    Well, just read the iOS Data Storage Guidelines. The whole thing is phrased in terms of one app storing it's user generated documents, and how to keep data to a minimum so as to not fill up the users cloud or take too long to sync. That is the model of app they are thinking of and writing about. The idea of a file transfer app storing all kinds of miscellaneous files in the cloud does not even seem to have occurred to them. In that situation I would ask instead of just going ahead and trying to sneak it through. You're just asking for something like this to happen (the reversed decision). And they clearly did have channels open based on the Coda blog post.

  • Reply 44 of 54
    Quote:

    Originally Posted by ascii View Post

     



    Well, just read the iOS Data Storage Guidelines. The whole thing is phrased in terms of one app storing it's user generated documents, and how to keep data to a minimum so as to not fill up the users cloud or take too long to sync. That is the model of app they are thinking of and writing about. The idea of a file transfer app storing all kinds of miscellaneous files in the cloud does not even seem to have occurred to them. In that situation I would ask instead of just going ahead and trying to sneak it through. You're just asking for something like this to happen. And they clearly did have channels open based on the Coda blog post. 


    This doc? That has nothing to do with iCloud Drive. It's not mentioned on the page at all. That doc is about what's acceptable to store in the device's Documents directory, and how to mark things not to be backed up to iCloud. Not a word about iCloud Drive.

     

    It's great that Cabel and Panic have a good relationship with Apple, but they're the exception, not the rule. The other 99.99% of developers don't get that special treatment.

     

    I will never understand the Apple apologia I see here day in and day out. Apple does things even its fans (like me) don't like. Not publishing clear developer guidelines and enforcing unpublished rules is one of them. It's because I want the platform to be great that I complain about this stuff.

  • Reply 45 of 54
    ascii wrote: »
    <div class="quote-container" data-huddler-embed="/t/183792/transmit-for-ios-restricted-from-using-icloud-drive-forced-to-delete-all-share-sheet-options#post_2649497" data-huddler-embed-placeholder="false">Quote:<div class="quote-block">Originally Posted by <strong>singularity</strong> <a href="/t/183792/transmit-for-ios-restricted-from-using-icloud-drive-forced-to-delete-all-share-sheet-options#post_2649497"><img alt="View Post" src="/img/forum/go_quote.gif" /></a><br /><br /><br />They are divas for breaking an unwritten policy?</div></div><p> </p><p>Yes. The typical iOS app has it's own custom document format which the user creates instances of and saves (e.g. a drawing, text document, spreadsheet...). Transmit uploads many kinds of documents, none of which were authored in the app. Rightly or wrongly, that is obviously an exception to the way iOS apps usually work, so a non-diva company would have asked Apple about it up front before they started coding.</p>
    Shouldn't all applicable policies actually be published so developers don't have to second guess whether what they are doing is allowed or not?

    Steady on!

    I'm not sure I can handle that much common sense in one day.
  • Reply 46 of 54

    Read this. It's a post about Launcher, an app containing a Notification widget that lets you launch other apps. Apple initially approved and then rejected it. But the reason Apple gave for it is absolutely appalling.

     

    App Review pretty much openly admits that, instead of just publishing a clear guideline about what they'll accept and what they won't, they approved an app with the intention of rejecting it later in order to make an example of the developer and discourage other developers from doing the same. This is a scandal in my opinion. It's completely insane.

     

    How on earth is this supposed to be better than publishing a rule? If the goal is to prevent these kinds of apps from being submitted, couldn't they just have added a guideline that says, "don't do this, or your app will be rejected" instead of humiliating a developer in public?

  • Reply 47 of 54
    MacProMacPro Posts: 19,728member
    cropr wrote: »
    As an app developer for companies, I've run a few times into issues wth Apple iOS guidelines that are too restrictive compared to other envrionments. This is hurting Apple.  I have a customer that decided to stop buying iPad's in the company and to gradually replace them by Android tablets, because one of the key apps I had to develop, did not pass the iOS app store guidelines.

    That's crazy. Oh boy you did your clients a disservice there then! Surely it would have been better to step up and conform so they could use the far superior hardware!
  • Reply 48 of 54
    toukale wrote: »
    Not yet, but they will. It's only a matter of time or when, not if, before people eventually starts using those storage for copyrighted materials.
    That's gotta be the most ridiculous things I've heard all week. Use your brain for 3 seconds. Please. Just use it.
  • Reply 49 of 54
    asdasdasdasd Posts: 5,686member
    aduzik wrote: »
    Read this. It's a post about Launcher, an app containing a Notification widget that lets you launch other apps. Apple initially approved and then rejected it. But the reason Apple gave for it is absolutely appalling.

    App Review pretty much openly admits that, instead of just publishing a clear guideline about what they'll accept and what they won't, they approved an app with the intention of rejecting it later in order to make an example of the developer and discourage other developers from doing the same. This is a scandal in my opinion. It's completely insane.

    How on earth is this supposed to be better than publishing a rule? If the goal is to prevent these kinds of apps from being submitted, couldn't they just have added a guideline that says, "don't do this, or your app will be rejected" instead of humiliating a developer in public?

    He's being disengenous. The guidelines about the today widget are clear. Lightweight apps that tell you about today's activities ( Calendar, Time, weather etc) and nothing else.

    There is a system calculator in the today center in OS X and so they approved PCalc. This was clear in the WWDC and guidelines.
  • Reply 50 of 54
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by aduzik View Post

     

    This doc? That has nothing to do with iCloud Drive. It's not mentioned on the page at all. That doc is about what's acceptable to store in the device's Documents directory, and how to mark things not to be backed up to iCloud. Not a word about iCloud Drive.

     

    It's great that Cabel and Panic have a good relationship with Apple, but they're the exception, not the rule. The other 99.99% of developers don't get that special treatment.

     

    I will never understand the Apple apologia I see here day in and day out. Apple does things even its fans (like me) don't like. Not publishing clear developer guidelines and enforcing unpublished rules is one of them. It's because I want the platform to be great that I complain about this stuff.




    It's the same thing though, whatever you store in your Documents directory is what shows up as your app's folder in iCloud drive, and anything you save there is automatically pushed to the cloud and then back down to all your other signed in devices. The system as a whole is designed for individual apps creating their individual documents. If they allow someone using Transmit to use iCloud as a general file store, you'll get someone uploading a couple of 4GB movies from their Mac, and then calling Apple Support when all their iDevices in the house suddenly start beeping that their flash memory is full, not understanding that everything syncs.

     

    I want Apple to be a great platform too. And it is, just look at all the amazing things these apps are doing, while following the rules:

     

    One thing that could ruin it though, is if it becomes Malware infested like Android, that is why I stand up for Apple when they enforce their sandbox rules.

  • Reply 51 of 54
    croprcropr Posts: 1,125member
    Quote:

    Originally Posted by digitalclips View Post





    That's crazy. Oh boy you did your clients a disservice there then! Surely it would have been better to step up and conform so they could use the far superior hardware!



    You underestimate the word "key app" in a business environment.  The purchase of the iPads was only approved by the CEO if they could support the key app.  I do agree that the iPad hardware is superior, but if the app is not approved by Apple, this is irrelevant.

     

    Of course we are trying to make a work around, bypassing the iOS restrictions, while complying to the specifications of the customer.  But this work around is technically not an easy challenge and does not come for free in time and budget.  And it much cheaper to buy high end Android tablets than to let a programmer develop a work around for a few weeks and even then not to be 100% sure that Apple will not reject the app again.  The lack of transparency in the approval process is a very frustrating experience for developers

  • Reply 52 of 54
    asdasdasdasd Posts: 5,686member
    cropr wrote: »

    You underestimate the word "key app" in a business environment.  The purchase of the iPads was only approved by the CEO if they could support the key app.  I do agree that the iPad hardware is superior, but if the app is not approved by Apple, this is irrelevant.

    Of course we are trying to make a work around, bypassing the iOS restrictions, while complying to the specifications of the customer.  But this work around is technically not an easy challenge and does not come for free in time and budget.  And it much cheaper to buy high end Android tablets than to let a programmer develop a work around for a few weeks and even then not to be 100% sure that Apple will not reject the app again.  The lack of transparency in the approval process is a very frustrating experience for developers

    Hang on. Why not just use enterprise dist?
  • Reply 53 of 54
    croprcropr Posts: 1,125member

    Because the app is not only used by employees, but also by external partners.  The IT department did not want give access to the Intranet for these external partners.

  • Reply 54 of 54
    Quote:
    Originally Posted by ascii View Post

     



    It's the same thing though, whatever you store in your Documents directory is what shows up as your app's folder in iCloud drive, and anything you save there is automatically pushed to the cloud and then back down to all your other signed in devices. The system as a whole is designed for individual apps creating their individual documents. If they allow someone using Transmit to use iCloud as a general file store, you'll get someone uploading a couple of 4GB movies from their Mac, and then calling Apple Support when all their iDevices in the house suddenly start beeping that their flash memory is full, not understanding that everything syncs.

     

    I want Apple to be a great platform too. And it is, just look at all the amazing things these apps are doing, while following the rules:

     

    One thing that could ruin it though, is if it becomes Malware infested like Android, that is why I stand up for Apple when they enforce their sandbox rules.


    No, what your app puts in its Ubiquity Container is what shows up in iCloud Drive. The Documents folder is backed up to iCloud, but the individual files are not exposed anywhere. Documents in the ubiquity container are *not* automatically pushed. Per Apple's own iCloud documentation

    Quote:

    In iOS, actively download files when required. Files in iOS are not automatically downloaded.


    So a 4 GB file would not be pushed to all iDevices. Macs, maybe, but not iDevices. And the user would have to have 4 GB free in their iCloud account to begin with. In other words, this is not a real concern.

     

    At any rate, Transmit did not use iCloud Drive. It used a Share Sheet that allows users to send content to sharing destinations, of which iCloud Drive is one. Apple's objection was not technical, it was philosophical. And they have reversed that decision, proving that there were no security or technical concerns.

     

    This is the important thing you need to know: developers do not know what the rules are. Apple publishes guidelines, not rules. It's impossible to know whether any particular feature will run afoul of a rule. If you ask them, they will not tell you. Their only response is "submit an app and we'll either approve it or reject it." I suspect they don't publish the rules because the rules aren't stable. There are countless cases of Apple reversing itself, which proves just how unstable the rules are.

     

    You essentially accuse developers of acting in bad faith, and I find that extremely offensive. Malware is basically impossible in iOS apps because the sandbox is well designed and very secure. And I completely agree with Apple rejecting insecure apps.

     

    App Review, on the other hand, is a completely separate matter. Rejecting apps for quality issues is a good thing, but rejecting them because they don't use features in a way Apple imagined, regardless of any real or imagined potential harm, is absurd and harmful. This is why the App Store is full of unimaginative garbage. The world does not need any more to-do list apps or Candy Crushes, but that's pretty much all Apple will approve.

Sign In or Register to comment.