iCloud Sync support
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.
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
ctypesmodule, 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.
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.
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?
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
dialogsmodule, which is also coming to Editorial as I understand it.
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.
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.
@omz - maybe for iCloud you could do something like taking all the content of each file, and converting it to a
.txtor some other type of file Apple allows to be sync-ed, and then on the other side convert it back to a
@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.
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.
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 :)
@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.
@JonB How did Apple’s own apps get approved? What about iOS itself? ;-D
@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. ;)