omz:forum

    • Register
    • Login
    • Search
    • Recent
    • Popular

    Welcome!

    This is the community forum for my apps Pythonista and Editorial.

    For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.


    iCloud Sync support

    Pythonista
    9
    14
    11181
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Stewartbracken
      Stewartbracken last edited by

      A really nice feature for pythonista would allow syncing projects through iCloud so I could seamlessly work on projects across devices. Often I find myself sending the text of a project to myself. Perhaps there could be a special iCloud folder that syncs across devices.

      Just an idea. Love your app! Keep it up.

      One more thing, I'd love the ability to have more low level access to the graphics surface with shaders or even just a pixels array.

      1 Reply Last reply Reply Quote 0
      • ccc
        ccc last edited by

        http://omz-forums.appspot.com/pythonista/post/6174668323028992

        1 Reply Last reply Reply Quote 0
        • mteep
          mteep last edited by

          @Stewartbracken
          I agree on both feature requests. For iCloud storage, omz needs to be convinced to try it. While at it, Handoff support would be nice too.

          Shader access might be possible in Pythonista 1.6 by using the ctypes module, if omz gets it to fully work in 64-bit builds (and it is approved by Apple, see below). If I find the time, which seems unlikely, I might investigate it in the beta.

          @ccc
          iCloud storage of code is AFAIK not at all prohibited by the App Store review guidelines. I haven't read them in a while, but why would it be? In fact, all code I have written in Pythonista is already on iCloud (automatically backed up by iOS).

          What are prohibited, are mechanisms that could be used to mass distribute (App-like or possibly malicious) code to other users, thereby circumventing the App Store. (This policy is needed to maintain the benefits of the App Store to developers and users.)

          That is, things like:

          • Creating public links to iCloud documents containing code. (Only the app itself, or one from the same developer, has the ability to do this. So the review team can verify this. In particular if special entitlements are required.)
          • Storing code in Dropbox or similar storage that, externally and unbeknownst to the app and the review team, could be made public.
          • Enable code import from other apps via the Open in ... mechanism, like Pythonista tried before.

          This means that using the old Documents in the Cloud mechanism should be fine, but probably not the iOS 8 Document Picker that came with iCloud Drive, unless it can be restricted with (lack of) entitlements.

          Note also that while code in iCloud likely is allowed by itself, it might not be allowed in combination with other functionality like ctypes, depending on the granularity of entitlements.

          1 Reply Last reply Reply Quote 0
          • macula
            macula last edited by

            I was about to open a new thread to request Document Picker support for Editorial.app. I presume similar reasons apply that prevent/discourage omz from implementing that?

            1 Reply Last reply Reply Quote 0
            • dgelessus
              dgelessus last edited by

              The 1.6 beta version of Pythonista has document picker support, at least on the Pythonista side. That means that you can load/save files from/to iCloud Drive and other apps by calling the appropriate functions, but you cannot access Pythonista's file storage from other apps supporting the document picker. This functionality will be included in the dialogs module, which is also coming to Editorial as I understand it.

              1 Reply Last reply Reply Quote 0
              • omz
                omz last edited by

                It's quite likely that I'll remove document picker support in the next beta. This has less to do with app review concerns than with technical issues that I'm too tired to explain right now. In general, please don't take any features in a beta version as a guarantee that they'll end up in the final release.

                1 Reply Last reply Reply Quote 0
                • Gerzer
                  Gerzer last edited by

                  But I looove the document picker! Maybe you could label it as “experimental”, like you did with ctypes? I haven’t run into any issues, and even Xcode handles it just fine.

                  1 Reply Last reply Reply Quote 0
                  • misha_turnbull
                    misha_turnbull last edited by

                    @omz - maybe for iCloud you could do something like taking all the content of each file, and converting it to a .txt or some other type of file Apple allows to be sync-ed, and then on the other side convert it back to a .py?

                    1 Reply Last reply Reply Quote 0
                    • mteep
                      mteep last edited by

                      @misha_turnbull I'm sorry, but I don't think that would help. I am pretty sure that any set of mechanisms that together enable code distribution is disallowed. Syncing user created content (including code) among the users devices is allowed. It doesn't really have anything to do with file types, extensions or UTI:s.

                      1 Reply Last reply Reply Quote 0
                      • omz
                        omz last edited by

                        @mteep

                        Syncing user created content (including code) among the users devices is allowed

                        What makes you think that syncing or downloading user-created code is allowed? The rule is about "apps that download code in any way or form", it doesn't distinguish between user-created or not.

                        1 Reply Last reply Reply Quote 0
                        • JonB
                          JonB last edited by

                          I love these rules:

                          2.1  Apps that crash will be rejected
                          2.2  Apps that exhibit bugs will be rejected
                          

                          It's a wonder that any app is ever approved :)

                          1 Reply Last reply Reply Quote 0
                          • mteep
                            mteep last edited by

                            @omz I could be wrong of course, but it just makes sense for personal content. From the perspective of users, iCloud is a simple feature that automatically makes their personal content available on all their devices, to quote some developer documentation. If a user can enter something into an app on one device, why shouldn't (s)he be able to access it in the same app on another device? After all, (s)he can restore an iCloud backup onto another device. Apple wouldn't gain anything by restricting that to some subset of personal content.

                            The key here is personal content. The guidelines refers to content created by other users as user generated content, and that is completely different.

                            The apparent contradiction could be explained in that the app itself doesn't actually do the download over the network (as far as I understand it), it just saves the file in the Ubiquity container and reads it from there (using special APIs, but still). The actual up- and download to sync it across devices is handled in the background by the Ubiquity machinery, somewhat like backups to iCloud are handled behind the app's back.

                            I believe the way, (shape,) or form wording refers to that the timing, the network protocol, or any encoding, encryption, or obfuscation is irrelevant. Basically, there shouldn't be any surprises for the user in terms of code that the review team couldn't review.

                            1 Reply Last reply Reply Quote 0
                            • Gerzer
                              Gerzer last edited by

                              @JonB How did Apple’s own apps get approved? What about iOS itself? ;-D

                              1 Reply Last reply Reply Quote 0
                              • dgelessus
                                dgelessus last edited by

                                @Gerzer, interestingly enough Safari would theoretically violate many of the app guidelines. Mostly those regarding crashes/bugs, downloading and running code, performing purchases without Apple's IAP system, and all the restrictions about adult and illegal content. ("Apps that include games of Russian roulette will be rejected." Who came up these guidelines?) Thankfully Apple doesn't actually enforce these for internet content appearing in web views, otherwise it would be almost impossible to use web views at all. ;)

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Powered by NodeBB Forums | Contributors