@zencuke Apple doesn't allow Pythonista to do iTunes file sharing? Do you have a source for that? (Although it's a little more accessible for abuse than "Documents in the Cloud", I'm not convinced it is totally forbidden for code.)

@omz There seems to be some issue affecting the canvas module. In both the recent betas (160013 and 160014), your turtle.py example crashes Pythonista immediately. But other simple canvas usage does not. In released versions like 1.5, and the earlier betas, I have only observed canvas crashes when I edited the script while it was running.

@polymerchm It seems that only crash reports with file names ending in ".ips" are shown in Xcode. Those that have been transferred are renamed on the device to ".ips-transferred" or similar. Those from the Pythonista beta end in ".ips-beta" or so. Fortunately, they call all be viewed on the device, if you go to Settings -> Privacy -> Diagnosis ... -> Diagnosis ... (or something close to that).

Well, with the Pythonista 1.6 Beta version that had the ctypes and BLE modules, something close to that was possible, but at that time somewhat tricky to implement. I was able to get a live camera view and detect iOS supported metadata/features such as barcodes (tested) and faces (not tested). The output to the relay could easily have been sent using BLE.

Having said that, Pythonista is most likely not the ideal choice to do something like this. At least not in the short term. First, it might take quite a while before the ctypes module comes to a released Pythonista version, due to problems with 64-bit versions. Second, implementation is tricky, in particular if you want to detect something not handled by the built in detectors, and do it fast enough.

The iPad hardware, particularly the Air 2, could most likely do whatever computer vision processing you need blazingly fast on the GPU if properly coded. But this would be a lot easier to develop in Swift or Objective-C in Xcode.

@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.

@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.

@donnieh Well, iTunes can back up the contents of the entire device. And from that backup it is possible to extract the user Python files from Pythonista. But it is nontrivial and might require questionable third party programs. The Xcode method works standalone, but presumably only with non-AppStore apps (TestFlight or your own).

If you have a Mac, you can use Xcode.

Just connect your device, go to the Devices window and click on your device. Under Installed Apps, you'll find Pythonista and probably any other TestFlight apps. Select Pythonista, click on the gear icon and select Download Container .... This saves the entire user portion of the app as a package. (That is, a directory which Finder shows as a single file. Context click on it and select Show package contents to show the files.)

Later, you could restore it using Replace Container ..., but if it is to a different version of the app you should download that container first and then replace the AppData/Documents content with that which you saved initially.

@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.

@wradcliffe Thanks, but I can't really say it was a very structured approach. I started on two different approaches: rewriting using PyBee, and logging the address and memory contents of the ctypes objects to be able to compare with the register contents in the crash reports. But while doing that I came to realize that the way I had written the code, nothing in Python (nor in Objective-C) could actually hold on to the function trampoline slot. So I added a direct reference to the Python object which allocated it. Luckily it was that simple.

So I never completed the rewrite using PyBee, but that would most likely have eliminated the crashes too . Except that I could only have run the code once without restarting Pythonista, due to the Objective-C classes remaining registered. I currently deal with this by disposing the old class pair if I cannot allocate a new class pair, but it would be better to clean up before exiting.

In parallel, I also did a stripped down version without the metadata detection, in order to post it. However, when I added the ability to switch between the front and back cameras, it crashed again. But this does not seem to be a GC thing, rather that an AVCaptureSession only should be manipulated from a single thread (or serial queue). I'm looking at Apple example code, but haven't yet had the time to re-create the exact scheduling of the code across threads/queues. A ui.in_foreground would have made that easier.